最近在准备下面试的东西，好久没写了，后续会慢慢补上，这篇博客主要说说我自己对https的一些理解吧，如果有错误的地方请指出，谢谢！ 自己先后在银行 和金融行业的公司，对这块还停留在很久以前的认知中，可能以前就没有正真搞懂，也可能是时间久忘记了
对称加密 和非对称加密
常用的hash算法：sha1 sha256 MD5 三者的区别是生成位数不同分别160 256 128
常用的对称加密：DES/AES
常用的非对称加密：RSA （一对密钥，公钥加密私钥解密，私钥加密公钥解密）
RSA发送消息的流程
没有找到合适的图，自己DIY一个：
rsa流程.jpg
客户端：消息，就是我们要发送的内容，首先通过一个单向hash过程，目前主流sha-256 生成一个hash值，拿到hash值，使用证书中的公钥对他加密，生成密文，把密文和我们发送的消息一起发送给服务端；
服务端：收到这个消息+ 密文，把密文取出来，用私钥对他解密。即使有中间人攻击，他没有私钥，就不能解析我们的密文，解析这个密文，得到一个hash值， 同样的 我们在把消息，使用客户端一样的单向hash生成一个hash值， 通过对比生成的 hash值和 解密的hash值，是否一样，如果一样说明传输没有被篡改。
上面流程的问题
1.使用公钥加密 耗时问题
2.公钥被冒充问题
这里就要说到https连接有一个握手过程：
1.客户端首先向服务端发送https请求，包含自己支持的cipher（秘钥算法套件）
2.服务端收到这个请求，会去匹配自己是否支持这个cipher，如果不支持，直接断开链接，如果支持选择一种加密算法和hash()算法，以证书的形式返回给客户端，证书里面还有颁发机构，有效期，域名 等信息
3，客户端收到这个证书，首先会去验证这个证书的合法性，有效期，请求地址等； 如果ok或者说添加了非授信的证书（比如fidder的证书） 会生成一串随机数，使用证书的公钥对这个随机数加密。这个随机数也就是后面加密的一把钥匙，这个就解决了我们第一个问题，使用这个钥匙进程对称加密，同时，会把这个钥匙给服务端，因为这个传输过程是用公钥加密，中间的人不能获取到，只要有私钥的服务端才能得到，那么服务端拿到这个钥匙就可以解密了。
上面的过程还有一个风险，就是客户端下发的证书怎么判断是服务器的
这个涉及证书的生成，与证书的校验：CA机构简单说下吧，就是权威机构，就是大家都信任的机构，比如你存钱在银行，要的时候去银行取，CA类比银行，比较出名的赛门特克等
证书生成
1.CA机构自己生成一对秘钥对；
2.当有公司向CA机构申请证书时候，也就是一般公司的运营会提供公司的注册信息，用途使用时长，域名等信息给到CA机构
3.CA机构会进行线上 线下的严格确认，然后把自己的信息，和公司提供的部门信息，整合到一起，但是这个时候是没有CA机构签名的
4.从3中抽取出摘要信息，然后使用CA机构的私钥对这个加密，也就是签名，CA 机构对他自己的私钥控制的非常严密
5.服务端拿到这对签过名的证书挂在服务器就可以运行了。
证书校验
1.首先客户端收到证书，会从证书中取出2个东西，一个是摘要密文一个是元数据
2.使用CA机构的公钥，对这个摘要密文进行解密，解密后得到一个摘要原文，主要是因为CA的公钥是公开的，所有人都能拿到，一般在内置在操作系统中
3.使用证书中提供hash对元数据进行hash，对比这个和2的摘要原文，一直 就说明证书没问题，
流程： 信任CA机构——>信任CA机构签发的证书 ——>信任挂起这个证书的服务器
其他风险
1,私钥一般放在服务器，如果黑客直接攻击了服务器，拿到了私钥，这个就涉及到一个证书链概念， CA机构有首先是自己生成一对秘钥，用私钥对自己加密，然后生成CA的二级证书，一般都是用CA都是有个一层一层的关系，出现上述问题，直接使用CA上级重新生成一对证书解决
2.webView 的证书信任问题，当使用webView.setWebClient()使用，重写webViewClient的onRecivedSslError（）这个 如果使用handler.procesd（）
会忽略，错误证书，继续显示，使用handler.cancel（）去取消
网友评论