文前说明

作为码农中的一员，需要不断的学习，我工作之余将一些分析总结和学习笔记写成博客与大家一起交流，也希望采用这种方式记录自己的学习之旅。

本文仅供学习交流使用，侵权必删。
不用于商业目的，转载请注明出处。

1. SSL/TLS

• SSL 是一个介于 HTTP 协议 与 TCP 协议 之间的一个可选层。
• 不使用 SSL/TLS 的 HTTP 通信，就是不加密的通信，信息明文传播会有以下风险。
  • 窃听风险（eavesdropping）第三方可以获知通信内容。
  • 篡改风险（tampering）第三方可以修改通信内容。
  • 冒充风险（pretending）第三方可以冒充他人身份参与通信。
• SSL/TLS 协议是为了解决这三大风险而设计。
  • 所有信息都是 加密传播，第三方无法窃听。
  • 具有 校验机制，一旦被篡改，通信双方会立刻发现。
  • 配备 身份证书，防止身份被冒充。
• 安全套接字层（Secure Socket Layer，SSL），为 Netscape 所研发，用以保障在 Internet上 数据传输安全。
  • 利用数据加密（Encryption）技术，确保数据在网络上之传输过程中不会被截取。
  • SSL 协议可分为两层，SSL 记录协议（SSL Record Protocol）和 SSL握手协议（SSL Handshake Protocol）。
    • SSL 记录协议建立在可靠的传输协议（如 TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
    • SSL 握手协议建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
• 传输层安全协议（Transport Layer Security，TLS），用于两个应用程序之间提供保密性和数据完整性。
  • TLS 1.0 是 Internet 工程任务组（Internet Engineering Task Force，IETF）制定的一种新的协议，它建立在 SSL 3.0 协议规范之上，是 SSL 3.0 的后续版本。
  • 该协议由两层组成，TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。
  • 较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

TLS 与 SSL 的差异

• 版本号。TLS 记录格式与 SSL 记录格式相同，但版本号的值不同，TLS 的版本 1.0 使用的版本号为 SSLv3.1。
• 报文鉴别码。SSLv3.0 和 TLS 的 MAC 算法及 MAC 计算的范围不同。
  • TLS 使用了 [ RFC 2104 ] 定义的 HMAC 算法。
  • SSLv3.0 使用了相似的算法，两者差别在于 SSLv3.0 填充字节与密钥之间采用的是连接运算，而 HMAC 算法采用的是异或运算。但是两者的安全程度是相同的。
  • 伪随机函数。TLS 使用了称为 PRF 的伪随机函数来将密钥扩展成数据块，是更安全的方式。
  • 报警代码。TLS 支持几乎所有的 SSLv3.0 报警代码，同时还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
  • 密文族和客户证书。SSLv3.0 和 TLS 存在少量差别，即 TLS 不支持 Fortezza 密钥交换、加密算法和客户证书。
  • certificate_verify 和 finished 消息。SSLv3.0 和 TLS 在用 certificate_verify 和 finished 消息计算 MD5 和 SHA-1 散列码时，计算的输入有少许差别，但安全性相当。
  • 加密计算。TLS 与 SSLv3.0 在计算主密值（Master Secret）时采用的方式不同。
  • 填充。用户数据加密之前需要增加的填充字节。
    • 在 SSL 中，填充后的数据长度要达到密文块长度的最小整数倍。
    • 在 TLS 中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为 255 字节），这种方式可以防止基于对报文长度进行分析的攻击。

TLS 的主要增强内容

• TLS 主要目标是使 SSL 更安全，并使协议的规范更精确和完善。TLS 在 SSL v3.0 的基础上，提供了以下增强内容。
  • 更安全的 MAC 算法。
  • 更严密的警报。
  • " 灰色区域 " 规范的更明确定义。

1.1 密钥协商过程（TLS 握手）

• 协议分为握手协议和记录协议两部分。
  • 其中握手协议用来协商密钥，协议大部分内容就是通信双方如何利用它来安全的协商出一份密钥。
  • 记录协议则定义了传输的格式。
• 由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过 HMAC 的处理。
• SSL 缺省只进行服务端的认证，客户端的认证是可选的。

TLS 握手过程

1.1.1 客户端发出请求（ClientHello）

• 由于客户端（如浏览器）对一些加解密算法的支持程度不一样，但是在 TLS 协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。
  • 所以在 TLS 握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，需要将本地支持的加密套件（Cipher Suite）的列表传送给服务端。
  • 除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产 主密值（Master Secret），假设该随机数为 random_C。
