TLS/SSL基础介绍

Transport Layer Security（TLS）和它早期版本Secure Sockets Layer（SSL）为网络加密协议，TLS协议是在SSL协议的基础上进行改进升级，他们主要用于在计算机网络上提供通信安全。其早期一些版本被广泛使用于web浏览器、email、即时通信、VoIP等。web网站通过该协议能够保证浏览器于服务器之间的安全通信。

SSL/TLS协议主要提供通信过程数据的保密性和完整性，在客户端与服务端通信过程中，主要包括以下几点：

• 通信数据保密性：主要防止数据被第三方截获查看。SSL/TLS协议采用对称加密算法，实现对传输内容的加密，而针对对称加密所需的密钥，则通过协议通信过程中的handshake过程，实现对称加密密钥的协商，同时，该过程也包括协商加密的算法。这个协商过程不同版本的协议，方法也存在一定的差异，需要注意。
• 通信双方身份认证：根据不同版本的SSL/TLS协议，其采用的身份认证方式、认证对象也存在不同，关于认证方式包括基于非对称加密的身份认证和基于证书的身份认证，而认证对象也分为单向认证（只认证服务端）和双向认证(客户端和服务端双向认证)
• 通信数据的可靠性（即完整性）：协议通过Message Athenticaiton Code（MAC）消息认证码，来防止数据的篡改，以保证其真实完整。

SSL/TLS协议支持多种不同的密钥交换、数据加密和数据完整性认证方法，具体内容后面将会讲述。

 

一、SSL/TLS协议组成

协议由两层构成：TLS Record Protocol和TLS Handshake Protocol。协议栈如下图所示

TLS Record Protocol处于较低的一层，基于可信任的协议之上，如TCP，为高层协议提供数据封装、压缩、加密等基本功能的支持。它保证了通信的两个基本安全属性：

• 保密连接。数据传输使用对称加密算法，如AES，RC4等。该对称加密算法的密钥对于每个连接是唯一的，基于密钥协商协议生成，比如TLS handshake protocol，Record Protocol也可以不使用加密。

• 可信连接。消息的传输包括了基于密钥的消息认证码（keyed MAC），使用安全Hash函数计算MAC，用于完整性检查。Record Protocol也可以不使用MAC，但是这种模式只用于安全参数协商时。

Record Protocol用于封装多种高层的协议，其中一个种就是TLS handshake protocol，这种协议允许客户与服务器相互认证，在应用程序通信前，协商加密算法和加密密钥。TLS handshake protocol保证了连接的三个基本安全属性：

• 两端的身份可以通过非对称或者公钥加密算法（DSA，RSA等）进行认证。认证过程是可选的，但至少要求一端被认证。
• 共享密钥的协商是安全的。密钥协商对于监听者和任何被认证的连接都是不可见的。
• 协商是可信的。攻击者无法修改协商信息。

TLS协议对数据的封装如下图所示：

 

二、SSL/TLS协议发展历史

Netscape设计了SSL协议原型，SSL1.0由于存在严重漏洞，因此没有发布；在1995你那SSL2.0发布，但其仍然存在许多安全问题，对此，在1996年发布了SSL3.0。其中Taher Elgamal被称作“SSL之父”。在2014年，SSL3.0被发现漏洞，能够遭受POODLE攻击，其影响所有组加密算法。随后，在2011年，RFC停止SSL2.0的更新，在2015年7月，停止对SSL3.0的更新。

TLS 1.0   首次于1999年进行定义，作为SSL3.0的升级版，但其余SSL3.0差别不是很大，但TLS 1.0包含一种方法，通过该方法，TLS实现可以将连接降级到SSL 3.0，从而削弱安全性。

TLS1.1  于2006年4月发布，他是TLS1.0版本的升级，其余TLS1.0版本的不同包括：

              1.增强了对CBC模式攻击的防护

              2.支持IANA参数注册

TLS1.2  于2008年8月发布，他是基于TLS1.1版本的升级，其修改内容包括：

             1.伪随机函数（PRF）中的MD5-SHA-1组合被SHA-256替换，可选择使用密码套件指定的PRF

             2.已完成的消息hash的MD5-SHA-1组合已替换为SHA-256，并且可以选择使用密码套件特定的散列算法，另                                    外，在完成消息hash的大小至少为96bit。

             3.数字签名元素中的MD5-SHA-1组合被替换为握手期间协商的单个哈希值，默认为SHA-1。

             4.增强客户端和服务器指定接受哪些哈希值和签名算法的能力

             5.扩展对经过身份验证的加密密码的支持，主要用于Galois / Counter Mode（GCM）和CCM模式的高级加密标                               准 （AES）加密

             6.添加了TLS扩展定义和AES密码套件

在2011年，所有TLS版本重新修订，移除了与SSL向后兼容性，以便TLS会话永远不会协商使用安全套接字层（SSL）2.0版。

