目录
前言
网上很多讲https加密的文章，很多技术区大佬用专业的话语将https的加密原理讲得很透彻，但是不好理解，自己看了很多篇文章才能理解核心意思。
为了便于后人理解和自己复习，于是自己借助了网上的图和部分文章的摘抄，为了助于理解，对文章的前后逻辑进行了修改和简化，写下了这篇通俗易懂的讲https加密原理的文章。
参考资料：18 张图彻底弄懂 HTTPS 的原理！ (baidu.com)
HTTPS加密原理概述
（此处与下方的总结内容相同）
https的核心本质还是使用高效的对称密钥的通信方式来进行传输，但是想使用这种方式就得对这个传输方式的密钥通过各种手段保证它是可靠的。
通过非对称传输密钥的方式，实现了客户端到服务器的可靠性。服务器将公钥广发给客户端（这个公钥大家都能拿到），然后客户端用这个公钥，将对称通信的密钥加密后，传给服务器，而服务器这边使用自己的私钥，将公钥加密的东西解开，就得到了那个对称通信的密钥。
接下来，为了保证服务器给客户端的公钥是可靠的，服务器就请别人做担保，服务器向第三方认证的机构CA申请证书，然后服务器再将公钥附在证书上传给客户端。客户端有可靠的方法确保证书是否正确，也就确保了收到的公钥是可靠的。
（具体验证证书的方法如下：客户端收到证书后，首先判断域名是否为目标域名，然后使用算法对签名求出摘要，再用自己内置的CA公钥去解密证书上的摘要，判断两者是否相同）
通过上面两种方式，保证了客户端给服务器的公钥可靠，也保证了服务器给客户端的公钥可靠，然后接下来客户端服务器就通过这两个可靠的公钥进行传输了。
这样即可实现https的加密传输。
HTTP 为什么不安全
HTTP 由于是明文传输，主要存在三大风险：窃听风险、篡改风险、冒充风险。
1.1 窃听风险
中间人可以获取到通信内容，由于内容是明文，所以获取明文后有安全风险。
1.2 篡改风险
中间人可以篡改报文内容后再发送给对方，风险极大。
1.3 冒充风险
比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信。
HTTPS 显然是为了解决这三大风险而存在的，接下来我们看看 HTTPS 到底解决了什么问题。
HTTPS 无非就是 HTTP + SSL/TLS。
而 SSL/TLS 的功能其实本质上是：如何协商出安全的对称加密密钥，以利用此密钥进行后续通讯的过程。
安全通信的四大原则
看了上一节，不难猜到 HTTPS 就是为了解决上述三个风险而生的，一般我们认为安全的通信需要包括以下四个原则: 机密性、完整性，身份认证和不可否认。
机密性：即对数据加密，解决了窃听风险，因为即使被中间人窃听，由于数据是加密的，他也拿不到明文；
完整性：指数据在传输过程中没有被篡改，不多不少，保持原样，中途如果哪怕改了一个标点符号，接收方也能识别出来，从来判定接收报文不合法；
身份认证：确认对方的真实身份，即证明“你妈是你妈”的问题，这样就解决了冒充风险，用户不用担心访问的是某宝结果却在和钓鱼网站通信的问题；不可否认: 即不可否认已发生的行为，比如小明向小红借了 1000 元，但没打借条，或者打了借条但没有签名，就会造成小红的资金损失。接下来我们一步步来看看 HTTPS 是如何实现以满足以上四大安全通信原则的。
HTTPS 通信原理
对称加密：HTTPS 的最终加密形式
既然 HTTP 是明文传输的，直接思路就是给报文加密即可。
如下图所示：双方使用对称加密的方式来给报文进行加密和解密。
对称加密具有加解密速度快，性能高的特点，也是 HTTPS 最终采用的加密形式。
（记住这点，这是最终的形式，不要下面看了那么多原理忘了这点。）
但是如果通过报文的方式直接传输密钥，中间人仍然可以劫取密钥，然后篡改内容：
有人说对这个密钥加密不就完了，但对方如果要解密这个密钥还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题，是不可行的。
下面看另外一种方式，这种方式没法直接解决这把对称密钥的传输问题，但是可以保证单方向（客户端到服务器）对称密钥传输的安全！
非对称加密：解决单向的对称密钥的传输问题
直接传输密钥无论从哪一端传从上节分析来看是不行了，这里我们再看另一种加密方式：非对称加密。
非对称加密即加解密双方使用不同的密钥，公钥和私钥。
公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。
那么我们让服务器这边保留有私钥，将公钥发布给其他客户端，让客户端用这把密钥，将上面提到的对称交流的这把密钥传给服务器，然后服务器用自己的私钥即可解密，解密后即可获得那把对称交流的密钥了。
中间人由于没有私钥，所以就算截取了这段报文，也无法解密。
如下图所示：客户端用公钥加密最终密钥，然后传给服务器。
这样保证了从客户端到服务器这段传输的安全性。（但只能保证单向）（因为服务器已经有了对称加密的密钥了，且只有自己知道）
上述方法只有单向的安全性，那另外一个方向怎么办呢？
如果想按照上面刚才的那种方式，用非对称来传输因为如果直接传公钥，会存在被中间人调包的风险。
数字证书：解决公钥传输信任问题
如何解决公钥传输问题呢？从现实生活中的场景找答案。员工入职时，企业一般会要求提供学历证明，显然不是什么阿猫阿狗的本本都可称为学历，这个学历必须由第三方权威机构即教育部颁发。
也就是说我们可以用一个第三者来帮助验证真实性。
服务器向 CA （Certificate Authority，简称 CA）申请证书，在证书中附上公钥，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。
服务器有了证书后，这样服务器传给客户端的不再是公钥，而是含有公钥的证书。这个证书的存在是为了确保传输的这把公钥是正确的。
那有人说那中间人截取这个证书，然后做一个假的证书不就行了？
事实上是证书没有那么容易伪造，因为证书具有防伪造的手段。下面具体讲解
下面的内容较为复杂，什么时候绕晕了，就回头来看看核心思想。
核心思想就是，证书上有两个东西，一个是公开的，一个是加密过的，这个加密的东西只有客户端自己才能解密的而中间人没法解密。
证书如何防伪呢，就是当这两个东西能互相对应时，说明该证书是真实正确的。
具体来说，证书上有两个东西：
- 一个是证书信息，是没有加密过的，
- 一个是数字签名，它是经过CA上的私钥加密过，只有客户端用一开始就存在于操作系统内部存储的公钥才可以解密。
数字签名是什么，有什么作用？
证书的数字签名该如何产生的呢？简单来说就是对证书的各种信息，例如下图：序列号啊、过期时间、DNS等的信息进行随机摘要（例如使用MD5摘要算法）。
- 提问：为什么要摘要，而不是直接对全部内容加密？
回答：直接对整个内容加密的话，客户端解密会很费时间。
另一方面，一般来说，只要内容不同，产生的摘要必然不同。也就是说摘要相同则证书信息相同。
那验证该证书真伪的方法，就是客户端拿到证书后，也用同样的摘要算法对证书明文计算摘要，两者一比对就可以发现报文是否被篡改了。
提问：那光摘要就可以验证是否被篡改了，那为啥要用第三方权威机构（Certificate Authority，简称 CA）私钥对摘要加密呢？
因为摘要算法是公开的，中间人可以用假的明文替换掉证书明文，再根据摘要算法计算出摘要，然后把证书上的摘要也给替换掉！这样客户端拿到证书后计算摘要发现一样，误以为此证书是合法就中招了。
所以必须要用 CA 的私钥给摘要进行加密，这样的话客户端得用 CA 的公钥来给签名解密。
而这个公钥，是被操作系统信任，内置在客户端的操作系统上的CA证书上的。所以无需传输，因此也不会被劫取。这意味着中间人是没有这个公钥的。
如果用的是 Mac 的同学，可以打开 keychain 查看一下，可以看到很多内置的被信任的证书。
我们接下来看，服务器将证书传给客户端后，客户端的验证签名过程如下：
服务器传输 CA 颁发的证书，客户收到证书后使用内置 CA 证书中的公钥来解密签名，然后对信息生成摘要，判断二者是否相同即可。如下图所示
于是：
如果客户端收到的证书中，数字签名被篡改，该证书上的数字签名使用 CA 的公钥是无法解密的。
如果客户端收到的证书中，证书信息被篡改，那么对该信息做出来的摘要肯定也是错误的，那么和真正的数字签名就会比对不成功，客户端也会认定此证书非法。
这样的话就解决了公钥传输过程中被调包的风险，保证了从服务器到客户端传输的公钥是真实正确的。
证书一整个被掉包怎么办？
不过此处还有一个问题，上面是实现了，利用证书的两部分信息互相验证的机制保证正确。
如果证书一整个被调包怎么办？
实际上任何站点都可以向第三方权威机构申请证书，中间人也不例外。
正常站点和中间人都可以向 CA 申请证书，获得认证的证书由于都是 CA 颁发的，所以都是合法的。
于是假如客户端收到的是一个 被掉包，但是合法的证书，那进行上面的验证签名的过程自然不会有问题。
那么此时中间人是否可以在传输过程中将正常站点发给 client 的证书替换成自己的证书呢，如下所示：
上图的思想看上去好像很完美，但是有一个致命的弱点！
答案是不行，因为客户端除了通过验签的方式验证证书是否合法之外，还需要验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 客户端请求的域名不一致，客户端会认定为不通过！
于是，这样就实现了https的加密功能了。
总结
https的核心本质还是使用高效的对称通信方式来进行传输，但是想使用这种方式就得对这个传输方式的密钥通过各种手段保证可靠。
通过非对称传输密钥的方式，实现了客户端到服务器的可靠性。服务器将公钥给客户端，然后客户端将对称通信的密钥传给服务器，而服务器这边是使用只有自己才知道的私钥才能进行解密的。
为了保证服务器给客户端的公钥是可靠的，服务器向第三方认证的机构CA申请证书，然后服务器再将公钥附在证书上传给客户端。客户端收到证书后，首先判断域名是否为目标域名，然后比对数字签名和使用摘要算法得出的信息是否正确（即验签）。这样即可实现https的加密传输。
其它 HTTPS 相关问题
什么是双向认证？
以上的讲述过程中，我们只是在 client 端验证了 server 传输证书的合法性。
但 server 如何验证 client 的合法性呢？
还是用证书，我们在网上进行转账等操作时，想想看是不是要先将银行发给我们的 U 盾插到电脑上？其实也是因为 U 盾内置了证书，通信时将证书发给 server，server 验证通过之后即可开始通信。
画外音：身份认证只是 U 盾功能的一种，还有其他功能，比如加解密都是在 U 盾中执行，保证了密钥不会出现在内存中
什么是证书信任链？
前文说了，我们可以向 CA 申请证书，但全世界的顶级 CA（Root CA） 就那么几个，每天都有很多人要向它申请证书，它也忙不过来啊，怎么办呢？想想看在一个公司里如果大家都找 CEO 办事，他是不是要疯了，那他能怎么办？授权，他会把权力交给 CTO，CFO 等，这样你们只要把 CTO 之类的就行了，CTO 如果也忙不过来呢，继续往下授权啊。
同样的，既然顶级 CA 忙不过来，那它就向下一级，下下级 CA 授权即可，这样我们就只要找一级/二级/三级 CA 申请证书即可。怎么证明这些证书被 Root CA 授权过了呢，小一点的 CA 可以让大一点的 CA 来签名认证。比如一级 CA 让 Root CA 来签名认证，二级 CA 让一级 CA 来签名认证,Root CA 没有人给他签名认证，只能自己证明自己了，这个证书就叫「自签名证书」或者「根证书」，我们必须信任它，不然证书信任链是走不下去的（这个根证书前文我们提过，其实是内置在操作系统中的）
证书信任链现在我们看看如果站点申请的是二级 CA 颁发的证书，client 收到之后会如何验证这个证书呢，实际上 service 传了传给二级 CA 的证书外，还会把证书信任链也一起传给客户端，这样客户端会按如下步骤进行验证：
浏览器就使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签；拿一级证书的公钥解密一级证书，拿到二级证书的公钥和摘要验签；再然后拿二级证书的公钥解密 server 传过来的二级证书，得到服务器的公钥和摘要验签，验证过程就结束了。
为什么不能随便认证第三方的证书？
上面的证书调包给了我们一种思路，什么思路？
大家想想，HTTPS 既然是加密的， charles 这些中间人为啥能抓到明文的包呢？其实就是用了证书调包这一手法，想想看，在用 charles 抓 HTTPS 的包之前我们先要做什么，当然是安装 charles 的证书。
这个证书里有 charles 的公钥，这样的话 charles 就可以将 server 传给 client 的证书调包成自己的证书，client 拿到后就可以用你安装的 charles 证书来验签等，验证通过之后就会用 charles 证书中的公钥来加密对称密钥了。整个流程如下：
由此可知，charles 这些中间人能抓取 HTTPS 包的前提是信任它们的 CA 证书，然后就可以通过替换证书的方式进行瞒天过海，所以我们千万不要随便信任第三方的证书，避免安全风险。
2965
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
