SSL握手流程

一、SSL是什么？

安全套接字（SSL）协议是Web浏览器和Web服务器之间安全交换信息的协议。

SSL介于应用层和TCP层之间，应用层数据不再直接传递给传输层，而是传递给SSL层，SSL层对从应用层收到的数据进行加密，并增加自己的SSL头。

History:
年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
年，NetScape公司发布SSL .0版，很快发现有严重漏洞。
年，SSL .0版问世，得到大规模应用。
年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS .0版。
年和年，TLS进行了两次升级，分别为TLS .1版和TLS .2版。最新的变动是2011年TLS .2的修订版。

0x1:SSL记录协议：
) 分组、组合
) 压缩、解压缩
) 以及消息认证
) 加密传输等

0x2:SSL握手协议：
). 客户机认证服务器
). 协商客户机与服务器选择双方都支持的密码算法
). 可选择的服务器认证客户
). 使用公钥加密技术生成共享密钥
). 建立加密SSL连接（过程都是明文的，握手完成之后才开始加密数据。）

0x3:SSL告警协议：SSL告警协议报文由严重级别和警告代码两部分组成

. 严重级别(AlertLevel )
    ) Fatal
    Fatal级报警即致命级报警，它要求通信双方都要采取紧急措施，并终止会话，同时消除自己缓冲区相应的会话记录
    ) Waming
    Warning级报警即警告级报警的处理，通常是通信双方都只进行日志记录，它对通信过程不造成影响
. 警告代码
    ) bad_record_mac：收到了不正确的MAC
　 ) unexpected_message：接收了不合适的报文
    ) decompression_failure：解压缩函数收到不适当的输入。
    ) illegal_parameter：握手报文中的一个字段超出范围或与其他字段不兼容。
    ) certificate_revoked：证书已经被废弃。
    ) bad_certificate：收到的证书是错误的。
    ) certificate_expired：证书已经过期。
    ) handshake_failer：握手过程失败。
    ) no_certificate: 未提供证书
    ) unsupported_certificate: 未支持的证书格式
    ) certificate_unknown: 未知证书

二、SSL有什么用？

. 秘密性: SSL客户机和服务器之间传送的数据都经过了加密处理,网络中的非法窃听者所获取的信息都将是无意义的密文信息

. 完整性: SSL利用密码算法和散列(HASH)函数,通过对传输信息特征值的提取来保证信息的完整性,确保要传输的信息全部到达目的地,可以避免服务器和客户机之间的信息受到破坏。

. 认证性:利用证书技术和可信的第三方认证，可以让客户机和服务器相互识别对方的身份。为了验证证书持有者是其合法用户(而不是冒名用户)，SSL要求证书持有者在握手时相互交换数字证
书，通过验证来保证对方身份的合法性。

三、SSL和TLS的差异：

. 版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.。
. 报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
. 伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
. 报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如
    ) 解密失败(decryption_failed)
    ) 记录溢出(record_overflow)
    ) 未知CA(unknown_ca)
    ) 拒绝访问(access_denied)等。
. 密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS"不支持":
    ) Fortezza密钥交换
    ) 加密算法
    ) 客户证书。
. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
. 加密计算：TLS与SSLv3.0在计算主密值(master secret)时采用的方式不同。但都是以客户端和服务端各自产生的随机数Ramdom作为输入
. 填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍(但填充的最大长度为255字节)，这种方式可以防止基于对报文长度进行分析的攻击。

四、SSL过程

0x1: 流程  前两部称为“握手阶段”

）客户端向服务器端索要并验证公钥
）双方协商生成“对话密钥”（不用通信方的公钥进行加密<耗时>，只用对方的公钥来加密本端生成的“密钥”）
）双方采用“对话密钥”进行加密通信。

0x2:具体过程  只关注单向认证

1. Client Hello：首先，客户端（浏览器）先向服务器发出加密通信请求，这被叫做ClientHello请求。

) 支持的协议版本，比如TLS .0版。
) 一个客户端生成的随机数A，稍后用于生成"对话密钥"。
) 加密方法：支持的多种非对称加密方法、多种对称加密方法、多种MAC算法
)  支持的压缩方法。

2.Server Hello：

) 确认使用的加密通信协议版本，比如TLS .0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
) 一个服务器生成的随机数B，稍后用于生成"对话密钥"。
) 确认使用的加密方法：从客户端提供的选出一个集合出来：{对称加密算法，非对称加密算法，MAC校验算法}

3. Certificate： server将“携带自己公钥信息的数字证书”和到根CA整个链通过Certificate消息发送给SSL客户端（整个公钥文件都发送过去）

1）客户端可以使用该公钥来验证服务器的身份

证书中的消息包括：

一般情况下客户端收到的是一个证书链，第一个是服务器的证书，之后是服务器证书签发者，最后是自签名的根证书。如下图，在实际解析中先要验证根CA的证书，然后是直接证书签发者证书，最后是服务器终端证书。

证书合法性的判断方法：

~颁布者的合法性（hash值）
~有效期
~签名值是否合法：首先对证书中除签名值部分的内容按照证书中的签名算法进行签名，把得到的签名按照asn.1编码方式进行编码：OBJECT格式的签名算法+ ASN_OCTET_STRING格式的签名值A；把证书中的签名值按照证书中的主体公钥算法进行解密得到B；当A和B完全相同时认为证书有效（证书制作过程中的签名值计算方法：计算得到A，和客户端计算方法相同，用服务器私钥对A进行加密，得到证书中的签名值）

2）公钥加密pre-naster secret （Client Key Exchange）

假设上面的证书验证通过了，这就意味着client相信server发过来的证书了，也就意味着client同意用server发过来的public key开始通讯了。注意，非对称加密的过程在这里开始了。client生成了一个pre-master secret（通常也是一个随机数）P，使用server提供的public key加密P之后生成P'，将P'发给了server。

server收到P'后，用自己的private key解密还原出了P。注意这个P和之前A的最大不同是加密传输过来的哦。而且理论上在server没有泄露自己private key的情况下， 只有server能够从P'还原出P。So，此时，client和server双方已经具备了生成双方后面通讯时对称加密需要使用的master secret的条件：双方都有的一个确定的伪随机函数、3个彼此都知道的随机数A、B和P。于是，双方在自己一方，通过共同的伪随机数和共同的素材，生成出来了master secret。

--------------

为什么要使用三个随机数?

1)"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
2)对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
3)pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret
 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是
 是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的 可不是一。"

4. Change cipher Spec：通信双方协商好了对称加密的密钥和对称加密的算法之后，用这个消息进行测试

)client用双方同意的MAC（message authentication code）算法，比如MD5加密一段明文Q，生成MAC，然后用双方都同意的对称加密算法（比如AES）加密Q和MAC之后，
  生成一段Change Cipher Spec(content type:).
)Server收到这条TLS record之后，会先尝试解密密文，再用约定的MAC算法验证内容是否被篡改。这个如果这两个任何一项工作失败了，就前功尽弃了。这里假设都成功了，
  于是server做了上一步client同样的事情：生成一份content type为20的Change cipher Spec发给client，至此，整个握手过程正式结束。

5. 下面的通讯就是双方直接使用对称加密算法直接加解密message的过程了，每次交互过程中，还会包括上面描述的MAC验证的过程。

参考资料：大部分资料来自网络，我只是稍加整理。风格是抄袭Little Hann大神的~勿喷

http://www.cnblogs.com/LittleHann/p/3733469.html
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
http://www.2cto.com/Article/201404/291859.html
http://blog.csdn.net/sealyao/article/details/5901510