TLS 1.3  于2018年8月发布，是在TLS1.2版本基础上升级，做了大量修改：

             1.将密钥协议和身份验证算法与密码套件分开

             2.删除对弱和较少使用的命名椭圆曲线的支持

             3.删除对MD5和SHA-224加密哈希函数的支持

             4.即使使用先前的配置，也需要数字签名

             5.整合HKDF和半短暂的DH提案

             6.支持1-RTT握手和0-RTT的初始支持

             7.Replacing resumption with PSK and tickets

            8.通过在（EC）DH密钥协议期间使用短暂密钥来强制完美的前向保密

            9.删除对许多不安全或过时功能的支持，包括压缩，重新协商，非AEAD密码，非PFS密钥交换（其中包括静态                                RSA和静态DH密钥交换），自定义DHE组，EC点格式协商，Change Cipher Spec协议， Hello消息UNIX时                                  间，以及输入到AEAD密码的长度字段AD

           10.禁止SSL或RC4协商以实现向后兼容性

           11.集成使用会话哈希

           12.弃用记录层版本号并冻结该数字以提高向后兼容性

           13.使用Poly1305消息验证代码添加ChaCha20流密码

           14.添加Ed25519和Ed448数字签名算法

           15.添加x25519和x448密钥交换协议

 

三、SSL/TLS协议具体简述

SSL/TLS协议RSA模式密钥交互简单流程介绍（需说明：下图非SSL/TLS标准过程图，也非作者原创，纯属网络参考）

1. 客户端发起会话，与支持SSL/TLS协议的服务器通信，其发送内容包含问候数据、客户端random和其所支持的加密套件（密钥协商算法、对称加密算法和MAC算法）等
2. 服务器接收相关信息后，响应相关请求，发送选择的加密套件信息、server random和公钥证书，进行身份验证等。
3. 客户端收到服务器相关响应后，对其进行身份验证，验证通过后，根据协商的加密套件信息，计算得到Premaster secret，并用服务端的公钥进行加密，并传递给服务端，其中Premaster secret用于会话密钥的生成。
4. 客户端发送ChangeCipherSpec record，主要用于验证服务端是否生成的密钥与自己产生的密钥相同。客户端将发送一个认证和加密的前面握手交互信息（Finished message）其中主要包括一个哈希值和MAC，如果服务器收到并验证通过，则以同样的方式验证客户端，如果验证不通过，则会话结束。
5. 当客户端和服务端验证所产生的密钥相同时，握手阶段完成，接着为数据内容传输。

安全性分析

Client Random 和 Server Random 明文传输,中间人可以直接查看。客户端生成 Premaster Secret 后,用服务端证书公钥加密后发送,如果服务端拥有对应的私钥,就可以成功解密得到 Premaster Secret。这时,客户端和服务端拥有相同的 Client Random、Server Random 和 Premaster Secret,可以各自算出相同的后续所需 Key。,这种方式合并了密钥交换和服务端认证两个步骤,如果服务端能解密 Premaster Secret,也就意味着服务端拥有正确的私钥。中间人没有私钥,无法得到 Premaster Secret,也就无法解密后续流量。对于 Wireshark 来说,配置某个网站的私钥后,能解密这个网站「使用 RSA 进行密钥交换」的加密流量就很容易理解了。 显然,RSA 密钥交换有一个很大的问题:没有前向安全性(Forward Secrecy)。这意味着攻击者可以把监听到的加密流量先存起来,后续一旦拿到了私钥,之前所有流量都可以成功解密。下图为 ECDHE 密钥交换模式流程图

上图中的 Server DH Parameter 是用证书私钥签名的,客户端使用证书公钥就可以验证服务端合法性。相比 RSA 密钥交换,DH 由传递 Premaster Scret 变成了传递 DH 算法所需的 Parameter,然后双方各自算出 Premaster Secret。 

对于这种情况,由于 Premaster Secret 无需交换,中间人就算有私钥也无法获得 Premaster Secret 和 Master Secret。也就是说 Wireshark 无法通过配置 RSA Private Key 的方式解密「使用 ECDHE 进行密钥交换」的加密流量。当然,使用 ECDHE 后,虽然中间人拿到私钥也无法解密之前的流量,但他可以实施 MITM 攻击来解密之后的流量,所以私钥还是要保管好。

相比 RSA 既可以用于密钥交换,又可以用于数字签名;ECC 这边就分得比较清楚了:ECDHE 用于密钥交换,ECDSA 用于数字签名。也就是目前密钥交换 + 签名有三种主流选择: 

• RSA 密钥交换、RSA 数字签名; 
• ECDHE 密钥交换、RSA 数字签名; 
• ECDHE 密钥交换、ECDSA 数字签名;

关于SSL/TLS主要的三个过程：密钥协商过程、数据加密过程、完整性验证过程。所涉及加密算法统计表如下：

• 密钥协商交换算法统计表

• 数据加密算法统计表

• 消息验证码算法统计表

 

四、针对SSL/TLS攻击

1. Renegotiation attack

2. Downgrade attacks: FREAK attack and Logjam attack

3. Cross-protocol attacks: DROWN

4. BEAST attack

5. CRIME and BREACH attacks

6. Timing attacks on padding

7. POODLE attack

8. RC4 attacks

9. Truncation attack

10. Unholy PAC attack

11. Sweet32 attack

12. Implementation errors: Heartbleed bug, BERserk attack, Cloudflare bug

13. 中间人攻击

其中常用的攻击为Renegotiation attack、RC4 attacks、CRIME attack、Heartbleed、ChangeCipherSpec injection attack、POODLE attack against TLS(Original POODLE against SSL 3.0 is not included)、Protocol downgrade

注：本文主要用于个人所搜集资料的整理，并非传播网络攻击教程。

参考：

https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development

https://tools.ietf.org/html/rfc6101

https://tools.ietf.org/html/rfc6176

https://tools.ietf.org/html/rfc2246

https://tools.ietf.org/html/rfc4346

https://tools.ietf.org/html/rfc5246

https://tools.ietf.org/html/rfc8446

https://www.aliyun.com/jiaocheng/163540.html