SSL详解

SSL介绍：

安全套接字（Secure Socket Layer，SSL）协议是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密。

SSL是Netscape于1994年开发的，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议

目前有三个版本：2、3、3.1，最常用的是第3版，是1995年发布的。

SSL协议的三个特性

① 保密：在握手协议中定义了会话密钥后，所有的消息都被加密。

② 鉴别：可选的客户端认证，和强制的服务器端认证。

③ 完整性：传送的消息包括消息完整性检查（使用MAC）。

SSL的位置

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

SSL的工作原理

握手协议（Handshake protocol）

记录协议（Record protocol）

警报协议（Alert protocol）

1、握手协议

握手协议是客户机和服务器用SSL连接通信时使用的第一个子协议，握手协议包括客户机与服务器之间的一系列消息。SSL中最复杂的协议就是握手协议。该协议允许服务器和客户机相互验证，协商加密和MAC算法以及保密密钥，用来保护在SSL记录中发送的数据。握手协议是在应用程序的数据传输之前使用的。

每个握手协议包含以下3个字段
（1）Type：表示10种消息类型之一
（2）Length：表示消息长度字节数
（3）Content：与消息相关的参数

握手协议的4个阶段

 

 

 

1.1建立安全能力

SSL握手的第一阶段启动逻辑连接，建立这个连接的安全能力。首先客户机向服务器发出client hello消息并等待服务器响应，随后服务器向客户机返回server hello消息，对client hello消息中的信息进行确认。

Client hello消息包括Version，Random，Session id，Cipher suite，Compression method等信息。

 

 

 

ClientHello 客户发送CilentHello信息，包含如下内容：

（1）客户端可以支持的SSL最高版本号

（2）一个用于生成主秘密的32字节的随机数。（等会介绍主秘密是什么）

（3）一个确定会话的会话ID。

（4）一个客户端可以支持的密码套件列表。

密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。用“With”这个词把密钥交换算法、加密算法、散列算法分开，例如：SSL_DHE_RSA_WITH_DES_CBC_SHA,表示把DHE_RSA(带有RSA数字签名的暂时Diffie-HellMan)定义为密钥交换算法；把DES_CBC定义为加密算法；把SHA定义为散列算法。

（5）一个客户端可以支持的压缩算法列表。

ServerHello 服务器用ServerHello信息应答客户，包括下列内容

（1）一个SSL版本号。取客户端支持的最高版本号和服务端支持的最高版本号中的较低者。

（2）一个用于生成主秘密的32字节的随机数。（客户端一个、服务端一个）

（3）会话ID

（4）从客户端的密码套件列表中选择的一个密码套件

（5）从客户端的压缩方法的列表中选择的压缩方法

这个阶段之后，客户端服务端知道了下列内容：

（1）SSL版本

（2）密钥交换、信息验证和加密算法

（3）压缩方法

（4）有关密钥生成的两个随机数。

1.2 服务器鉴别与密钥交换

服务器启动SSL握手第2阶段，是本阶段所有消息的唯一发送方，客户机是所有消息的唯一接收方。该阶段分为4步：
（a）证书：服务器将数字证书和到根CA整个链发给客户端，使客户端能用服务器证书中的服务器公钥认证服务器。
（b）服务器密钥交换（可选）：这里视密钥交换算法而定
（c）证书请求：服务端可能会要求客户自身进行验证。
（d）服务器握手完成：第二阶段的结束，第三阶段开始的信号

 

 

 

这里重点介绍一下服务端的验证和密钥交换。这个阶段的前面的（a）证书 和（b）服务器密钥交换是基于密钥交换方法的。而在SSL中密钥交换算法有6种：无效（没有密钥交换）、RSA、匿名Diffie-Hellman、暂时Diffie-Hellman、固定Diffie-Hellman、Fortezza。

在阶段1过程客户端与服务端协商的过程中已经确定使哪种密钥交换算法。

如果协商过程中确定使用RSA交换密钥，那么过程如下图：

 

 

 

这个方法中，服务器在它的第一个信息中，发送了RSA加密/解密公钥证书。不过，因为预备主秘密是由客户端在下一个阶段生成并发送的，所以第二个信息是空的。注意，公钥证书会进行从服务器到客户端的验证。当服务器收到预备主秘密时，它使用私钥进行解密。服务端拥有私钥是一个证据，可以证明服务器是一个它在第一个信息发送的公钥证书中要求的实体。