• 客户端向服务器提供的信息。
  • 支持的协议版本，例如 TLS 1.0 版。
  • 一个客户端生成的随机数，用于生成 对话密钥（Session Secret）。
  • 支持的加密方法，例如 RSA 公钥加密。
  • 支持的压缩方法。
• 通过 Wireshark 抓包可以看到以下内容。
  • 信息包含 ContentType、Version、Handshake Protocol 等信息。

Handshake Protocol: Client Hello
    Handshake Type: Client Hello (1)
    Length: 508
    Version: TLS 1.2 (0x0303)
    Random: cdc1f5573df2fa1c629ab466d127cc551ec6bc2b569385ed...
    Session ID Length: 32
    Session ID: b15be15c4c39956f6f5bc3f5bb865efeba69406ea0fcc8b8...
    Cipher Suites Length: 34
    Cipher Suites (17 suites)
    Compression Methods Length: 1
    Compression Methods (1 method)
    Extensions Length: 401
    Extension: Reserved (GREASE) (len=0)
    Extension: extended_master_secret (len=0)
    Extension: renegotiation_info (len=1)
    Extension: supported_groups (len=10)
    Extension: ec_point_formats (len=2)
    Extension: SessionTicket TLS (len=192)
    Extension: application_layer_protocol_negotiation (len=14)
    Extension: status_request (len=5)
    Extension: signature_algorithms (len=20)
    Extension: signed_certificate_timestamp (len=0)
    Extension: key_share (len=43)
    Extension: psk_key_exchange_modes (len=2)
    Extension: supported_versions (len=11)
    Extension: Unknown type 27 (len=3)
    Extension: Reserved (GREASE) (len=1)
    Extension: padding (len=33)

ContentType	Dec	说明
ChangeCipherSpec	20	开始加密传输
Alert	21	警告
Handshake	22	握手
Application	23	正常通信

• Version 为版本信息。

主要版本	次要版本	版本类型
3	0	SSLv3
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2

• Handshake Protocol 是对应握手阶段中的具体步骤。

编号	说明
0	HelloRequest
1	ClientHello
2	ServerHello
11	Certificate
12	ServerKeyExchange
13	CertificateRequest
14	ServerHelloDone
15	CertificateVerify
16	ClientKeyExchange
20	Finished

分析用例

• 支持的协议版本为 TLS 1.2。
• 客户端生成的随机数为 Random: cdc1f5573df2fa1c629ab466d127cc551ec6bc2b569385ed...。
• 支持的加密方法（加密套件） Cipher Suite。

Cipher Suites (17 suites)
    Cipher Suite: Reserved (GREASE) (0xfafa)
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
    Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
    Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

• Session ID，如果连接断开，再次连接时，可以使用该属性重新建立连接，在双方都有缓存的情况下可以省略握手的步骤。

1.1.2 服务器回应（SeverHello）

• 从 Server Hello 到 Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello 和 Server Done 都是只有头没有内容的数据。
• 服务端在接收到客户端的 Client Hello 请求之后，服务端需要将自己的 证书（这个证书是对于服务端的一种认证，例如，客户端收到了一个来自于 www.alipay.com 的数据，通过证书就能证明它是 alipay，而不是财付通）发送给客户端。
  • 证书需要申请，并由专门的数字证书认证机构（CA）通过非常严格的审核之后颁发的电子证书。
  • 颁发证书的同时会产生一个私钥和公钥。
  • 私钥由服务端自己保存，不可泄漏。
  • 公钥则是附带在证书的信息中，可以公开的。
  • 证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。
  • 另外，证书还有个有效期。
• 在服务端向客户端发送的证书中没有提供足够的信息（证书公钥）的时候（如基于 DH 的证书，公钥不被证书中包含），还可以向客户端发送一个 Server Key Exchange。
• 对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。
  • 服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证（例如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供 USB 密钥，里面就包含了一张客户端证书）。
• 跟客户端一样，服务端也需要产生一个随机数发送给客户端，假设该随机数为 random_S。
• 客户端和服务端都需要使用这 两个随机数 来产生 主密值（Master Secret）。
• 最后服务端发送一个 Server Hello Done 消息给客户端，表示 Server Hello 消息结束。
• 服务器的回应包含的内容。
  • 确认使用的加密通信协议版本，比如 TLS 1.0 版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  • 一个服务器生成的随机数，用于生成 对话密钥（Session Secret）。
  • 确认使用的加密方法，比如 RSA 公钥加密。
  • 服务器证书。

Handshake Protocol: Server Hello
    Handshake Type: Server Hello (2)
    Length: 77
    Version: TLS 1.2 (0x0303)
    Random: b8a711c2e2c5c83b53257ef8c3b088c265f34377567f22a3...
    Session ID Length: 32
    Session ID: b15be15c4c39956f6f5bc3f5bb865efeba69406ea0fcc8b8...
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Compression Method: null (0)
    Extensions Length: 5
    Extension: renegotiation_info (len=1)

