这篇原理讲的蛮好的https原理通俗理解
还有迪哥的这篇 简单粗暴系列之HTTPS
https就是http over ssl 。大致原理如下。（还缺了一个自己画的图，以后补上）
1： 客户端-》 服务器 信息传输不安全，需要加密
2：使用对称加密方式A： 产生如下情况
客户端A--- 对称加密方式A -----服务器
客户端B---- 对称加密方式A ----- 服务器
所有的客户端和服务器的链接都用同一种方式加密，无异于没加密。
- 所以，解决方案是：
客户端A--- 对称加密方式A -----服务器
客户端B---- 对称加密方式B----- 服务器
客户端和服务器之间使用不同的对称加密方式。如何让客户端和服务器知道使用了什么那种对称加密方式呢。
- 解决方案是：
客户端A -------我要用加密算法A---> 服务端
客户端A <---------我知道了--------- 服务端
客户端B-------我要用加密算法B---> 服务端
客户端B <------- 我知道了--------- 服务端
客户端和服务器有一个协商的过程，协商使用那种加密方式和什么秘钥。 产生的问题是协商的部分没有加密。可以被中间人拦截。
- 解决的方案：
使用非对称加密方式，对协商的部分加密。
客户端（公钥）------协商内容（对称加密方式和秘钥）-----> 服务端（私钥）
这样有有一个问题 ，客服端必须有这个公钥，但是客户端如何保证该公钥的确是服务器给的公钥，如下，客户端获取的公钥可能被篡改
客户端<---- 假公钥<-----中间劫持（假公钥，假私钥）<----真公钥---服务器
中间劫持获取服务端真公钥,然后下发假公钥，服务端使用假公钥加密，中间劫持使用假私钥解密，然后将信息篡改，使用真公钥加密后给服务端。
- 解决方案
如果一直加密下去也不是办法。 这时候需要一个第三方机构来处理。
客户端 (本地存储有第三方机构的公钥)<-- 使用第三方机构的私钥加密后的(我们的公钥)---服务端
服务端发送给我们的 使用第三方机构的私钥加密后的 （我们协商要用的公钥等信息）的东西称为 证书。
这样我们对 客户端和服务器之间协商要用的自己的公钥也进行了加密，使用的是第三方机构的私钥。 而第三方机构的公钥存在我们本地不用传输，保证了不会被劫持和替换 。
如果服务器给我们的证书，我们用本地的第三方公钥解密不了，说明证书有问题。
现在遇到一个问题，如果同一个第三方机构用同一个私钥加密了我们要用的公钥M，给了证书1， 也加密了中间劫持人的公约N，给了证书2.
这时，中间劫持人可以解密我们的证书1， 然后给我们一个伪造或者
篡改后的证书2，此时是同一个私钥加密获取的证书，客户端还是可以解密证书2。
- 解决方案是：使用数字签名来防止证书有问题
证书在发送到客户端后，客户端解密后， 对证书的 内容进行 一个签名算法（md5等） 然后与证书自带的 结果进行比对，可以保证证书没有内容没有别篡改。
证书内容 ---签名算法MD5等--> 证书编号结果1 ==？ 证书自带编号结果2
8.关于第三方机构
到这里： 证书就是TTTPS中的数字证书
证书编号就是数字签名
第三方机构就是数字证书颁发机构CA
CA的公钥是如何存在客户端的呢？
其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）
CA如何将证书给我们的服务端的？
签合同-》付款-》 申请-》颁发。
- HTTP的简单实现流程（其实和上边的原理一样）
-
1、客户端首先会将自己支持的加密算法，打个包告诉服务器端。
-
2、服务器端从客户端发来的加密算法中，选出一组加密算法和HASH算法（注，HASH也属于加密），并将自己的身份信息以证书的形式发回给客户端。而证书中包含了网站的地址，加密用的公钥，以及证书的颁发机构等；
-
3、客户端收到了服务器发来的数据包后，会做这么几件事情：
1）验证一下证书是否合法。一般来说，证书是用来标示一个站点是否合法的标志。如果说该证书由权威的第三方颁发和签名的，则说明证书合法。
2）如果证书合法，或者客户端接受和信任了不合法的证书，则客户端就会随机产生一串序列号，使用服务器发来的公钥进行加密。这时候，一条返回的消息就基本就绪。
3）最后使用服务器挑选的HASH算法，将刚才的消息使用刚才的随机数进行加密，生成相应的消息校验值，与刚才的消息一同发还给服务器。 -
4、服务器接受到客户端发来的消息后，会做这么几件事情：
1）使用私钥解密上面第2）中公钥加密的消息，得到客户端产生的随机序列号。
2）使用该随机序列号，对该消息进行加密，验证的到的校验值是否与客户端发来的一致。如果一致则说明消息未被篡改，可以信任。
3）最后，使用该随机序列号，加上之前第2步中选择的加密算法，加密一段握手消息，发还给客户端。同时HASH值也带上。 -
5、客户端收到服务器端的消息后，接着做这么几件事情：
1）计算HASH值是否与发回的消息一致
2）检查消息是否为握手消息
握手结束后，客户端和服务器端使用握手阶段产生的随机数以及挑选出来的算法进行对称加解密的传输。
为什么不直接全程使用非对称加密算法进行数据传输？这个问题的答案是因为非对称算法的效率对比起对称算法来说，要低得多得多；因此往往只用在HTTPS的握手阶段。
以下是我们一些经常使用的加密算法
非对称加密算法：RSA, DSA/DSS
对称加密算法： AES, 3DES
HASH算法：MD5, SHA1, SHA256
这就是HTTPS的基本原理。
网友评论