图解TLS握手连接

* 00 00 - 这个值表示扩展名为‘Server Name’

* 00 13 - Extension Length

* 00 11 - Server Name list length

* 00 - list entry is type 0x00 "DNS hostname"

* 00 0e - Server Name Length

* 65 78 61 ... 6e 65 74 - 表示服务器名

1.10 Extension - Status Request

客户端为服务器提供在其响应中提供OCSP信息的权限。OCSP可用于检查证书是否已被撤销。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，而服务器用填充了数据的扩展进行应答。

00 05 00 05 01 00 00 00 00

1.11 Extension - Supported Groups

客户端表示支持4条曲线的椭圆曲线加密。这个扩展最初被命名为“椭圆曲线”，但现在被重命名为“受支持的组”，以便与其他加密类型通用。

1.12 Extension - EC Point Formats

在椭圆曲线(EC)加密期间，客户机和服务器将以压缩或未压缩的形式交换所选点上的信息。这个扩展表明客户机只能解析来自服务器的未压缩信息。在下一版本的TLS中，不存在协商点的能力(而是为每个曲线预先选择了一个点)，因此不会发送此扩展。

1.13 Extension - Signature Algorithms

随着TLS的发展，有必要支持更强大的签名算法，如SHA-256，同时仍然支持使用MD5和SHA1的早期实现。此扩展指示客户机能够理解哪些签名算法，并可能影响服务器发送给客户机的证书的选择。

1.14 Extension - Renegotiation Info

该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

1.15 Extension - SCT

客户端为服务器提供返回签名证书时间戳的权限。客户端发送空扩展的这种形式是必要的，因为服务器使用客户端首先没有提供的扩展进行应答是一个致命错误。因此，客户端发送一个空形式的扩展，服务器使用填充了数据的扩展进行响应，或者根据发送扩展的客户端更改行为。

2. Server Hello

服务器回以“你好”。服务器提供以下信息:

2.1 Record Header

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

2.2 Handshake Header

每个握手消息都以类型和长度开始。

2.3 服务器TLS版本

给出了协议版本“3,3”(TLS 1.2)。不寻常的版本号(“3,3”表示TLS 1.2)是由于TLS 1.0是SSL 3.0协议的一个小修订。

03 03 - TLS Version = 1.2

2.4 服务器随机数

服务器提供32字节的随机数据。在本例中，我们将随机数据设置为可预测的字符串。

2.5 会话ID

服务器可以为这个会话提供一个ID，客户机可以在以后的会话协商中提供这个ID，以便重用关键数据并跳过大多数TLS协商过程。为了使其工作，服务器和客户端都将来自前一个连接的密钥信息存储在内存中。恢复连接可以节省大量的计算和网络往返时间，因此只要有可能就会执行连接。

2.6 服务器选择的加密方式

服务器从客户机提供的选项列表中选择了密码套件0xC02F (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)。

其中SHA256就是客户端和服务端使用的HMAC算法

2.7 服务器选择的压缩方式

服务器从客户机提供的选项列表中选择了压缩方法0x00(“Null”，它不执行压缩)。

2.8 Extension长度

服务器向客户端返回了一个扩展列表。由于禁止服务器使用客户机没有发送其hello消息的扩展进行应答，所以服务器知道客户机将支持列出的所有扩展。

2.9 Extension - Renegotiation Info

该扩展的存在防止了使用TLS重新协商执行的攻击类型。重新协商连接的能力已经从该协议的下一个版本(TLS 1.3)中移除，因此将来不再需要这个扩展。

2.10 Extended Master Secret

无“Extended Master Secret”

master_secret = PRF(pre_master_secret, "主秘钥", ClientHello.random + ServerHello.random)[0..47]

具有“Extended Master Secret”

master_secret = PRF(pre_master_secret，“扩展的主密钥”，session_hash)[0..47];

session_hash = hash(handshake_message)

3. Server Certificate

服务器提供一个包含以下内容的证书:

这里先介绍下证书认证的过程：

1). 服务器发送给浏览器端的证书只有public key, 服务器端保存着private key。

2). client随机生成一串数，用server这里的public key加密，发给server

3). server用private key解密后返回给client

4). client与原文比较，如果一致，则说明server拥有private key，也就说明与client通信的正是证书的拥有者服务器加密方式，因为public key加密的数据，只有private key才能解密

3.1 Record Heade

TLS会话被分解为“记录”的发送和接收，“记录”是具有类型、协议版本和长度的数据块。

3.2 Handshaker Heade

每个握手消息都以类型和长度开始。

3.3 Certificate Length

证书消息以随后的所有证书数据的长度开始。

* 00 03 28- 0x328 (808) bytes of certificate list follows

3.4 Certificate

证书采用ASN.1 DER二进制编码。这种编码由以下序列中的记录组成:类型标记、长度、数据。

type标签包含以下信息:

type class (2 bits):通用的、应用程序的、特定于上下文的或私有的

constructed (1 bit):如果记录由更小的记录组成，则设置

type (5 bits):如果类型类是通用类型，那么类型表示整数、ASCII字符串、对象ID等。

4. Server Key Exchange

服务器提供了密钥交换信息。作为密钥交换过程的一部分，客户端需要拥有一组公钥+私钥，公钥用于加密发送的数据, 私钥用于解密服务器发送过来的数据。并且将互相发送对方的公钥。然后，将使用各方的私钥和另一方的公钥的组合生成共享加密密钥。

双方同意使用ECDHE密码套件,这意味着密钥对将基于选择的椭圆曲线,diffie - hellman,密钥对都是暂时的(为每个连接生成),而不是使用的公钥/私钥证书。

4.1 Record Header && HandShaker Header

略

4.2 Curve info

服务器选择椭圆曲线, 椭圆曲线上的所有点。

4.3 Public Key

服务器端提供的公钥来自于之前的步骤 "Server Key Exchange Generation".

4.4 Signature

因为服务器正在生成临时密钥，所以它没有使用服务器证书中提供的公钥。为了证明服务器拥有服务器证书(在TLS会话中提供证书有效性)，它使用证书的私钥签署临时公钥。可以使用证书的公钥验证此签名。

我们可以自己计算签名使用服务器的私钥.

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!