分析用例

• 确认使用的加密通信协议版本 TLS 1.2。
• 服务器生成的随机数 Random: b8a711c2e2c5c83b53257ef8c3b088c265f34377567f22a3...。
• 确认使用的加密方法 Cipher Suite。
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)。

1.1.3 客户端回应（Certificate Verify）

Client Key Exchange

• 如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。

Certificate Verify

• 接着，客户端需要对服务端的证书进行检查，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
• 如果证书没有问题，客户端会从服务器证书中取出服务器的公钥。
• 向服务器发送。
  • 一个随机数。该随机数用服务器公钥加密（产生一个 48 个字节的 Key，客户端使用一些加密算法（例如 RSA，Diffie-Hellman）产生一个 48 个字节的 PreMaster Secret），防止被窃听（这是握手阶段的第三个随机数），假设该随机数为 pre_master_secret。
• 几个随机数组合计算可以得到 主密值。
  • master_secret =PRF(pre_master_secret, "master secret", random_C + random_S)。
  • "master secret" 是一串 ASCII 码。
  • PRF 是伪随机函数，将密钥、ASCII 码标签、哈希值整合在一起。各有一半的参数分别使用 MD5 和 SHA-1 获取哈希值（hash 之后再 hash）。
  • 客户端得到主密值（Master Secret）后（48 字节），根据协议约定，利用 PRF 生成这个会话中所需要的各种密钥，称之为 密钥块（key block，由 Master Secret 再与 key expansion 常量、双方的随机数，经过伪随机函数（PRF）运算得到）。

ChangeCipherSpec

• ChangeCipherSpec 是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
• 在 ChangecipherSpec 传输完毕之后，客户端会使用之前协商好的加密套件和 Session Secret 加密一段 Finish 的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。

1.1.4 服务器的最后回应（Server Finish）

• 服务端在接收到客户端传过来的 pre_master_secret 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成 Session Secret，一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret 加密数据。
• 服务端使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
• 如果客户端和服务端都能对 Finish 信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来双方可以使用之前产生的 Session Secret 对数据进行加密传输。
• 如果通过，说明握手过程中的数据没有被第三方篡改过，也说明服务端是之前交换证书的拥有者。现在双方就可以开始后续通信，进入 Application context。

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.2 (0x0303)
    Length: 1
    Change Cipher Spec Message
TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
    Content Type: Application Data (23)
    Version: TLS 1.2 (0x0303)
    Length: 853
    Encrypted Application Data: 00000000000000016a4554bc0c9c4055ee59e491d861aee9...

1.1.5 密钥（Secret）

PreMaster Secret

• PreMaster Secret 是在客户端使用 RSA 或者 Diffie-Hellman 等加密算法生成。
  • 它将用来跟服务端和客户端在 Hello 阶段产生的随机数结合在一起生成 主密值（Master Secret）。
  • 在客户端使用服务端的公钥对 PreMaster Secret 进行加密之后传送给服务端，服务端将使用私钥进行解密得到 PreMaster Secret。
  • 服务端和客户端都有一份相同的 PreMaster Secret。
• PreMaster Secret 前两个字节是 TLS 的版本号，Client Hello 阶段，客户端会发送一份加密套件列表和当前支持的 SSL/TLS 版本号给服务端，使用明文传送，如果握手的数据包被破解，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来的 PreMaster 中的版本号跟之前 Client Hello 阶段的版本号对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。

Master Secret（主密值）

• 服务端和客户端都有一份相同的 PreMaster Secret 和 随机数（服务器和客户端各自一个）
• Master Secret 作为数据加解密相关的 Secret 的 Key Material 的一部分。
• Key Material 数据如下。

组成部分
Client write MAC Key
Server write MAC Key
Client write encryption key
Server write encryption key
Client write IV
Server write IV

• Client write MAC Key 对应 客户端 Session Secret（Key）。
• Server write MAC Key 对应 服务端 Session Secret（Key）。
• MAC（Message Authentication Code）是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。

应用数据传输

• 在所有的握手阶段都完成后开始传送应用数据。
  • 应用数据传输前，首先附加 MAC Secret，然后对数据包使用 write encryption key 进行加密。
  • 服务端收到密文后使用 Client write encryption key 进行解密。
  • 客户端收到密文后使用 Server write encryption key 进行解密，然后使用各自的 write MAC key 对数据完整性、是否被串改进行验证。

密钥的传输

1.1.6 会话缓存握手过程

