SSL/TLS与DTLS

一个大龄程序员
3,361 阅读11分钟

一、概述

SSL最先由Netscape(网景公司)研发，后来ISOC(具体是其中的IETF)接管SSL制定工作，更名为TLS。DTLS(Datagram TLS)是基于UDP的安全传输协议，DTLS作为UDP版本的TLS，具备了同样的安全机制和防护等级，在版本上存在对应关系，如DTLS 1.2版本对应于 TLS1.2。

SSL/TLS发展时间线如下表：f

协议 时间 建议 说明
SSLv1 / / 实际从未公开发布。
SSLv2 1995 弃用 IETF已于2011年弃用。
SSLv3 1996 弃用 IETF已于2015年弃用。
TLSv1.0 1999 兼容 -
TLSv1.1 2006 兼容 -
TLSv1.2 2008 主推 目前最新可用版本
TLSv1.3 / / 2016开始草案制定

SSL/TLS在TCP/IP网络结构中所处位置(http应用层和tcp网络层之间的可选层)：

SSL/TLS处于网络层和应用层之间

SSL/TLS的出现是为了解决http传输中的安全风险，包括：

  • 1).窃听风险（eavesdropping）：第三方可以获知通信内容。
  • 2).篡改风险（tampering）：第三方可以修改通信内容。
  • 3).冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS是为了解决上述三种风险，希望达到以下目标：

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

二、技术原理

0.术语

  • RSA:非对称加密，通过交换密钥来完成，目前在TLS中使用还比较多，详见RSA算法百科
  • DH:Diffie-Hellman算法，非对称加密，无需交换密钥，前向安全性更高。
    DH计算公式
  • PRF(Pseudo-Random Functions):伪随机函数，用于生成伪随机数。
  • client random: 客户端随机数，是一个 32B 的序列值，每次连接来时，都会动态生成，即，每次连接生成的值都不会一样。因为，他包含了 4B 的时间戳和 28B 的随机数。
  • server random: 服务端随机数，和 client random 一样，只是是由 server 端生成。
  • premaster secret: 客户端用公钥加密的第三个随机数，这是 48B 的 blob 数据。它能和 client & server random 通过 pseudorandom (PRF) 一起生成 session key。
  • master secret:由client random、server random、premaster secret一起产生的密钥， master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)。注意master secret和session key还不是一回事，master secret是用来生成session key的。
  • session key: 对话密钥，这是 TLS/SSL最后协商的结果，用来进行对称加密，是key material的一部分。包括6个部分：client_write_MAC_key, server_write_MAC_key, client_write_key, server_write_key, client_write_IV, server_write_IV。如果加密的方法使用stream cipher，则不需要client/server_write_IV。
  • cipher suite: 用来定义 TLS 连接用到的算法。

TLS连接中常用的算法通常有 4 部分：

  1. 非对称加密 (ECDH 或 RSA)
  2. 证书验证 (证书的类型)
  3. 保密性 (对称加密算法)
  4. 数据完整性 (产生 hash 的函数)

比如 AES128-SHA 代表着：

RSA 算法进行非对称加密
RSA 进行证书验证
128bit AES 对称加密
160bit SHA 数据加密算法

比如 ECDHE-ECDSA-AES256-GCM-SHA384 代表着:

ECDHE 算法进行非对称加密
ECDSA 进行证书验证
265bit AES 对称加密
384bit SHA 数据加密算法：
  • Forward Secrey:前向保密/前向安全性,当前密钥只能保护和解密当前会话信息。如果你的 private key 能够用来破解以前通信的 session 内容，这种情况就是 non-forward-secrey。那如何做到 FS 呢？ 很简单，上文也已经提到过了，使用 DH 加密方式即可。因为，最后生成的 sessionKey 和 private key 并没有直接关系，premaster secret 是通过 g(ab) mod P 得到的。
  • NPN:由server 端告诉 client，它支持什么协议，然后 client 确认支持的协议后，开始进行连接
  • ALPN:Application Layer Protocol Negotiation（应用层协议协商机制），由 client 告诉 server，它所支持的所有协议，然后开始进行连接。
  • SNI：Server Name Indication，同一服务器上不同证书的区分。
  • Session ID：server 将上一次成功连接的 session 内容存在自己的硬盘里面（并对每个session设置了过期时间）。在客户端发送session data到服务端后，服务端检查自己缓存里是否有这个session id，如果有则直接使用已有的session id。可以减少网络延迟，降低服务器计算压力。此时TLS握手流程如下图：
    利用已有的session id
  • Session Ticket:实现Session ID同样的事情，server 将最新一次的 sesion data 通过二次加密，在上一次握手结束时传递过去，然后 client 将传递过来的信息保存。 这样，利不利用缓存的 session data 这时，就取决于 client。Session Ticket的方式相对于Session ID,减少了存储空间，但增加了计算。
  • 数字证书：根证书就是CA证书，SSL/TLS中将公钥存储在数字证书中，见数字证书。

1.SSL/TLS加密机制

通过公钥加密法，其中公钥存储在数字证书中防止被篡改实现信息内容加密，而公钥是使用非对称加密算法生成，由于计算量非常大，只用来加密“对话密钥”。每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快。“公钥+对话密钥”的机制解决了安全与计算速度两个问题。

2.SSL/TLS运行机制

  • 1).客户端向服务器端索要并验证公钥。
  • 2).双方协商生成"对话密钥"。【至此为握手阶段】
  • 3).双方采用"对话密钥"进行加密通信。

三、协议详情

1.SSL/TLS协议内容

