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 信息;
-
服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
参考链接
-
-
-
网友评论