• 为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS 协议提供两类会话缓存机制。
  • 会话标识 Session ID，由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话 ID 以及协商的通信信息，nginx 中 1M 内存约可以保存 4000 个 session ID 机器相关信息，占用服务器资源较多。
  • 会话记录 Session Ticket，需要服务器和客户端都支持，属于一个扩展字段，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。
  • 两者主要是保存协商信息的位置与方式不同，类似于 HTTP 中的 session 与 cookie。
  • 两者都存在的情况下，nginx 优先使用 Session Ticket。

会话标识 Session ID

会话标识 Session ID 恢复

• 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中。
• 如果客户端再次需要和该服务器建立连接，则在 client_hello 中 session ID 中携带记录的信息，发送给服务器。
• 服务器根据收到的 session ID 检索缓存记录，如果没有检索到缓存或者缓存过期，则按照正常的握手过程进行。
• 如果检索到对应的缓存记录，则返回 change_cipher_spec 与 encrypted_handshake_message 信息（是到当前的通信参数与 master_secret 的 hash 值），这两个信息作用类似。
• 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与 encrypted_handshake_message 信息。
• 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

会话记录 Session Ticket

会话记录 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 信息。
• 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

2. HTTPS

• 超文本传输安全协议（Hypertext Transfer Protocol Secure，HTTPS），是以安全为目标的 HTTP 通道。
• HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
  • HTTPS 并不是一个单独的协议，而是对工作在 加密连接（TLS/SSL）上的常规 HTTP 协议的称呼。
  • HTTP + 加密 + 认证 + 完整性保护 = HTTPS。

2.1 HTTPS 加密方式

• 对称密钥加密方式的优缺点。
  • 优点。处理速度快。
  • 缺点。但是容易被第三方盗取。
• 非对称密钥加密方式的优缺点。
  • 优点。更加安全，不容易被盗取。
  • 缺点。处理效率相比对称密钥加密要慢，如果在通信时用这种方式加密，效率很低。
• HTTPS 采用了两者的优点，使用了混合加密的方式。
  • 使用非对称密钥加密的方式安全地交换再稍后对称密钥加密中要使用的密钥。
  • 确保交换的密钥是安全的之后，放弃非对称密钥加密，使用对称密钥加密来进行通信，保证传输效率。

2.2 证书

证明公钥正确性的数字证书

• 客户端无法判断自己收到的服务器的公钥是否正确，是否在服务器发送给客户端的过程中被第三方篡改，为解决该问题，服务器可以使用由数字证书认证机构（CA）颁发的证书，这种机构是客户端和服务器双方的第三方机构。
• 服务器获取证书的流程。
  • 服务器运营人员向 CA 提出对公钥（A）进行签名的申请。
  • CA 在判明申请者的身份之后，对已申请的公钥（A）做数字签名（用 CA 的私钥对 A 进行签名），然后将这个数字签名、公钥（A）和服务器相关的一些信息一起做成证书分配给服务器公司。
  • 服务器会把由 CA 颁发的证书以及公钥（B，B 与 A 一致）发送给客户端，以此来和客户端进行通信。
  • CA 的公钥（C）已经事先植入到浏览器中，客户端通过 CA 的公钥（C）解密证书上的签名，获得证书中的公钥（A），然后与服务器发送给客户端的公钥（B）对比。
  • A 与 B 一致则认证通过，一旦认证通过，客户端就可以知道服务器的公钥（B）是真实有效的，并且是值得信赖的。

证明企业真实性的 EV SSL 证书

• 该证书用来验证服务器背后运营的企业的合法性。

用以确认客户端的客户端证书

• 该证书用来向服务器证明，与之通信的客户端是预料之内的客户端。
• 想要获取证书时，用户得自行安装客户端证书，一般只有某些特定的业务，如网上银行等，需要使用客户端证书。

2.3 HTTP 与 HTTPS 的区别

• HTTPS 更加安全，因为它有加密，身份认证，验证数据完整性等环节。
• HTTPS 需要申请证书。
• 加密通信需要消耗更多的 CPU 和内存资源，如果每次通信都加密，会消耗很多的资源，当访问量很多的网站在进行加密处理时，所承担着负载也很多，这时需要服务器端实现负载均衡。（有专用的 HTTPS 加解密硬件服务器）。
• 使用端口不同，HTTP 使用 80 端口，HTTPS 使用 443 端口。
• 所在层次不同，HTTP 运行在 TCP 之上，HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。

参考资料

https://cloud.tencent.com/developer/article/1115445
https://blog.csdn.net/fw0124/article/details/40875629
https://www.cnblogs.com/NathanYang/p/9183300.html
https://blog.csdn.net/tterminator/article/details/50675540