基于ECDHE的TLS握手流程
-
客户端首先发送一个ClientHello消息作为TLS握手的开始。该消息中主要包含:TLS的版本号, 客户端随机数(Client Random), 密钥套件列表以及SessionID信息。
如果报文中的SessionID不为空,则说明客户端想复用此session的密码信息。服务端如果同意则在ServerHello中使用相同的SessionID, 如果不同意则重新生成一个新的SessionID。
TLS的密钥套件不同于IPSec密钥套件。IPSec密钥套件中加密算法、哈希算法、认证算法可以互相自由组合,协商的是每一种算法,最后组合成一个密码套件。而TLS则直接协商密码套件,每一种密码套件中密码算法组合是固定的。
TLS第二次握手报文包含的内容比较多。有时候一个报文包含所有载荷,有时各个载荷单独发送。如果看到单独发送的载荷,莫要奇怪。第二次握手主要包含了四个载荷:
Server Hello:Server Hello中的内容与Client Hello中基本一致。包括:TLS版本号, 服务器端的随机数(Server Random), 服务器端想要使用的SessionID,服务器端选择的加密套件。
如果此SessionID与ClientHello中的SessionID相同,则说明服务器同意复用此session; 如果不同则说明需要进行重新协商。我这次抓的报文两者sessionID并不相同,因此需要完整的TLS协商流程。Certificate,Server Key Exchange,Server Hello Done。
TLS第三次握手:客户端收到服务端的ServerHello阶段信息后,首先会对服务端的证书进行验证,验证服务端证书可能涉及认证链的问题。如果验证通过,说明当前服务器身份没有问题。如果验证不通过,则会提示相应的错误信息(好像是Bad certificate)。对服务端的身份认证一般情况下是可以设置的,客户端可以选择验证也可以不验证。服务端验证完毕后,客户端会生成一个随机数,作为ECDHE的临时私钥,并通过服务端在ServerKeyExchange中发送的椭圆曲线参数,计算出自己的ECDHE公钥信息。然后通过ClientKeyExchange发送给服务端。
第四次握手与第三次握手非常相似。服务器端收到ClientKeyExchange后,获取到里面的客户端DH算法公钥,计算出ECDHE协商出的共享密钥。 然后在利用手中的Client Random, Server Random, ECDHE协商出的共享密钥计算出会话密钥。最后根据会话密钥依次生成其他密钥。在此过程中服务端同样会发送ChangeCipherSpec,通知客户端,麻溜采用新协商的安全参数进行通讯,以后发给你的数据全部进行加密。此外服务端同样对所有的握手报文做一个摘要,并进行加密然后给客户端发送一个Encrypted Handshake Message消息,验证客户端是否可以正常解密。
西南地区IT社群(QQ)
- 云南
- 【昆明网页设计交流吧】243627302
- 【昆明nodejs交流吧】 243626749
- 【VUE】838405306
- 【云南程序员总群】343606807
- 【昆明UI设计】104031254
- 【云南软件外包】15547313
- 贵州
- 【PHP/java源码/站长交流群】55692114
- 四川
- 【成都Java/JavaWeb交流】86669225
- 【vaScript+PHP+MySql】116270060
- 【UI设计/设计交流学习群】135794928
- 重庆
- 【诺基亚 JAVA游戏博物馆】 559479780
- 【PHP,Java,Python,C++接单】 442103442
- 西藏