其他的几种密钥交换算法这里就不介绍了。可以参考Behrouz A.Forouzan著的《密码学与网络安全》。

1.3 客户机鉴别与密钥交换：

 

 

 

客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。该阶段分为3步：

（a）证书（可选）：为了对服务器证明自身，客户要发送一个证书信息，这是可选的，在IIS中可以配置强制客户端证书认证。

（b）客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。

（c）证书验证（可选），对预备秘密和随机数进行签名，证明拥有（a）证书的公钥。

下面也重点介绍一下RSA方式的客户端验证和密钥交换。

 

 

 

这种情况，除非服务器在阶段II明确请求，否则没有证书信息。客户端密钥交换方法包括阶段II收到的由RSA公钥加密的预备主密钥。

阶段III之后，客户要有服务器进行验证，客户和服务器都知道预备主密钥。

1.4 完成

 

 

 

客户机启动SSL握手第4阶段，使服务器结束。该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。

1.5密钥生成的过程

这样握手协议完成，下面看下什么是预备主密钥，主密钥是怎么生成的。为了保证信息的完整性和机密性，SSL需要有六个加密秘密：四个密钥和两个IV。为了信息的可信性，客户端需要一个密钥（HMAC），为了加密要有一个密钥，为了分组加密要一个IV，服务也是如此。SSL需要的密钥是单向的，不同于那些在其他方向的密钥。如果在一个方向上有攻击，这种攻击在其他方向是没影响的。生成过程如下：

 

 

 

 

 

 

 

 

 

2、记录协议

记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务：

（1）保密性：使用握手协议定义的秘密密钥实现

（2）完整性：握手协议定义了MAC，用于保证消息完整性

记录协议的过程：

 

SSL记录的首部：
类型（type）：8位，指明上层协议的类型。 改变密码规约协议的值:20. 告警协议：21 握手协议：22 应用数据协议：23
版本(version):TLS协议版本，长度为16位
长度（length）:加密后数据的长度
数据分片的密文数据，附带MAC摘要。

3、警报协议

客户机和服务器发现错误时，向对方发送一个警报消息。如果是致命错误，则算法立即关闭SSL连接，双方还会先删除相关的会话号，秘密和密钥。每个警报消息共2个字节，第1个字节表示错误类型，如果是警报，则值为1，如果是致命错误，则值为2；第2个字节制定实际错误类型。

总结

SSL中，使用握手协议协商加密和MAC算法以及保密密钥 ，使用握手协议对交换的数据进行加密和签名，使用警报协议定义数据传输过程中，出现问题如何去解决。

 

二、 SSL/TLS协议

SSL（Secure Sockets Layer，安全套接层），及其继任者 TLS（Transport Layer Security，传输层安全）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

 SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。

SSL协议可分为两层：
SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。SSL握手协议有三个子协议如图：

握手协议（Handshake protocol）：用于会话建立。

改变密码规约协议（Change cipher spec protocol）：用于通知安全参数的建立。

告警协议（Alert protocol）：用于向对方发出告警信息。

 

 

 SSL/TLS协议栈

SSL/TLS协议主要解决的以下3个问题：
1.客户端对服务器端的认证
2.服务器端对客户端的认证
3.在客户端和服务器端建立安全的数据通道

HTTPS = HTTP over TLS.只需配置浏览器和服务器相关设置开启 TLS，即可实现 HTTPS，TLS 高度解耦，可装可卸，与上层高级应用层协议相互协作又相互独立。

 1.加密

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

 TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

例如，在 HTTPS 协议中，客户端发出请求，服务端会将公钥发给客户端，客户端验证过后生成一个密钥再用公钥加密后发送给服务端（非对称加密），双方会在 TLS 握手过程中生成一个协商密钥（对称密钥），成功后建立加密连接。通信过程中客户端将请求数据用协商密钥加密后发送，服务端也用协商密钥解密，响应也用相同的协商密钥。后续的通信使用对称加密是因为对称加解密快，而握手过程中非对称加密可以保证加密的有效性，但是过程复杂，计算量相对来说也大。

2. 记录层

记录协议负责在传输连接上交换的所有底层消息，并且可以配置加密。每一条 TLS 记录以一个短标头开始。标头包含记录内容的类型 (或子协议)、协议版本和长度。原始消息经过分段 (或者合并)、压缩、添加认证码、加密转为 TLS 记录的数据部分。

 3.分片 (Fragmentation)

