客户端回合
Client Hello
- 客户端使用的TLS版本
- 支持的密码套件列表
- 随机数(Client Random)
服务器回合
Server Hello
- 确认TLS版本号是否支持
- 选择一个密码套件
- 随机数(Server Random)
Server Certificate
数字证书:
- 公钥
- 持有者信息
- 证书认证机构(CA)的信息
- CA对这份文件的数字签名及使用的算法
- 证书的有效期
- 还有一些其他额外信息
Server Hello Done
客户端回合
Client Key Exchange
- 用服务器公钥加密过的随机数(pre-master)
其中公钥可以在服务器发回来的证书中找到，pre-master由客户端自己随机生成
中场休息
现在回顾一下服务器和客户端双方现在都拥有什么。省去TLS版本号确认、加密套件选择的环节，双方分别交换了各自生成的随机数Client Random和Server Random，还有pre-master。pre-master是通过非对称加密的方式来交换的，客户端生成pre-master后使用公钥加密，服务器接收到后使用私钥解密出pre-mater。
所以，至此，双方都拥有Client Random、Server Random和pre-master这三样东西，前两者是明文传送，可以被截获，最后一个pre-master则是采用非对称加密传送，即使截获也没意义。
其实只需要通过非对称加密pre-master就能完成协商，但是
不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。对于RSA密钥交换算法来说，pre-master secret本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-master secret就有可能被猜出来，那么仅适用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
双方根据都拥有的三个随机数来生成会话密钥(Master Secret)，用于后续的对称加密会话。
客户端回合
Change Cipher Spec
告诉服务器开始使用加密方式发送消息
Encrypted Handshake Message(Finished)
把之前所有发送的数据做个摘要，再用会话密钥(master secret)加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。
- 确认会话密钥的正确性
- 告诉对方在整个过程中发送了什么，接收了什么（防止中间人篡改报文）
如果中间有人篡改了报文（中间人攻击），比如，把客户端的client hello中的提供的加密套件改成了 一个弱秘钥算法，那么对于server而言，收到的client hello 和 客户端实际发送的是不同的，假设server收到的叫做client_hello_bad，这样，server 在计算Encrypted handshake message时，因为使用了client_hello_bad，计算完成之后，会发送给客户端，客户端为了确定握手数据是否被篡改，也需要模拟server端计算这个Encrypted handshake message，显然 客户端 计算 Encrypted handshake message 用的client hello 不是client_hello_bad，这样，客户端计算出来的，就和 服务端发过来的不同了，验证自然失败。
服务器回合
Change Cipher Spec
Encrypted Handshake Message(Finished)
结束握手
如果双方都验证加密和解密没问题，那么握手正式完成。最后，就用「会话密钥」加解密 HTTP 请求和响应了。
其中的数学原理
- 分解质因数很难（其实还有超多原理）
- 欧拉函数
- 欧拉定理
- 模反元素
- 同余定理
参考链接：
标签：pre,加密,RSA,算法,master,密钥,随机数,客户端 From： https://www.cnblogs.com/roadwide/p/17146231.html