SSL握手流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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