记录层将信息块分割成携带 2^14 字节 (16KB) 或更小块的数据的 TLSPlaintext 记录。

记录协议传输由其他协议层提交给它的不透明数据缓冲区。如果缓冲区超过记录的长度限制（2^14），记录协议会将其切分成更小的片段。反过来也是可能的，属于同一个子协议的小缓冲区也可以组合成一个单独的记录。

  1.  
    struct {
  2.  
    uint8 major, minor;
  3.  
    } ProtocolVersion;
  4.  
     
  5.  
    enum {
  6.  
    change_cipher_spec(20),
  7.  
    alert(21),
  8.  
    handshake(22),
  9.  
    application_data(23), (255)
  10.  
    } ContentType;
  11.  
     
  12.  
    struct {
  13.  
    ContentType type; // 用于处理封闭片段的较高级协议
  14.  
    ProtocolVersion version; // 使用的安全协议版本
  15.  
    uint16 length; // TLSPlaintext.fragment 的长度（以字节为单位），不超过 2^14
  16.  
    opaque fragment[TLSPlaintext.length]; // 透明的应用数据，被视为独立的块，由类型字段指定的较高级协议处理
  17.  
    } TLSPlaintext;
  18.  
    复制代码

4.记录压缩和解压缩 (Record compression and decompression)

压缩算法将 TLSPlaintext 结构转换为 TLSCompressed 结构。如果定义 CompressionMethod 为 null 表示不压缩

  1.  
    struct {
  2.  
    ContentType type; // same as TLSPlaintext.type
  3.  
    ProtocolVersion version; // same as TLSPlaintext.version
  4.  
    uint16 length; // TLSCompressed.fragment 的长度，不超过 2^14 + 1024
  5.  
    opaque fragment[TLSCompressed.length];
  6.  
    } TLSCompressed;
  7.  
    复制代码

5.空或标准流加密 (Null or standard stream cipher)

流加密（BulkCipherAlgorithm）将 TLSCompressed.fragment 结构转换为流 TLSCiphertext.fragment 结构

  1.  
    stream-ciphered struct {
  2.  
    opaque content[TLSCompressed.length];
  3.  
    opaque MAC[CipherSpec.hash_size];
  4.  
    } GenericStreamCipher;
  5.  
    复制代码

MAC 产生方法如下：

  1.  
    HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));
  2.  
    复制代码

seq_num（记录的序列号）、hash（SecurityParameters.mac_algorithm 指定的哈希算法）

MAC(Message authentication code) - 消息认证码

注意，MAC 是在加密之前计算的。流加密加密整个块，包括 MAC。对于不使用同步向量 (例如 RC4) 的流加密，从一个记录结尾处的流加密状态仅用于后续数据包。如果 CipherSuite 是 TLS_NULL_WITH_NULL_NULL，则加密由身份操作 (数据未加密，MAC 大小为零，暗示不使用 MAC) 组成。TLSCiphertext.length 是 TLSCompressed.length 加上 CipherSpec.hash_size

6.CBC 块加密 (分组加密)

块加密（如 RC2 或 DES），将 TLSCompressed.fragment 结构转换为块 TLSCiphertext.fragment 结构

  1.  
    block-ciphered struct {
  2.  
    opaque content[TLSCompressed.length];
  3.  
    opaque MAC[CipherSpec.hash_size];
  4.  
    uint8 padding[GenericBlockCipher.padding_length];
  5.  
    uint8 padding_length;
  6.  
    } GenericBlockCipher;
  7.  
    复制代码

padding: 添加的填充将明文长度强制为块密码块长度的整数倍。填充可以是长达 255 字节的任何长度，只要满足 TLSCiphertext.length 是块长度的整数倍。长度大于需要的值可以阻止基于分析交换信息长度的协议攻击。填充数据向量中的每个 uint8 必须填入填充长度值 (即 padding_length)。

padding_length: 填充长度应该使得 GenericBlockCipher 结构的总大小是加密块长度的倍数。合法值范围从零到 255（含）。该长度指定 padding_length 字段本身除外的填充字段的长度

加密块的数据长度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的总和加一

