一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第7天，点击查看活动详情。
前言
之前的两篇已经讲了对称加密、非对称加密、https为什么不用两个非对称加密来实现，具体内容可参考。上篇文章还遗留一个问题就是https中使用的加密方式是对称加密和非对称加密结合的方式，但是非对称加密的公钥可能会被中间人劫持、更改，下面就来看一下https是如何解决化解这个问题的。
验证收到的公钥是否是原网站的公钥
- 数字证书 实现验证公钥是否是原网站的公钥就要靠数字证书来实现了，何为数字证书呢？它是又CA机构在网站申请https的时候所颁发的证书。证书中包含了原网站的身份信息，公钥等内容。百度的解释如下图：
但是数字证书也可能会被被人恶意更改，这时候就要引出https的终结防更改方法了，那就是数字签名。
数字签名
数字签名就是CA机构通过使用自己的私钥对数字证书进行加密处理，得到数字签名S；在把数字证书和数字签名一起给目标浏览器。当浏览器收到之后就可以使用CA的公钥来解密数字签名，和数字证书一对比就可以知道数字证书是否被更改了（这是因为如果中间人更改了证书，那数字证书就会和解密的数字签名不一致）
还有一种情况就是中间人也有CA机构的认证证书，那它就可以拿着自己网站的数字证书和数字签名去做中间人攻击了（它把自己的数字证书和数字签名给目标，目标可能会把它当成原网站，因为数字签名解密后和数字证书是一致的），但这种情况几乎不存在，因为数字证书包含了网站的很多信息，比如名称，域名什么的，浏览器只要一和目标网站一对比就会发现其中的猫腻。
双方多久进行一次秘钥的传输呢？
试想一下，如果每一次https请求都要传输一次秘钥，那是非常耗时的，这不太现实。真实的情况也确实不是每次请求都会传输一次秘钥。这其中的原理是当第一次连接时，服务器为会浏览器生成一个sessionId，在这个sessionId下面会存放这个浏览器的秘钥，当下次浏览器再连接的时候只要带上sessionId就可以了，服务器就会找到这个浏览器的秘钥，这就不用每次都传入秘钥了。
总结
通过分为三部分终于把https的大致加密过程搞清楚了七七八八。其中牵扯的东西还是挺多的，对称加密，非对称加密，数字证书，数字签名等等，还有很多细节没有去深究，等有机会再一一探索。
