2 SSL/TSL 运行机制

SSL/TLS 运行机制

互联网的通信安全，建立在 SSL/TLS 协议之上。

1 作用

不使用 SSL/TLS 的 HTTP 通信，就是不加密的通信。所有信息明文传播，带来了以下3大风险。

1. 窃听风险：第三方可以获知通信内容
2. 篡改风险：第三方可以修改通信内容
3. 冒充风险：第三方可以冒充他人身份参与通信

SSL/TLS 协议就是为了解决这3大风险而设计的，希望达到：

1. 所有信息都是加密传输的，第三方无法窃听
2. 具有校验机制，一旦被篡改，通信双发就会立即发现
3. 配备身份证书，防止身份被冒充

2 历史

互联网加密通信协议的历史，几乎与互联网一样长。

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的修订版。

目前，应用最广泛的是 TLS1.0，接下来是 SSL4.0，但是主流的浏览器都已经实现了 TLS1.2 的支持。（TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3）

3 基本运行过程

SSL/TLS 协议的基本思路是采用公钥加密罚，也就是说，client 现象 server 索要公钥，然后用公钥加密信息，服务器收到加密文件后，用自己的私钥解密。

但，这里有2个问题。

1. 如何保证公钥不被篡改

解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。

1. 公钥加密计算量太大，如何减少耗时

每一次对话（session），client 和 server 都会生产一个 “对话密钥” （session key），用它来加密信息。由于 “对话密钥” 是对称加密，所以运算速度非常快，而服务器公钥只用于加密 “对话密钥” 本身，这样就减少了加密运算的耗时。

因此，SSL/TLS 协议的基本过程就是以下这样的：

1. client 向 server 索要并验证公钥
2. 双方协商生成 “对话密钥”
3. 双方采用 “对话密钥” 进行加密通信

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

4 handshake 过程详解

handshake 所有的通信都是明文的

4.1 客户端发出请求

首先，client（通常是浏览器）先向 server 发出加密通信的请求。

在这一步，client 主要向 server 提供以下信息：

1. 支持的协议版本，如 TLS 1.0 版
2. 一个 client 生产的随机数，稍后用于生产 “对话密钥”
3. 支持的加密方法，比如 RSA 公钥加密
4. 支持的压缩方法

这里需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。

4.2 服务器回应

server 收到 client 请求后，向 client 发出回应，回应包括了一下内容：

1. 确认使用的加密通信协议版本。如果协议版本不一致，则 server 关闭加密通信
2. 一个 server 生成的随机数，稍后用于生成 “对话密钥”
3. 确认使用的加密方法，比如 RSA 公钥加密
4. 服务器证书

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

4.3 客户端回应

client 收到 server 回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，client 就会从证书中取出 server 的公钥，然后向 server 发送以下信息：

1. 一个随机数，改随机数会用 server 公钥加密，防止被窃听
2. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
3. client 握手结束通知，表示 client 的握手阶段已经结束。这一项同时也是前面发送的所有内容的 hash 值，用来供 server 校验。

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。

4.4 服务器的最后回应

server 收到 client 的第三个随机数 pre-master key 之后，计算本次回话生成的 “会话密钥”。然后，向 client 最后发送下面信息：

1. 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
2. 服务器握手结束通知，表示服务器的握手阶段已经结束，这一项同时也是前面发送的所有内容的 hash 值，用来供 client 端校验。