示例: 如果块长度为 8 字节，压缩内容长度（TLSCompressed.length）为 61 字节，MAC 长度为 20 字节，则填充前的长度为 82 字节（padding_length 占 1 字节）。 因此，为了使总长度为块长度 (8 字节) 的偶数倍，模 8 的填充长度必须等于 6，所以填充长度可以为 6，14，22 等。如果填充长度是需要的最小值，比如 6，填充将为 6 字节，每个块都包含值 6。因此，块加密之前的 GenericBlockCipher 的最后 8 个八位字节将为 xx 06 06 06 06 06 06 06，其中 xx 是 MAC 的最后一个八位字节。

  1.  
    XX - 06 06 06 06 06 06 - 06
  2.  
    MAC - padding[6] - padding_length
  3.  
    复制代码

7.记录有效载荷保护 (Record payload protection)

加密和 MAC 功能将 TLSCompressed 结构转换为 TLSCiphertext。记录的 MAC 还包括序列号，以便可以检测到丢失，额外或重复的消息。

  1.  
    struct {
  2.  
    ContentType type; // same
  3.  
    ProtocolVersion version; // same
  4.  
    uint16 length; // TLSCiphertext.fragment 的长度，不超过 2^14 + 2048
  5.  
    select (CipherSpec.cipher_type) {
  6.  
    case stream: GenericStreamCipher;
  7.  
    case block: GenericBlockCipher;
  8.  
    } fragment; // TLSCompressed.fragment 的加密形式，带有 MAC
  9.  
    } TLSCiphertext;
  10.  
    复制代码

注意 这里提到的都是先 MAC 再加密，是基于 RFC 2246 的方案 (TLS 1.0) 写的。但新的方案选择先加密再 MAC，这种替代方案中，首先对明文和填充进行加密，再将结果交给 MAC 算法。这可以保证主动网络攻击者不能操纵任何加密数据。

8.密钥计算 (Key calculation)

记录协议需要一种算法，从握手协议提供的安全性参数生成密钥、IV 和 MAC secret.

主密钥 (Master secret): 在连接中双方共享的一个 48 字节的密钥 客户随机数 (client random): 由客户端提供的 32 字节值 服务器随机数 (server random): 由服务器提供的 32 字节值

9. 握手层

  • 握手协议的职责是生成通信过程所需的共享密钥和进行身份认证。这部分使用无密码套件，为防止数据被窃听，通过公钥密码或 Diffie-Hellman 密钥交换技术通信。
  • 密码规格变更协议，用于密码切换的同步，是在握手协议之后的协议。握手协议过程中使用的协议是“不加密”这一密码套件，握手协议完成后则使用协商好的密码套件。
  • 警告协议，当发生错误时使用该协议通知通信对方，如握手过程中发生异常、消息认证码错误、数据无法解压缩等。
  • 应用数据协议，通信双方真正进行应用数据传输的协议，传送过程通过 TLS 应用数据协议和 TLS 记录协议来进行传输。

握手是 TLS 协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身 份验证。根据使用的功能的不同，整个过程通常需要交换 6~10 条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：(1) 完整的握手， 对服务器进行身份验证；(2) 恢复之前的会话采用的简短握手；(3) 对客户端和服务器都进行身份验证的握手。

握手协议消息的标头信息包含消息类型（1 字节）和长度（3 字节），余下的信息则取决于消息类型：

  1.  
    struct {
  2.  
    HandshakeType msg_type;
  3.  
    uint24 length;
  4.  
    HandshakeMessage message;
  5.  
    } Handshake;
  6.  
    复制代码

9.1 完整握手

每一个 TLS 连接都会以握手开始。如果客户端此前并未与服务器建立会话，那么双方会执行一次完整的握手流程来协商 TLS 会话。握手过程中，客户端和服务器将进行以下四个主要步骤:

  • 交换各自支持的功能，对需要的连接参数达成一致
  • 验证出示的证书，或使用其他方式进行身份验证
  • 对将用于保护会话的共享主密钥达成一致
  • 验证握手消息并未被第三方团体修改

下面介绍最常见的握手规则，一种不需要验证客户端身份但需要验证服务器身份的握手:

 9.1.1 ClientHello

