handshake（握手）
握手的过程如上图所示；
1.客户端发出请求
客户端先向服务器发出加密通信请求，通常被称为ClientHello; 在这个过程中，客户端会发送给服务器的信息包括：
- 自己支持的协议版本
- 生成一个随机数，自己保留一份并发生给服务器
- 支持的加密算法
2.服务器回应
服务器收到ClientHello后，会发出回应，称为ServerHello； 在这个过程中，服务器会发送给客户的一下内容
- 确认协议版本号
- 服务器生成一个随机数，自己保留一份并发生给客户端
- 确认使用到的加密算法
- 服务器的CA证书
3.客户端回应
在客户端回应之前，需要先对服务器的CA证书进行验证，验证通过后，就会向服务器发送如下信息
- 生成一个随机数，并用证书里的公钥进行加密传输
- 编码改变通知，表示随后的通信使用双方协定的加密法方法
- 握手结束的通知，发送前面内容的hash值，用来供服务器验证
4.服务器最后的回应
- 编码改变通知
- 握手结束通知，发送前面所发生的内容的hash值，供客户端验证；
ssl在协议层中的位置
ssl/tls其实就是夹在tcp和应用层之间的一层安全协议；对于http(应用层)来说，他实际还是直接使用http报文进行传输，只是这层报文数据被ssl整个进行加密，所以在传输的过程中将无法通过抓包来获取到http的数据（毕竟http是明文的）
客户端验证CA证书的过程
客户端在收到服务器的CA证书之后，需要验证该证书是否是上级CA签发，是否被吊销，是否在有效期内；这个证书里面包括上级CA签发的数字签名和公钥；
具体流程就是根据证书的签发机构，在浏览器内置的根证书里找到对应的公钥，用此公钥解开数字签名，验证是否是上级CA的密钥所产生的签名；
这里顺便拓展一点，就是说数字签名是由签发机构的密钥生成的（并不是解密），然后签发机构在将自己的公钥发放给需要验证的单位，使用公钥对数字签名进行解密，若能够解密获得明文，则说明该签名是由该机构签发的，因为只有该机构发放的公钥才能解密获得；换句话说，因为只有CA机构有该私钥，所以没有其他人能生成该签名；
证书的审核是多级的，所以审核的过程是条审核链，毕竟我们有时候也需要知道浏览器的里面的证书是否有效，直到最后的根证书；
对称加密与非对称加密
这里在握手的过程中，对随机数使用公钥加密，私钥解密的过程就是非对称加密，因为是使用公钥加密，只有密钥才能解密，而密钥是不公开的，只有服务器拥有；他是多对一的单向保密通信；常见的算法有RSA等；
对称加密就是双发都持有相同的密钥来对数据进行加解密；在ssl的过程中，最后会使用生成的三个随机数，以及双方协定好的加密算法来生成一个会话密钥，用于后续的对称加密；常见的算法有DES、3DES、AES；
三个随机数
首先说明，第三个用公钥加密的随机数被称为“premaster-secret”，随用双方用该随机数生成“会话密钥”，也称为“master secret”
“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”
其实通过分析握手过程，可以知道整个过程最重要的其实就是公钥的可信度和这个premaster-secret了，握手阶段是明文的，所以这个premaster-secret就非常重要了，根据引用里的解释，就是为了不让这个随机生成的随机数太过好猜，通过在生成两个随机数来使premaster-secret更随机；
