TLS/SSL握手详解

握手阶段分成五步。


第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。


第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。


第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。


第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。


第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

数字证书：
由证书机构颁发，用户验证服务器是否是合法服务器，客户端向服务器发送请求后收到数字证书，由CA机构私钥签名，包含服务端公钥，有效期等，拿到后用数字证书机构的公钥解密（安装浏览器时自带），得到服务器端公钥，使用随机数或或DH算法参数根据协商的加密算法生成秘钥，以后可以进行对称加密传输


数字签名：
用来验证发送的消息是否被修改，一般用来附在发送消息后，用发送方私钥加密发送消息的hash（使用MD5防止恢复数据）后的值，接收方用发送方公钥解密，解密成功，解密后的内容，与接收到内容做hash后相同，则可以确定没有修改，因为第三方没有发送方私钥，加密后用发送方公钥不能解开


session id与session ticket区别：


握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。


这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。


session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。省去继续握手-》用来生成秘钥。客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。


session ticket方式，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥
了。