这条消息将客户端的功能和首选项传送给服务器。

 Version: 协议版本（protocol version）指示客户端支持的最佳协议版本

  • Random: 一个 32 字节数据，28 字节是随机生成的 (图中的 Random Bytes)；剩余的 4 字节包含额外的信息，与客户端时钟有关 (图中使用的是 GMT Unix Time)。在握手时，客户端和服务器都会提供随机数，客户端的暂记作 random_C (用于后续的密钥的生成)。这种随机性对每次握手都是独一无二的，在身份验证中起着举足轻重的作用。它可以防止 重放攻击，并确认初始数据交换的完整性。
  • Session ID: 在第一次连接时，会话 ID（session ID）字段是空的，这表示客户端并不希望恢复某个已存在的会话。典型的会话 ID 包含 32 字节随机生成的数据，一般由服务端生成通过 ServerHello 返回给客户端。
  • Cipher Suites: 密码套件（cipher suite）块是由客户端支持的所有密码套件组成的列表，该列表是按优先级顺序排列的
  • Compression: 客户端可以提交一个或多个支持压缩的方法。默认的压缩方法是 null，代表没有压缩
  • Extensions: 扩展（extension）块由任意数量的扩展组成。这些扩展会携带额外数据

9.1.2 ServerHello

是将服务器选择的连接参数传回客户端。

 这个消息的结构与 ClientHello 类似，只是每个字段只包含一个选项，其中包含服务端的 random_S 参数 (用于后续的密钥协商)。服务器无需支持客户端支持的最佳版本。如果服务器不支持与客户端相同的版本，可以提供某个其他版本以期待客户端能够接受

图中的 Cipher Suite 是后续密钥协商和身份验证要用的加密套件，此处选择的密钥交换与签名算法是 ECDHE_RSA，对称加密算法是 AES-GCM，后面会讲到这个

还有一点默认情况下 TLS 压缩都是关闭的，因为 CRIME 攻击会利用 TLS 压缩恢复加密认证 cookie，实现会话劫持，而且一般配置 gzip 等内容压缩后再压缩 TLS 分片效益不大又额外占用资源，所以一般都关闭 TLS 压缩

9.1.3 Certificate

典型的 Certificate 消息用于携带服务器 X.509 证书链。 服务器必须保证它发送的证书与选择的算法套件一致。比方说，公钥算法与套件中使用的必须匹配。除此以外，一些密钥交换算法依赖嵌入证书的特定数据，而且要求证书必须以客户端支持的算法签名。所有这些都表明服务器需要配置多个证书（每个证书可能会配备不同的证书链）。

 Certificate 消息是可选的，因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书。更进一步说，虽然消息默认使用 X.509 证书，但是也可以携带其他形式的标志；一些套件就依赖 PGP 密钥

9.1.4 ServerKeyExchange

携带密钥交换需要的额外数据。ServerKeyExchange 是可选的，消息内容对于不同的协商算法套件会存在差异。部分场景下，比如使用 RSA 算法时，服务器不需要发送此消息。

ServerKeyExchange 仅在服务器证书消息（也就是上述 Certificate 消息）不包含足够的数据以允许客户端交换预主密钥（premaster secret）时才由服务器发送。

比如基于 DH 算法的握手过程中，需要单独发送一条 ServerKeyExchange 消息带上 DH 参数:

 9.1.5 ServerHelloDone

表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。

9.1.6 verify certificate

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证内容包括如下:

  • 证书链的可信性 trusted certificate path;
  • 证书是否吊销 revocation，有两类方式 - 离线 CRL 与在线 OCSP，不同的客户端行为会不同;
  • 有效期 expiry date，证书是否在有效时间范围;
  • 域名 domain，核查证书域名是否与当前的访问域名匹配;

由 PKI 体系 的内容可知，对端发来的证书签名是 CA 私钥加密的，接收到证书后，先读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后去查询证书的吊销情况等

9.1.7 ClientKeyExchange

合法性验证通过之后，客户端计算产生随机数字的预主密钥（Pre-master），并用证书公钥加密，发送给服务器并携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响，内容随着不同的协商密码套件而不同。

此时客户端已经获取全部的计算协商密钥需要的信息: 两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，然后得到协商密钥(用于之后的消息加密)

  1.  
    enc_key = PRF(Pre_master, "master secret", random_C + random_S)
  2.  
    复制代码

 图中使用的是 ECDHE 算法，ClientKeyExchange 传递的是 DH 算法的客户端参数，如果使用的是 RSA 算法则此处应该传递加密的预主密钥

9.1.8 ChangeCipherSpec

通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信

注意 ChangeCipherSpec 不属于握手消息，它是另一种协议，只有一条消息，作为它的子协议进行实现。

9.1.9 Finished (Encrypted Handshake Message)

