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的修订版，在2018年也发布了TLS1.3版本。

TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的了

SSL/TLS协议的基本过程（TLS1.2）

客户端向服务器端索要并验证公钥。

双方协商生成"对话密钥"。

双方采用"对话密钥"进行加密通信。

上面过程的前两步，又称为"握手阶段"（handshake）

下面是我们本次模拟访问时抓的包，大家可以看到这里面涉及的流程逻辑

1 客户端发出请求（ClientHello）

（1） 支持的协议版本，比如TLS 1.2版。

（2） 一个客户端生成的随机数1，稍后用于生成"对话密钥"。

（3） 【支持的密码套件】支持的加密方法，比如RSA公钥加密。

（4） 支持的压缩方法。

（5） 一个session id，标识是否复用服务器之前的tls连接（需要服务器支持）

2 服务器回应（SeverHello）

（1） 确认使用的加密通信协议版本，比如TLS 1.2版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。

（2） 一个服务器生成的随机数2，稍后用于生成"对话密钥"。

（3） 【确认密码套件】确认使用的加密方法，比如RSA公钥加密，此时带有公钥信息。

（4） 一个session id（若同意复用连接）

3 服务器回应（Server Certificate）

（1）服务器证书（该证书即包含服务器公钥）。

4 服务器回应（Server Key Exchange）

（1）服务器算法变更通知，服务端给客户端一个用于 ECDHE 算法的公钥

5 服务器回应（Server CertificateRequest）

（1）请求客户端证书，此案例中没有，一般银行等需要客户端也加密的才有，比如 U 盾。

6 服务器回应（Server ServerHelloDone）- 标识着 serverHello 这个握手过程结束了。

7 客户端回应（Client Certificate）- 回应客户端证书，本案例不涉及

8 客户端回应（ClientKeyExchange）

（1）客户端在验证完服务器的证书后，生成一个新的随机数（pre_master），通过服务器的公钥加密后发给服务器。

到这里，服务端与客户端将 生成最终通信的对称加密秘钥：master_secret

计算过程根据上面得到的三个随机数：

随机数 1（客户端随机数）：在 ClientHello 消息里，由客户端生成的随机数1

随机数 2（服务端随机数）：在 ServerHello 消息里，由服务端生成的随机数2

随机数 3（pre_master)：通过秘钥交换算法 ECDHE 计算出的，我们叫它 pre_master。

最终的对称加密秘钥 master_secret，就是根据这三个随机数共同计算出来的。

9 客户端回应（Client CertificateVerif）

（1）验证客户端证书有效性，本次不涉及

10 客户端回应（Client ChangeCipherSpec）

（1）秘钥改变通知，此时客户端已经生成了 master_secret，之后的消息将都通过 master secret 来加密。

11 客户端回应（Client Finish）

（1） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

12 服务器回应（Server ChangeCipherSpec）

（1）秘钥改变通知，此时服务端也已经生成了 master_secret 了，后面的通信都用此值加密。

13 服务器回应（Server Finish）

（1）同 Client Finish，服务器端发送握手结束通知，同时会带上前面所发内容的hash签名到客户端，保证前面通信数据的正确性。

上述流程简易版（不包含验证客户端证书）：

1. client --> server ClientHello

客户端生成随机数，并发送一组密码学套件供服务端选

2. server--> client ServerHello

服务端生成随机数，并从上述密码学套件组里选一个

3. server--> client Certificate

服务端发给客户端证书

4. server--> client ServerKeyExchange

服务端发给客户端秘钥交换算法所需的值

5. server--> client ServerHelloDone

服务端 hello 阶段结束

6. client --> server ClientKeyExchange

客户端发给服务端秘钥交换算法所需的值pre_master

7. client --> server ChangeCipherSpec

客户端告诉服务端，我已经知道秘钥了，之后的消息我就都加密发送了。

8. client --> server Finish

结束并验证

7. server --> server ChangeCipherSpec

服务端告诉客户端，我已经知道秘钥了，之后的消息我就都加密发送了。

9. server--> client Finish

结束并验证

图片流程

为什么一定要用三个随机数，来生成"会话密钥"呢？

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机数，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

以上介绍为TLS1.2的版本，其他TLS如1.0版本的流程会稍有不同，但大致逻辑是一样的。

TLS 1.2 转换流程逻辑也可以参考：26 | 信任始于握手：TLS1.2连接过程解析-极客时间

更新的 TLS 1.3也可以参考：27 | 更好更快的握手：TLS1.3特性解析-极客时间

TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：

　　1）更安全的MAC算法

　　2）更严密的警报

　　3）“灰色区域”规范的更明确的定义

TLS对于安全性的改进点如下（了解即可）：

1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

SSL/TLS 密码套件

浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。上述Client/Server Hello过程中就涉及密码套件的约定流程。

TLS 的密码套件命名格式为：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法

如对于套件：“ECDHE-RSA-AES256-GCM-SHA384”，其解释为：握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。

HTTPS很安全，很古老也很成熟，为什么一直到今天我们还有66%的网站不支持HTTPS呢？

1、慢，HTTPS未经任何优化的情况下要比HTTP慢几百毫秒以上，特别在移动端可能要慢500毫秒以上，关于HTTPS慢和如何优化已经是一个非常系统和复杂的话题

2、贵，特别在计算性能和服务器成本方面。HTTPS为什么会增加服务器的成本？相信大家也都清楚HTTPS要额外计算，要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本

另外还有:

1、大量的计算。SSL的每一个字节都涉及到较为复杂的计算。即使是clientHello，也需要在握手完成时做校验。

2、TLS协议的封装和解析。HTTPS所有数据都是按照TLS record格式进行封装和解析的。

3、协议的网络交互。从TLS的握手过程可以看出，即使不需要进行任何计算，TLS的握手也需要至少1个RTT（round trip time)以上的网络交互。

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

4、HTTPS降低用户访问速度（需多次握手）

5、网站改用 HTTPS 以后，由 HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用 301、302 跳转）

6、HTTPS 涉及到的安全算法会消耗 CPU 资源，需要增加服务器资源（https 访问过程需要加解密）