从协议内部的功能层面上来看，SSL/TLS 协议可分为两层：

  1. SSL/TLS 记录协议（SSL/TLS Record Protocol），它建立在可靠的传输层协议（如 TCP）之上，为上层协议提供数据封装、压缩、加密等基本功能。
  2. SSL/TLS 握手协议（SSL/TLS Handshake Protocol），它建立在 SSL/TLS 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等初始化协商功能。

2.SSL/TLS认证方式

从协议使用方式来看，又可以分成两种类型：

  1. SSL/TLS 单向认证，就是用户到服务器之间只存在单方面的认证，即客户端会认证服务器端身份，而服务器端不会去对客户端身份进行验证。首先，客户端发起握手请求，服务器收到握手请求后，会选择适合双方的协议版本和加密方式。然后，再将协商的结果和服务器端的公钥一起发送给客户端。客户端利用服务器端的公钥，对要发送的数据进行加密，并发送给服务器端。服务器端收到后，会用本地私钥对收到的客户端加密数据进行解密。然后，通讯双方都会使用这些数据来产生双方之间通讯的加密密钥。接下来，双方就可以开始安全通讯过程了。
  2. SSL/TLS 双向认证，就是双方都会互相认证，也就是两者之间将会交换证书。基本的过程和单向认证完全一样，只是在协商阶段多了几个步骤。在服务器端将协商的结果和服务器端的公钥一起发送给客户端后，会请求客户端的证书，客户端则会将证书发送给服务器端。然后，在客户端给服务器端发送加密数据后，客户端会将私钥生成的数字签名发送给服务器端。而服务器端则会用客户端证书中的公钥来验证数字签名的合法性。建立握手之后过程则和单向通讯完全保持一致。

3.SSL/TLS握手过程

SSL/TLS握手过程如下图：

SSL/TLS握手过程

1).客户端发出请求（ClientHello）

客户端在请求中包含以下信息：

（1） 支持的协议版本，比如TLS 1.0版。
（2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。【注：随机数1】
（3） 支持的加密方法，比如RSA公钥加密。
（4） 支持的压缩方法。
（5） TLSv1.1中开始支持Server Name Indication扩展，用于区分同一服务器上不同网站的证书

2).服务器回应（SeverHello）

服务器的回应包括信息如下：

（1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
（2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。【注：随机数2】
（3） 确认使用的加密方法，比如RSA公钥加密。
（4） 服务器证书。
（5） 如服务端要求认证客户端身份，则在SeverHello中要求对方提供证书

3).客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。 如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

（1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。【注：随机数3,被加密后称为Pre Master Secret】
（2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
（4） 如果服务端要求了客户端证书，则此步增加客户端证书。

以上握手过程中一共注明了3个伪随机数的产生，生成伪随机数使用PRF(Pseudo-Random Function)，这三个伪随机数将用约定的加密方法生成对话密钥。很显然，3个随机数的拼接会让整个对话密钥被猜测破解难度显著增大。

4).服务器最后的回应

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

从此以后，双方进入正式通信阶段，所有信息都使用Master Secret加密，这个Master Secret就是对话密钥。

4.SSL/TLS中的密钥

上面术语部分提到了很多密钥，其中客户端随机数、服务端随机数的产生较为简单，但premaster secret、master secret、session key的产生比较复杂。 整个SSL/TLS中密钥产生流程：

如图是网上整理的premaster secret产生master secret过程：
premaster to master

5.DTLS协议

DTLS协议中的header,与TLS协议相比增加了一些字段：

struct {

        HandshakeType msg_type;

        uint24 length;

        uint16 message_seq;  // New field,用于包序验证

        uint24 fragment_offset; // New field，握手消息分段

        uint24 fragment_length; // New field，消息分段长度

        select (HandshakeType) {

          case hello_request: HelloRequest;

          case client_hello:  ClientHello;

          case hello_verify_request: HelloVerifyRequest;  // New type，新增的服务端认证

          case server_hello:  ServerHello;

          case certificate:Certificate;

          case server_key_exchange: ServerKeyExchange;

          case certificate_request: CertificateRequest;

          case server_hello_done:ServerHelloDone;

          case certificate_verify:  CertificateVerify;

          case client_key_exchange: ClientKeyExchange;

          case finished:Finished;

        } body;

   } Handshake;

握手流程：

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

   ClientHello             -------->                           Flight 1

                           <-------    HelloVerifyRequest      Flight 2

   ClientHello             -------->                           Flight 3

                                              ServerHello    \
                                             Certificate*     \
                                       ServerKeyExchange*      Flight 4
                                      CertificateRequest*     /
                           <--------      ServerHelloDone    /

   Certificate*                                              \
   ClientKeyExchange                                          \
   CertificateVerify*                                          Flight 5
   [ChangeCipherSpec]                                         /
   Finished                -------->                         /

                                       [ChangeCipherSpec]    \ Flight 6
                           <--------             Finished    /

可以看到整体流程与TLS一致，但增加了HelloVerifyRequest。header结构体中有包序和消息分段处理相关的字段。

与TLS协议的异同【不一定准确，汗。。。】：

特征 TLS DTLS
网络层 TCP,可靠传输 UDP,不可靠传输
自定义包序 无 有，握手阶段的消息含序列号
重传包检测 无 有，bitmap维护已收到的数据包并检测重复包
握手消息包体积限制 基本没有 小于MTU
握手消息分段 无 有
加密算法 多 少，不支持RC4流式加密
会话恢复 有 有
错误处理 直接丢弃连接 丢包重传，超时处理

四、应用

TLS一般都在https中，DTLS则在UDP传输协议上使用。

五、参考

avatar
文章
阅读
粉丝