Finished 消息意味着握手已经完成。消息内容将加密，以便双方可以安全地交换验证整个握手完整性所需的数据。

这个消息包含 verify_data 字段，它的值是握手过程中所有消息的散列值。这些消息在连接两端都按照各自所见的顺序排列，并以协商得到的主密钥 (enc_key) 计算散列。这个过程是通过一个伪随机函数（pseudorandom function，PRF）来完成的，这个函数可以生成任意数量的伪随机数据。 两端的计算方法一致，但会使用不同的标签（finished_label）：客户端使用 client finished，而服务器则使用 server finished。

  1.  
    verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))
  2.  
    复制代码

因为 Finished 消息是加密的，并且它们的完整性由协商 MAC 算法保证，所以主动网络攻击者不能改变握手消息并对 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的长度默认是 12 字节（96 位），并且允许密码套件使用更长的长度。在此之前的版本，除了 SSL 3 使用 36 字节的定长消息，其他版本都使用 12 字节的定长消息。

9.1.10 Server

服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，同样计算得到协商密钥: enc_key = PRF(Pre_master, "master secret", random_C + random_S);

同样计算之前所有收发信息的 hash 值，然后用协商密钥解密客户端发送的 verify_data_C，验证消息正确性;

9.1.11 change_cipher_spec

 服务端验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信（图中多了一步 New Session Ticket，此为会话票证，会在会话恢复中解释）;

9.1.12 Finished (Encrypted Handshake Message)

服务器也结合所有当前的通信参数信息生成一段数据 (verify_data_S) 并采用协商密钥 session secret (enc_key) 与算法加密并发送到客户端;

9.1.13 握手结束

客户端计算所有接收信息的 hash 值，并采用协商密钥解密 verify_data_S，验证服务器发送的数据和密钥，验证通过则握手完成;

9.1.14 加密通信

开始使用协商密钥与算法进行加密通信。

 

9.2 密钥交换和签名算法

常用的密钥交换和签名算法

HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能。加密过程中，需要用到非对称密钥交换和对称内容加密两大算法。

对称内容加密强度非常高，加解密速度也很快，只是无法安全地生成和保管密钥。在 TLS 协议中，最后的应用数据都是经过对称加密后传输的，传输中所使用的对称协商密钥(上文中的 enc_key)，则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305，都是对称加密算法。

非对称密钥交换能在不安全的数据通道中，产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE。

RSA 历史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy)；而 ECDHE 是使用了 ECC（椭圆曲线）的 DH（Diffie-Hellman）算法，计算速度快，且支持 PFS。

在 PKI 体系 一节中说明了仅有非对称密钥交换还是无法抵御 MITM 攻击的，所以需要引入了 PKI 体系的证书来进行身份验证，其中服务端非对称加密产生的公钥会放在证书中传给客户端。

在 RSA 密钥交换中，浏览器使用证书提供的 RSA 公钥加密相关信息，如果服务端能解密，意味着服务端拥有与公钥对应的私钥，同时也能算出对称加密所需密钥。密钥交换和服务端认证合并在一起。

在 ECDH 密钥交换中，服务端使用私钥 (RSA 或 ECDSA) 对相关信息进行签名，如果浏览器能用证书公钥验证签名，就说明服务端确实拥有对应私钥，从而完成了服务端认证。密钥交换则是各自发送 DH 参数完成的，密钥交换和服务端认证是完全分开的。

可用于 ECDHE 数字签名的算法主要有 RSA 和 ECDSA - 椭圆曲线数字签名算法，也就是目前密钥交换 + 签名有三种主流选择:

  • RSA - RSA 密钥交换（无需签名）
  • ECDHE_RSA - ECDHE 密钥交换、RSA 签名
  • ECDHE_ECDSA - ECDHE 密钥交换、ECDSA 签名

 比如我的网站使用的加密套件是 ECDHE_RSA，可以看到数字签名算法是 sha256 哈希加 RSA 加密，在 PKI 体系 一节中讲了签名是服务器信息摘要的哈希值加密生成的

内置 ECDSA 公钥的证书一般被称之为 ECC 证书，内置 RSA 公钥的证书就是 RSA 证书。因为 256 位 ECC Key 在安全性上等同于 3072 位 RSA Key，所以 ECC 证书体积比 RSA 证书小，而且 ECC 运算速度更快，ECDHE 密钥交换 + ECDSA 数字签名是目前最好的加密套件

以上内容来自本文: 开始使用 ECC 证书

