备注：学习 SSL/TLS 是为更深刻地理解 HTTPS 作知识储备。
一、SSL/TSL协议的产生背景
1> 目前互联网常用的 'HTTP协议' 是非常不安全的明文传输协议。
2> 'SSL协议'及其继任者'TLS协议'，是一种实现网络通信加密的安全协议。
3> 通过 SSL/TSL协议，可在客户端（浏览器）和服务器端（网站）之间建立一条加密通道，保证数据在传输过程中不被窃取或篡改。
4> 'SSL证书'，也称为 '服务器SSL证书'，是遵守SSL协议的一种数字证书。
5> 'SSL证书'由全球信任的证书颁发机构(CA)验证服务器身份后颁发。将SSL证书安装在网站服务器上，可实现网站身份验证和数据加密传输双重功能。
二、SSL/TLS协议的作用
HTTP协议不使用 SSL/TLS，所以HTTP通信是不加密的通信，也就是说: HTTP通信过程中的所有信息都是明文传输的。
HTTP通信是明文传输，所以具有以下3大风险:
1> 窃听风险(Eavesdropping)：'第三方可以窃听(截获)通信内容'。
2> 篡改风险(Tampering): '第三方可以修改通信的内容'。
3> 冒充风险(Pretending): '第三方可以冒充他人身份参与通信'。
SSL/TLS就是为了解决上述三大风险而诞生的，目的是达到
1> 所有信息都是'加密传播'，第三方无法窃听(截获)。
2> 具有'校验机制'，一旦被篡改，通信双方会立刻发现。
3> 配备'身份证书'，防止身份被冒充。
众所周知，在互联网上，通信双方的身份都是未知的，这就为协议的设计带来了很大的难度。而且，协议还必须能够经受所有匪夷所思的网络攻击，这就使得SSL/TLS协议变得非常复杂。
三、SSL/TLS的概念
1> SSL：(Secure Sockets Layer) '安全套接层',
2> TLS：(Transport Layer Security) '传输层安全'，TLS是SSL的继任者。
3> SSL/TLS都是为网络通信提供'安全'及'数据完整性'的一种安全协议。
4> TLS与SSL在'传输层'对网络连接进行加密。
四、SSL/TLS的历史
1> 1994年，NetScape(网景)公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
2> 1995年，NetScape公司发布SSL 2.0版本，很快发现有严重漏洞。
3> 1996年，SSL 3.0版问世，得到大规模应用。
4> 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
5> 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。
6> 目前，应用最广泛的是 TLS1.0版，接下来是 SSL3.0。但是，主流浏览器都已经实现了对TLS1.2的支持。
注: TLS1.0通常被标示为SSL3.1，TLS1.1为SSL3.2，TLS1.2为SSL3.3
五、SSL/TLS的基本运行过程
SSL/TLS协议的基本思路是: 采用公钥加密法。
基本流程如下:
1> 客户端先向服务器索要公钥
2> 客户端用公钥加密信息
3> 服务器接收到秘文之后，用自己的私钥解密
但是，存在两个问题
1> 如何保证公钥不被篡改?
解决办法: 将公钥放在'数字证书'中。'只要证书是可信的，公钥就是可信'的。
2> 公钥加密计算量太大，如何减少耗用的时间？
解决办法:
* 每一次对话(session)，客户端和服务器都会生成一个'对话密钥'(session key)，用它来加密信息。
* 由于'对话密钥'是对称加密，所以运算速度非常快，而服务器公钥只用于加密'对话密钥'本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程如下
1> 客户端向服务器端索要并验证公钥。
2> 双方协商生成'对话密钥'。
3> 双方采用'对话密钥'进行加密通信。
注: 前两步又称为'握手阶段'(handshake)
六、握手阶段详解
握手阶段.png
由图可知: 『握手阶段』涉及4次通信，我们一一来解读。需要注意的是，『握手阶段』的所有通信都是明文的。
6.1 客户端发出请求(ClicentHello)
首先，客户端(通常是浏览器)先向服务器发出需要加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息:
1> 客户端支持的协议版本，比如 TLS1.0版。
2> 一个客户端生成的随机数，稍后用于生成'对话密钥'。
3> 客户端支持的加密算法，比如RSA公钥加密。
4> 客户端支持的压缩方法。
这里需要注意:
1> 客户端发送的信息中不包括服务器的域名。
2> 也就是说，理论上服务器只能包含一个网站，否则就会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
3> 对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
6.2 服务器响应(ServerHello)
服务器接收到客户端的请求后，向客户端发出响应，这叫做ServerHello。
服务器的响应包含以下内容:
1> 确认服务器自己使用的加密通信协议的版本，比如TLS1.0版本。如果客户端和服务器支持的版本不一致，服务器就会关闭加密通信。
2> 一个服务器生成的随机数，稍后用于生成'对话密钥'。
3> 确认使用的加密算法，比如RSA公钥加密。
4> 服务器证书。
除了上面的信息，如果服务器需要确认客户端的身份，就会再包含一项请求，
5> 要求客户端提供'客户端证书'。
比如: 金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
6.3 客户端回应
- 客户端收到服务器回应以后，首先验证服务器证书。
- 如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
- 如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。
1> 一个随机数。该随机数用服务器公钥加密，防止被窃听。
2> 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
3> 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
- 上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
那么，为什么一定要用3个随机数，来实现'会话密钥'
1> 不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。
2> 由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
3> 对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。
此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。
6.4 服务器的最后响应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
1> 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
2> 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"对通信内容进行加密。
握手协议.png
参考链接
MicroSoft TechNet, SSL/TLS in Detail
Jeff Moser, The First Few Milliseconds of an HTTPS Connection
Wikipedia, Transport Layer Security
StackExchange, How does SSL work?
