关于HTTPS的理解 https( 五 )

第三步，Client Key Exchange前两个打招呼的报文实际上都是明文传输的，因为在建立连接之前双方都没有密钥，无法使用加密传输的。而前文有提到的两个随机数(Client Random和Server Random)都有被截获的风险，如果中间人获取到我们的随机数，再根据同样的算法进行计算，不是就可以得到我们最终生成的对称密钥了吗？显然我们不可能让坏人轻易得逞，原因就在于第三步的Client Key Exchange中的第三个随机数，我们通常称之为预主密钥(Pre Master) 。客户端在收到了服务器返回的消息之后，首先会用存放在本地的根证书对服务器证书进行验证，验证通过便会认为服务器证书中的公钥是可信的，取出来备用。接下来客户端会生成第三个随机数，为了把这第三个随机数安全的交给服务器，我们需要对他进行加密，这时的情况跟第一次Client Hello时有所不同，因为我们已经有了可以信任的服务器公钥。客户端根据服务器返回的Cipher Suite使用确定的算法和公钥对第三个随机数进行加密传输。这时候只有服务器的私钥可以解密获取这第三个随机数，从而保证了主密钥的安全。
在这一步里，客户端还做了一些小动作，由于客户端现在已经抢先服务端计算出了主密钥，而当这条Client Key Exchange信息到达服务端时，服务端应该也能正确的计算出主密钥，所以客户端先用主密钥对之前握手的信息做了摘要和签名以供服务端计算出主密钥之后当场进行验证，这是双方第一次使用对称加密的主密钥进行加密。
第四步，Server Change Cipher Spec走到这一步，服务端会先用自己的私钥解密，获取到客户端传来的第三个随机数（预主密钥），接着通过相同的算法计算出主密钥。服务端对上一步客户端做的小动作进行验签，这是服务端第一次使用对称加密主密钥，如果验签成功说明我们双方的主密钥计算成功，是安全的。接着服务端做了最后的回应：

Change Cipher Spec，告诉客户端，我准备好了，后续咱们就用主密钥加密沟通，你懂的。
对我们握手的信息用主密钥进行签名，你验证一下。

至此，整个HTTPs的握手完成。
后记关于HTTPs的内容确实有很多要讲。比如本文所讲的主要时原始的RSA密钥交换，而目前应用最多的密钥交换算法是ECDHE，它在交换随机数与预主密钥时使用了不同的策略，但是流程原理与RSA密钥交换是共通的。HTTPs的每一步都有它的用意，少了任何一步都会导致信息安全出现漏洞，原PPT的后面还有一部分反向案例分析，由于篇幅问题就下次再更新吧。

关于HTTPS的理解 https( 五 )

秒懂生活扩展阅读