关于 ECC 证书的更多细节可见文档: ECC Cipher Suites for TLS - RFC4492

RSA 密钥交换和 DH 密钥交换的区别

使用 RSA 进行密钥交换的握手过程与前面说明的基本一致，只是没有 ServerKeyExchange 消息，其中协商密钥涉及到三个参数 (客户端随机数 random_C、服务端随机数 random_S、预主密钥 Premaster secret)， 其中前两个随机数和协商使用的算法是明文的很容易获取，最后一个 Premaster secret 会用服务器提供的公钥加密后传输给服务器 (密钥交换)，如果这个预主密钥被截取并破解则协商密钥也可以被破解。

RSA 算法的细节见: wiki 和 RSA算法原理（二）- 阮一峰

RSA 的算法核心思想是利用了极大整数 因数分解 的计算复杂性

而使用 DH(Diffie-Hellman) 算法 进行密钥交换，双方只要交换各自的 DH 参数(在 ServerKeyExchange 发送 Server params，在 ClientKeyExchange 发送 Client params)，不需要传递 Premaster secret，就可以各自算出这个预主密钥

DH 的握手过程如下，大致过程与 RSA 类似，图中只表达如何生成预主密钥:

 服务器通过私钥将客户端随机数 random_C，服务端随机数 random_S，服务端 DH 参数 Server params 签名生成 signature，然后在 ServerKeyExchange 消息中发送服务端 DH 参数和该签名；

客户端收到后用服务器给的公钥解密验证签名，并在 ClientKeyExchange 消息中发送客户端 DH 参数 Client params；

服务端收到后，双方都有这两个参数，再各自使用这两个参数生成预主密钥 Premaster secret，之后的协商密钥等步骤与 RSA 基本一致。

基于 RSA 算法与 DH 算法的握手最大的区别就在于密钥交换与身份认证。前者客户端使用公钥加密预主密钥并发送给服务端完成密钥交换，服务端利用私钥解密完成身份认证。后者利用各自发送的 DH 参数完成密钥交换，服务器私钥签名数据，客户端公钥验签完成身份认证。

关于 DH 算法如何生成预主密钥，推荐看下 Wiki 和 Ephemeral Diffie-Hellman handshake

其核心思想是利用了 离散对数问题 的计算复杂性

原根：假设一个整数 g 对于质数 P 来说是原根，那么 g^i mod P (1 ≦ i < P) 的结果各不相同，且其结果按一定顺序排列后是 1 到 P-1 的所有整数，例子

离散对数：如果对于一个整数 n 和质数 P 的一个原根 g，可以找到一个唯一的指数 i，使得 n = g^i mod P (0 ≦ i < P)，那么指数 i 称为 n 的以 g 为基数的模 P 的离散对数

Diffie-Hellman 算法的有效性依赖于计算离散对数的难度，其含义是：当已知大素数 P 和它的一个原根 g 后，对给定的 n，要计算 i，被认为是很困难的，而给定 i 计算 n 却相对容易

 

 

双方预先商定好了一对 P g 值 (公开的)，而 Alice 有一个私密数 a(非公开，对应一个私钥)，Bob 有一个私密数 b(非公开，对应一个私钥)

  • Alice 计算 A = g^a mod P，并把 A(公开，对应一个公钥) 发给 Bob

  • Bob 计算 B = g^b mod P，并把 B(公开，对应一个公钥) 发给 Alice

  • 双方计算出共享密钥，K = B^a mod P = A^b mod P (= g^ab mod P)

对于 Alice 和 Bob 来说通过对方发过来的公钥参数和自己手中的私钥可以得到最终相同的密钥

而第三方最多知道 P g A B，想得到私钥和最后的密钥很困难，当然前提是 a b P 足够大 (RFC3526 文档中有几个常用的大素数可供使用)，否则暴力破解也有可能试出答案，至于 g 一般取个较小值就可以

 

可以看到双方发给对方的参数中携带了一个公钥值，对应上述的 A 和 B

而且实际用的加密套件是 椭圆曲线 DH 密钥交换 (ECDH)，利用由椭圆曲线加密建立公钥与私钥对可以更进一步加强 DH 的安全性，因为目前解决椭圆曲线离散对数问题要比因式分解困难的多，而且 ECC 使用的密钥长度比 RSA 密钥短得多(目前 RSA 密钥需要 2048 位以上才能保证安全，而 ECC 密钥 256 位就足够)

