基于ECDHE的TLS握手流程

<!doctype html>3.3 基于ECDHE的TLS握手流程

3.3 基于ECDHE的TLS握手流程

image-20210912155522430

上图便是一个基于HTTPS通讯的完整过程,涉及:

  • TCP三次握手
  • TLS握手
  • 加密数据传输
  • TCP四次挥手

下面主要着重介绍基于ECDHE的TLS的握手流程。

image-20210912180439743

3.3.1 TLS第一次握手

image-20210912161218021

客户端首先发送一个【ClientHello】消息作为TLS握手的开始。该消息中主要包含:TLS的版本号客户端随机数(Client Random), 密钥套件列表以及SessionID信息

如果报文中的SessionID不为空,则说明客户端想复用此session的密码信息。服务端如果同意则在ServerHello中使用相同的SessionID, 如果不同意则重新生成一个新的SessionID。

这里说一下:密码套件的格式

TLS的密钥套件不同于IPSec密钥套件。

  • IPSec密钥套件中加密算法、哈希算法、认证算法可以互相自由组合,协商的是每一种算法,最后组合成一个密码套件。
  • 而TLS则直接协商密码套件,每一种密码套件中密码算法组合是固定的。

TLS密码套件组合方式:

TLS——密钥交换算法——签名算法——WITH——加密算法——摘要算法

其中密钥交换算法和签名算法可以合二为一。

image-20210912173742535

3.3.2 TLS第二次握手

TLS第二次握手报文包含的内容比较多。有时候一个报文包含所有载荷,有时各个载荷单独发送。如果看到单独发送的载荷,莫要奇怪。

image-20210912174546599

第二次握手主要包含了四个载荷:

  • Server Hello
  • Certificate
  • Server Key Exchange
  • Server Hello Done

下面分别介绍这四个载荷:

Server Hello载荷内容

image-20210912180951271

Server Hello中的内容与Client Hello中基本一致。包括:TLS版本号, 服务器端的随机数(Server Random), 服务器端想要使用的SessionID,服务器端选择的加密套件

如果此SessionID与ClientHello中的SessionID相同,则说明服务器同意复用此session; 如果不同则说明需要进行重新协商。我这次抓的报文两者sessionID并不相同,因此需要完整的TLS协商流程。

服务端选择的算法套件是:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), 它的意思是:

  • 密钥交换算法采用:ECDHE

  • 签名算法采用:RSA

  • 加密算法采用:AES对称算法,密钥长度为256bit, 模式为:GCM。

  • 摘要算法采用:SHA284

服务端证书载荷

image-20210912182634850

证书载荷中可以包含多个证书。一个或者两个比较常见。如果是一个,则是服务端证书;如果是两个,则另一个一般是服务端CA,用来验证服务端证书。

Server Key Exchange

由于采用的是ECDHE进行密钥交换,因此服务端需要将采用的椭圆曲线信息公共值信息发送给客户端。此外为了防止信息被篡改,服务端使用RSA算法对DH公钥做一个签名。这个Pubkey???

image-20210912182954558

 

Server Hello Done

最后发送一个ServerHelloDone消息,表明:“这就是Server Hello阶段发送的所有信息,你可以忙活了”。它的报文内容很简单,啥也没有。

image-20210912183330474

 

握手阶段交互完毕,通过Hello阶段握手,客户端和服务端交换的信息如下:Client Random, Server Random, 使用的椭圆曲线,椭圆曲线公钥。

 

3.3.3 TLS第三次握手

客户端收到服务端的ServerHello阶段信息后,首先会对服务端的证书进行验证,验证服务端证书可能涉及认证链的问题。如果验证通过,说明当前服务器身份没有问题。如果验证不通过,则会提示相应的错误信息(好像是Bad certificate)。对服务端的身份认证一般情况下是可以设置的,客户端可以选择验证也可以不验证

服务端验证完毕后,客户端会生成一个随机数,作为ECDHE的临时私钥,并通过服务端在ServerKeyExchange中发送的椭圆曲线参数,计算出自己的ECDHE公钥信息。然后通过ClientKeyExchange发送给服务端。

image-20210912191459710

之后,客户端会根据手里中的信息:Client Random, Server Random, ECDHE协商出的共享密钥,计算出会话密钥(主密钥)。 其他密钥都是在此基础上依次获取的。密钥计算完毕后,发送ChangeCipherSpec消息,通知服务端后续报文采用新协商的安全参数进行安全通讯。

image-20210912191734223

最后发送一个Encrypted Handshake Message消息,把之前所有的握手报文做一个摘要,然后使用协商的对称密钥进行加密发送给服务端。依次来验证双方本次握手协商的安全参数是否可用。

image-20210912192028102

 

3.3.4 TLS第四次握手

第四次握手与第三次握手非常相似。服务器端收到ClientKeyExchange后,获取到里面的客户端DH算法公钥,计算出ECDHE协商出的共享密钥。 然后在利用手中的Client Random, Server Random, ECDHE协商出的共享密钥计算出会话密钥。最后根据会话密钥依次生成其他密钥。

在此过程中服务端同样会发送ChangeCipherSpec,通知客户端,麻溜采用新协商的安全参数进行通讯,以后发给你的数据全部进行加密。此外服务端同样对所有的握手报文做一个摘要,并进行加密然后给客户端发送一个Encrypted Handshake Message消息,验证客户端是否可以正常解密。

image-20210912192757290

至此, 基于ECDHE的TLS协商完毕。之后双方使用协商出的安全参数进行加密通讯。加密的应用层协议使用TLS Record Layer Protocal进行封装。

image-20210912193039813

参考文档

  1. RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1
  2. 小林coding的《图解网络》
posted @ 2021-09-12 23:39  叨陪鲤  阅读(66)  评论(0编辑  收藏  举报