TLS过程解读分享

TLS过程解读分享

HTTP和HTTPS区别

HTTP和HTTPS的主要区别如下包括:HTTPS协议需要到CA申请证书,而HTTP协议则不用；HTTP是超文本传输协议，信息是明文传输，而HTTPS则是加密传输；HTTP和HTTPS使用完全不同的连接方式，所占用的端口也不一样，前者占用80端口，后者占用443端口；HTTPS传输过程比较复杂，对服务端占用的资源比较多，由于握手过程的复杂性和加密传输的特性导致HTTPS传输的效率比较低；HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

image-20200102173351877

基本概念

• SSL（Secure Socket Layer，安全套接字层）

  位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

  • TLS(Transport Layer Security，传输层安全协议)

    用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

    • TLS是在SSL的基础上标准化的产物，目前SSL3.0与TLS1.0保持一致，二者是并列关系。

      SSL/TLS位于传输层和应用层之间，应用层数据不再直接传递给传输层，而是传递给TLS层，TLS层对从应用层收到的数据进行加密，并增加自己的TLS头。

      TLS设计目标

      TLS的设计目标是构建一个安全传输层（Transport Layer Security ），在基于连接的传输层（如tcp）上提供：

      • 保密性，message privacy (保密通过加密encryption实现，所有信息都加密传输，第三方无法窃听 )

      • 完整性，message integrity（ 通过MAC校验机制，一旦被篡改，通信双方会立刻发现 ）

      • 认证， mutual authentication （双方认证，双方都可以配备证书，防止身份被冒充 ）

      • 互操作、通用性 （ 根据公开的rfc，任何符合rfc的软件实现都可以互操作，不受限于任何专利技术）

      • 可扩展性 ( 通过扩展机制 tls_ext可以添加功能，有大量的新功能，都是通过扩展添加的)

      • 高效率 （通过session cache，恰当部署cache之后，tls的效率很高）

      TLS发展历史

      • 1995: SSL 2.0, 由Netscape提出，这个版本由于设计缺陷，并不安全，很快被发现有严重漏洞，已经废弃。

      • 1996: SSL 3.0. 写成RFC，开始流行。目前(2015年)已经不安全，必须禁用。

      • 1999: TLS 1.0. 互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

      • 2006: TLS 1.1. 作为 RFC 4346 发布。主要fix了CBC模式相关的如BEAST攻击等漏洞。

      • 2008: TLS 1.2. 作为RFC 5246 发布 。增进安全性。目前(2015年)应该主要部署的版本。

      • 2015之后: TLS 1.3，还在制订中，支持0-rtt，大幅增进安全性，砍掉了aead之外的加密方式。

      由于SSL的2个版本都已经退出历史舞台了，所以本文后面只用TLS这个名字。 一般所说的SSL就是TLS。

      一些需要了解的名词

      密码套件（cipher suite）

      密码套件（Cipher suite）是传输层安全（TLS）/安全套接字层（SSL）网络协议中的一个概念。在TLS 1.2中，密码套件的名称是以协商安全设置时使用的身份验证、加密、消息认证码（MAC）和密钥交换算法组成。TLS 1.3中的密码套件格式已经修改。在目前的TLS 1.3草案文档中，密码套件仅用于协商加密和HMAC算法。在创建一个TLS连接后，一次也称TLS握手协议的握手发生。在这个握手，一条ClientHello和一条ServerHello消息被发出。首先，客户端按照偏好的顺序发送它支持的密码套件的列表。然后服务器回复它从客户端的列表中选择的密码套件。

      TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，它表示，密钥交换算法使用ECDHE（短暂椭圆曲线），身份认证算法使用RSA，对称加密算法使用AES_128_CBC，摘要算法使用SHA256。

      对称加密

      传统加密技术，也称为传统加密技术，是一种只使用一个密钥进行加密和解密的技术。例如，DES，Triple DES算法，IBM的MARS，RC2，RC4，RC5，RC6。

      非对称加密

      使用一对密钥进行加密的公钥加密：用于加密数据的公钥和用于解密的私钥。公钥发布给人们，但保密私钥。例如，RSA，数字签名算法(DSA)，Elgamal。

      原理

      下图为TLS握手的大致流程：

      image-20191231140243667

      抓包分析

      所有的握手包

      image-20191231141927468

      C：Client Hello报文解读

      我们需要关注的是Secure Sockets Layer,即安全套接字层

      image-20191230152727043

      客户端把自己所支持的加密套件全部发送给服务器，服务器会从中选择一个加密套件。这个我们将在后面的Server hello中讲到。

      每个加密套件用2字节表示，这里一共23个加密套件，所以理所当然的，Cipher Suits Length是23 * 2 = 46字节。

      image-20191230153127244

      Extension

      拓展字段的存在，是因为SSL协议起草之初有些功能没有考虑到，后续这些功能被加进RFC，而为了兼容SSL，把这些功能的描述放到Extension中。Extension很大程度上影响了SSL的流程，很多人觉得某些SSL连接的报文好奇怪、和正常接触的SSL报文不一样，就是因为Extension起的作用。

      TLS 1.3 就借助 extension 发送不同curve的pubkey来减少RTT，后续有机会再说。这里介绍主流的一些拓展。

      （1）Renegotiation info：

      如果是重新协商（即加密的hello），那么会带上上次协商的12字节的finished，如果是新hello请求，那么里面字段为0。

      切记及时服务器端不支持renegotiation，在server hello响应时也需要带上这个拓展（前提是客户端有这个拓展或者有等价的EMPTY_SCSV，因为我在实现上碰到过如果不带该拓展，导致客户端结束连接的情况）。

      （2）Server_name(SNI):

      SSL存在验证证书的时候，有这么一个判断：比较“浏览器输入的地址”和“获取的证书的名称”，如果一样，那么接着验证，如果不一样，那么认为证书是不可信的。

      假设有公司的域名存在2个：[www.123.com](file:///Users/zhengxq/Desktop/www.123.com)和[www.567.com](file:///Users/zhengxq/Desktop/www.567.com)，它们对应的ip都是222.12.34.56，假设服务证书的名字是 ”[www.123.com](file:///Users/zhengxq/Desktop/www.123.com)” ，那么从 ”[www.567.com](file:///Users/zhengxq/Desktop/www.567.com)” 访问过来的用户无法信任服务器证书，总之，总有一个域名访问会导致客户端无法信任服务器。为了解决这个问题，客户端在client hello中带上server name 拓展（如果使用ip地址进行访问，那么就不会有server name拓展），它会捎带上域名地址，服务器解析到server name后，就会根据server name中的域名，选择合适的证书。

      S：服务端 server Hello总报文

      image-20191230153916532

      S：Server Hello报文解读

      image-20191231143527398

      S：Certificate报文解读

      证书格式

      image-20191231150710889

      • 验证有效期

      • 验证域名domain 等

      image-20191230163302440

      S：Server key Exchange报文解读

      image-20191231111706420

      S：Server Hello Done

      image-20191230165729209

      C：Client Key Exchange报文解读

      验证证书

      image-20191231150757532 image-20191231112715526

      C：Change Cipher Spec报文解读

      image-20191230170809910

      注意：这个时候session key 已经协商出来了session key =Fuc(random_C, random_S, Pre-Master)

      C：Encryted Handshake Message报文解读

      client发送的encrypted handshake message加密数据非常关键。

      一是能证明握手数据没有被篡改过，二也能证明自己确实是密钥的拥有者(这里是单边验证，只有server有certificate，server发送的Finished能证明自己含有private key，原理是一样的)。

      image-20191231112854305

      S：Change Cipher Spec报文解读

      这个时候session key 已经协商出来了session key =Fuc(random_C, random_S, Pre-Master)

      image-20191231114450509

      S：Encryted Handshake Message报文解读

      image-20191231131147314

      最后温习一遍

      image-20200102173136878

      会话标识 session ID 的作用

      • 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中;

      • 如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器;

      image-20191231152901142

      • 服务器根据收到的 session ID 检索缓存记录，如果没有检索到货缓存过期，则按照正常的握手过程进行;

      • 如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，发送一个用之前的session key进行加密的数据发送给客户端

      image-20191231153131034
      • 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息;
      image-20191231153202691
      • 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

      会话记录 session ticket的作用

      • 如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的 session_ticket 信息，客户端保存;

      • 如果客户端再次需要和该服务器建立连接，则在 client_hello 中扩展字段 session_ticket 中携带加密信息，一起发送给服务器;

      • 服务器解密 sesssion_ticket 数据，如果能够解密失败，则按照正常的握手过程进行;

      • 如果解密成功，则返回 change_cipher_spec 与 encrypted_handshake_message 信息，两个信息作用与 session ID 中类似;

      • 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec与encrypted_handshake_message 信息;

      • 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

      参考链接

      1. https://www.cnblogs.com/huanxiyun/articles/6554085.html

      2. https://blog.csdn.net/hherima/article/details/52469488

      3. https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

      4. https://www.cnblogs.com/20179204gege/p/7858070.html