关于 椭圆曲线密码学 - ECC，推荐看下 A Primer on Elliptic Curve Cryptography - 原文 - 译文

9.3 客户端身份验证

尽管可以选择对任意一端进行身份验证，但人们几乎都启用了对服务器的身份验证。如果服务器选择的套件不是匿名的，那么就需要在 Certificate 消息中跟上自己的证书。

 相比之下，服务器通过发送 CertificateRequest 消息请求对客户端进行身份验证。消息中列出所有可接受的客户端证书。作为响应，客户端发送自己的 Certificate 消息（使用与服务器发送证书相同的格式），并附上证书。此后，客户端发送 CertificateVerify 消息，证明自己拥有对应的私钥。

只有已经过身份验证的服务器才被允许请求客户端身份验证。基于这个原因，这个选项也被称为相互身份验证（mutual authentication）。

9.3.1 CertificateRequest

在 ServerHello 的过程中发出，请求对客户端进行身份验证，并将其接受的证书的公钥和签名算法传送给客户端。

它也可以选择发送一份自己接受的证书颁发机构列表，这些机构都用其可分辨名称来表示:

  1.  
    struct {
  2.  
    ClientCertificateType certificate_types;
  3.  
    SignatureAndHashAlgorithm supported_signature_algorithms;
  4.  
    DistinguishedName certificate_authorities;
  5.  
    } CertificateRequest;
  6.  
    复制代码

9.3.2 CertificateVerify

在 ClientKeyExchange 的过程中发出，证明自己拥有的私钥与之前发送的客户端证书中的公钥匹配。消息中包含一条到这一步为止的所有握手消息的签名：

  1.  
    struct {
  2.  
    Signature handshake_messages_signature;
  3.  
    } CertificateVerify;
  4.  
    复制代码

9.4 会话恢复

最初的会话恢复机制是，在一次完整协商的连接断开时，客户端和服务器都会将会话的安全参数保存一段时间。希望使用会话恢复的服务器为会话指定唯一的标识，称为会话 ID(Session ID)。服务器在 ServerHello 消息中将会话 ID 发回客户端。

希望恢复早先会话的客户端将适当的 Session ID 放入 ClientHello 消息，然后提交。服务器如果同意恢复会话，就将相同的 Session ID 放入 ServerHello 消息返回，接着使用之前协商的主密钥生成一套新的密钥，再切换到加密模式，发送 Finished 消息。 客户端收到会话已恢复的消息以后，也进行相同的操作。这样的结果是握手只需要一次网络往返。

Session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话 ID 以及协商的通信信息，占用服务器资源较多。

 用来替代服务器会话缓存和恢复的方案是使用会话票证（Session ticket）。使用这种方式，除了所有的状态都保存在客户端（与 HTTP Cookie 的原理类似）之外，其消息流与服务器会话缓存是一样的。

其思想是服务器取出它的所有会话数据（状态）并进行加密 (密钥只有服务器知道)，再以票证的方式发回客户端。在接下来的连接中，客户端恢复会话时在 ClientHello 的扩展字段 session_ticket 中携带加密信息将票证提交回服务器，由服务器检查票证的完整性，解密其内容，再使用其中的信息恢复会话。

这种方法有可能使扩展服务器集群更为简单，因为如果不使用这种方式，就需要在服务集群的各个节点之间同步会话。 Session ticket 需要服务器和客户端都支持，属于一个扩展字段，占用服务器资源很少。

警告 会话票证破坏了 TLS 安全模型。它使用票证密钥加密的会话状态并将其暴露在线路上。有些实现中的票证密钥可能会比连接使用的密码要弱。如果票证密钥被暴露，就可以解密连接上的全部数据。因此，使用会话票证时，票证密钥需要频繁轮换。

References

转载于:https://juejin.im/post/5b88a93df265da43231f1451

 

三、利用wireshark进行SSL/TLS协议的验证---以登陆163邮箱为例子
确保浏览器开启了SSL、TLS功能

 

 

 TLS数据包列表

 

 

 

 客户端 Client Hello 报文

 

 

 


server hello报文

 

 

 

服务器认证报文
————————————————
版权声明：本文为CSDN博主「Chaos_Ju」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/chaosju/article/details/39897799

 

posted @ 2021-08-17 09:44  常给自己加个油  阅读(5828)  评论(0)  编辑  收藏  举报