TLS（Transport Layer Security）传输层安全协议，及其前身SSL（Secure Sockets Layer），都是对网络通信提供安全和数据完整性保证的加密协议。TLS/SSL可以配合其他高层协议使用，如目前互联网中广泛使用的HTTPS协议就是在HTTP协议的基础上搭配使用了TLS/SSL协议以增强其安全性。由于TLS 1.3协议还是草案，本文主要以TLS 1.2协议为基础。
基础知识
- 对称加密（Symmetric-key Cryptography）：加密和解密使用相同的密钥，加密效率高，但是存在密钥管理的问题。
- 非对称加密（Asymmetric-key Cryptography）：又称公开密钥加密（Public-key Cryptography），它需要两个密钥，一个是公钥，另一个是私钥，一个用作加密，另外一个用作解密。相比于对称加密非对称加密性能欠佳，但是私钥的私密性带来了较高的安全性。常用于数据加密和数字签名。
- 数字签名（Digital Signature）：一种用来表明消息或者文档真实性的解决方案。发送者将摘要信息使用发送者的私钥加密，接受者使用发送者的公钥解密。有效的数字签名使接收者相信该消息是由已知的发送者创建的（真实性），发送方不能否认发送消息（不可抵赖性），并且消息在传输中未被更改（完整性）。
- 数字证书（Digital Certificate）：是一种用来证明公钥所有权的电子文档。由认证中心（Certificate Authority）签发。证书中包含了公钥信息、所有者身份信息和已验证证书内容的实体（一般指CA）的数字签名。CA机构的数字签名使得攻击者不能伪造和篡改证书。
- 密码套件（Cipher Suite）：由密钥交换算法、批加密算法、消息认证码（MAC）算法和伪随机函数（PRF）组成。
- MAC（Message Authentication Code）：消息认证码，在密码学中是用来认证消息的信息片段。它可以用来确认消息来自可以真实的发送者并且内容未被篡改，进而保护信息的数据完整性和真实性。由于MAC使用对称加密，密钥在通信方之间是共享的，一方能够验证MAC，就能够生成MAC，所以MAC无法保证消息的不可抵赖性，这也是其和数字签名的一个主要区别。
设计目的
- 增加数据交换的安全性/隐蔽性，防止信息被嗅探
- 引入通信双方的身份认证机制，防止一方被冒充
- 保证传输数据完整性，防止数据丢失或被篡改
协议架构
TLS/SSL协议不能巧妙地整合到OSI模型或者TCP/IP模型的任何单一层中，它运行在一些可靠的传输层协议(如TCP/IP)之上，以增强应用层协议(如HTTP, TELNET, FTP, SMTP等)的安全性。TLS/SSL协议主要由记录协议和握手协议两层组成。
- 握手协议：当客户端和服务端第一次通信时，他们要协商协议版本，选择加密算法，互相认证（可选），并使用非对称加密生成共享密钥。
- 记录协议：使用握手协议协商出来的参数，为高层协议进行数据处理（加/解密、拆分/重组、验证等）。
其中握手协议又包含了三个子协议：
- Handshake Protocol：协商协议版本，选择加密算法，相互认证（可选），使用非对称加密算法生成共享密钥。
- Change Cipher Spec Protocol：通知对端后续的记录将接受新协商的密码规范和密钥的保护，在TLS 1.3中已移除。
- Alert Protocol：用来提示告警级别和告警原因，如错误的MAC、无效的证书等。
协议流程
握手协议
以使用RSA密钥交换为例
- 客户端发送一个“Client Hello”消息、客户端随机数以及支持的密码套件到服务端。
- 服务端选择一个合适的密码套件（此例中密钥交换算法为RSA），发送“Server Hello”消息，同时附带了服务端的随机数以响应客户端。
- 服务端发送证书到客户端以便进行服务端的认证，同时有可能请求客户端证书。服务端发送“Server Hello Done”消息。
- 如果服务端请求了客户端证书，则客户端发送证书到服务端。
- 客户端创建一个随机的预备主密钥（Pre-Master Secret）并且使用服务端证书中的公钥对其进行RSA加密发送给服务端。
- 服务端使用私钥解密得到预备主密钥。服务端和客户端根据之前两个随机数和预备主密钥生成主密钥（Master Secret）。
- 把上述过程中协商好的参数提供给记录层协议，这些参数又被称为安全参数（Security Parameters）。
- 允许客户端和服务端验证它们的对端确实计算出了相同的安全参数并且握手过程没有被攻击者篡改。
记录协议
记录协议对将要发送的数据进行拆分，压缩，附上MAC，加密后对结果进行传输。接受到的数据经过解密，验证，解压，重组，然后被传送给高层协议。
记录协议的这些处理过程依赖于握手过程中生成的安全参数（Security Parameters）：
- 连接端（connection end）：标识客户端或服务端
- 伪随机算法（PRF algorithm）：一个用于从主密钥生成其他密钥的算法
- 批量加密算法（bulk encryption algorithm）：用来对大量数据加解密的对称加密算法
- MAC算法（MAC algorithm）:一种用于消息认证的算法
- 压缩算法（compression algorithm）：用于传输数据的压缩和解压缩
- 主密钥（master secret）:一个连接双方共享的48位密钥
- 客户端随机数（client random）：一个由客户端提供的32位随机数
- 服务端随机数（server random）：一个由服务端提供的32位随机数
记录协议使用上述安全参数计算生成以下六项密钥用于协议过程：
- client write MAC key：客户端使用该密钥生成消息的MAC，服务端使用该密钥对客户端的消息进行认证
- server write MAC key：服务端使用该密钥生成消息的MAC，客户端使用该密钥对服务端的消息进行认证
- client write encryption key：客户端使用该密钥加密消息，服务端使用该密钥解密客户端消息
- server write encryption key：服务端使用该密钥加密消息，客户使用该密钥解密服务端消息
- client write IV：只在AEAD 加密时需要
- server write IV：只在AEAD 加密时需要
密钥交换和认证
密钥交换和认证是整个TLS/SSL协议设计中的核心和难点。下面主要介绍两种密钥交换和认证方式，TLS/SSL协议规范中采纳的方式多为这两者的变种。
RSA密钥交换和认证
RSA是非对称加密，使用RSA密钥交换时，客户端下载服务端的证书并进行验证，验证通过后取得其中存放的服务端公钥，然后用公钥加密预备主密钥，发送到服务端，服务端收到后用自己的私钥解密得到预备主密钥。单纯使用RSA加密可以防止网络数据的嗅探但是无法防止网络数据的篡改，所以引入CA进行服务端的认证时很有必要的，可以有效地防止中间人攻击（Man-in-the-middle attack）。
Diffie–Hellman密钥交换和认证
Diffie–Hellman密钥交换是一种在公共信道下安全地交换密钥的一种方法。使用DH密钥交换时，客户端无法独立创建预备主密钥，由于DH算法的特性，服务端需要生成算法参数以参与预备主密钥的生成。为了避免中间人攻击，服务端可以提供包含固定算法参数的证书，也可以通过Server Key Exchange Message发送使用DSA或RSA证书私钥签名的临时算法参数。
FAQ
1.在握手协议中为什么要生成两个随机数，而不直接使用预备主密钥？
直接使用预备主密钥若被攻击者窃取到，虽然预备主密钥被加密，攻击者无法破解其明文信息，但攻击者仍然可以利用其进行重放攻击（Replay Attack），重放握手阶段以欺骗服务器，接着重放截取到的用户请求达到攻击目的（如欺骗服务器完成身份认证）。使用客户端和服务端随机数再加上预备主密钥生成主密钥，可以使握手过程的密钥生成不完全依赖于客户端。即使预备主密钥和客户端随机数被截获，攻击者也无法完成重放攻击，因为重新发起的握手阶段会导致服务器生成新的随机数，此次得到的主密钥与被窃听会话的主密钥必然不同，由主密钥计算得到的MAC密钥和加密密钥也必然不同，进而可以有效地防止攻击者欺骗服务器。