SSL/TLS 握手过程详解

CDN测评 0 280

HTTPS加密协议详解(一):HTTPS基础知识 


HTTPS基础知识:HTTPS (Secure Hypertext Transfer Protocol)安全超文本传输协议,是一个安全通信通道,它基于HTTP开发用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,简单来说它是HTTP的安全版,是使用TLS/SSL加密的HTTP协议。


HTTP协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能,可以避免此类问题发生。


TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议,不影响原有的TCP协议和HTTP协议,所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。


更多HTTPS基础知识参考:HTTPS和HTTP的区别



HTTPS加密协议详解(二):TLS/SSL工作原理


HTTPS协议的主要功能基本都依赖于TLS/SSL协议,本节分析TLS/SSL协议工作原理。


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



散列函数Hash


常见的有 MD5、SHA1、SHA256,该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定,针对数据的任何修改都会改变散列函数的结果,用于防止信息篡改并验证数据的完整性;


在信息传输过程中,散列函数不能单独实现信息防篡改,因为明文传输,中间人可以修改信息之后重新计算信息摘要,因此需要对传输的信息以及信息摘要进行加密;


对称加密


常见的有 AES-CBC、DES、3DES、AES-GCM等,相同的密钥可以用于信息的加密和解密,掌握密钥才能获取信息,能够防止信息窃听,通信方式是1对1;


对称加密的优势是信息传输1对1,需要共享相同的密码,密码的安全是保证信息安全的基础,服务器和 N 个客户端通信,需要维持 N 个密码记录,且缺少修改密码的机制;


非对称加密


即常见的 RSA 算法,还包括 ECC、DH 等算法,算法特点是,密钥成对出现,一般称为公钥(公开)和私钥(保密),公钥加密的信息只能私钥解开,私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息,只能和掌握私钥的服务器进行加密通信,服务器可以实现1对多的通信,客户端也可以用来验证掌握私钥的服务器身份。


非对称加密的特点是信息传输1对多,服务器只需要维持一个私钥就能够和多个客户端进行加密通信,但服务器发出的信息能够被所有的客户端解密,且该算法的计算复杂,加密速度慢。


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


图片1.png

HTTPS加密协议详解(三):PKI 体系


1、RSA身份验证的隐患


身份验证和密钥协商是TLS的基础功能,要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性,因为公钥并不包含服务器的信息,存在安全隐患:


客户端C和服务器S进行通信,中间节点M截获了二者的通信;


节点M自己计算产生一对公钥pub_M和私钥pri_M;


C向S请求公钥时,M把自己的公钥pub_M发给了C;


C使用公钥 pub_M加密的数据能够被M解密,因为M掌握对应的私钥pri_M,而 C无法根据公钥信息判断服务器的身份,从而 C和 M之间建立了"可信"加密连接;


中间节点 M和服务器S之间再建立合法的连接,因此 C和 S之间通信被M完全掌握,M可以进行信息的窃听、篡改等操作。


另外,服务器也可以对自己的发出的信息进行否认,不承认相关信息是自己发出。


因此该方案下至少存在两类问题:中间人攻击和信息抵赖。



2、身份验证CA和证书


解决上述身份验证问题的关键是确保获取的公钥途径是合法的,能够验证服务器的身份信息,为此需要引入权威的第三方机构CA(如沃通CA)。CA 负责核实公钥的拥有者的信息,并颁发认证"证书",同时能够为使用者提供证书验证服务,即PKI体系(PKI基础知识)。


基本的原理为,CA负责审核信息,然后对关键信息利用私钥进行"签名",公开对应的公钥,客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书,基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下:



a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;


b.CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;


c.如信息审核通过,CA会向申请者签发认证文件-证书。


证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;


签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA的私钥对信息摘要进行加密,密文即签名;


d.客户端 C 向服务器 S 发出请求时,S 返回证书文件;


e.客户端 C读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;


f.客户端然后验证证书相关的域名信息、有效时间等信息;


g.客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA的证书,证书也会被判定非法。


在这个过程注意几点:


a.申请证书不需要提供私钥,确保私钥永远只能服务器掌握;


b.证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;


c.内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书(为什么说"部署自签SSL证书非常不安全")


d.证书=公钥+申请者与颁发者信息+签名;


3、证书链


如 CA根证书和服务器证书中间增加一级证书机构,即中间证书,证书的产生和验证原理不变,只是增加一层验证,只要最后能够被任何信任的CA根证书验证合法即可。


a.服务器证书 server.pem 的签发者为中间证书机构 inter,inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;


b.中间证书 inter.pem 的签发 CA 为 root,root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;


c.客户端内置信任 CA 的 root.pem 证书,因此服务器证书 server.pem 的被信任。



服务器证书、中间证书与根证书在一起组合成一条合法的证书链,证书链的验证是自下而上的信任传递的过程。


二级证书结构存在的优势:


a.减少根证书结构的管理工作量,可以更高效的进行证书的审核与签发;


b.根证书一般内置在客户端中,私钥一般离线存储,一旦私钥泄露,则吊销过程非常困难,无法及时补救;


c.中间证书结构的私钥泄露,则可以快速在线吊销,并重新为用户签发新的证书;


d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。



证书链有以下特点:


a.同一本服务器证书可能存在多条合法的证书链。


因为证书的生成和验证基础是公钥和私钥对,如果采用相同的公钥和私钥生成不同的中间证书,针对被签发者而言,该签发机构都是合法的 CA,不同的是中间证书的签发机构不同;


b.不同证书链的层级不一定相同,可能二级、三级或四级证书链。


中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构,所以证书链层级不一定相同。


4、证书吊销


CA 机构能够签发证书,同样也存在机制宣布以往签发的证书无效。证书使用者不合法,CA 需要废弃该证书;或者私钥丢失,使用者申请让证书无效。主要存在两类机制:CRL 与 OCSP。


a.CRL


Certificate Revocation List, 证书吊销列表(什么是证书吊销列表(CRL)?吊销列表起什么作用),一个单独的文件。该文件包含了 CA 已经吊销的证书序列号(唯一)与吊销日期,同时该文件包含生效日期并通知下次更新该文件的时间,当然该文件必然包含 CA 私钥的签名以验证文件的合法性。


证书中一般会包含一个 URL 地址 CRL Distribution Point,通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新,但是不能及时吊销证书,因为 CRL 更新时间一般是几天,这期间可能已经造成了极大损失。


b.OCSP


Online Certificate Status Protocol, 证书状态在线查询协议,一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询,服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址,要求查询服务器具有良好的性能。部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的,对于吊销证书会是一件非常麻烦的事情。


啥?你问四在哪?当然在前面了


HTTPS加密协议详解(五):HTTPS性能与优化


1、HTTPS性能损耗


前文讨论了HTTPS原理与优势:身份验证、信息加密与完整性校验等,且未对TCP和HTTP协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价,HTTPS协议的性能损耗主要体现如下:


(1).增加延时


分析前面的握手过程,一次完整的握手至少需要两端依次来回两次通信,至少增加延时2* RTT,利用会话缓存从而复用连接,延时也至少1* RTT*。


(2).消耗较多的CPU资源


除数据传输之外,HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU:对称加密算法AES-CBC-256 吞吐量 600Mbps,非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销,10G 网卡为对称加密需要消耗 CPU 约17核,24核CPU最多接入 HTTPS 连接 4800;


静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s,如果将所有的HTTP连接变为HTTPS连接,则明显RSA的解密最先成为瓶颈。因此,RSA的解密能力是当前困扰HTTPS接入的主要难题。


2、HTTPS接入优化


(1).CDN接入


HTTPS 增加的延时主要是传输延时 RTT,RTT 的特点是节点越近延时越小,CDN 天然离用户最近,因此选择使用 CDN 作为 HTTPS 接入的入口,将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法,极大减少 HTTPS 带来的延时。


(2).会话缓存


虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时,但是至少延时已经减少为原来的一半,明显的延时优化;同时,基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息,可以省去CPU 的消耗。如果业务访问连接集中,缓存命中率高,则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%,10k/s的接入资源实际可以承载13k/的接入,收效非常可观。


(3).硬件加速


为接入服务器安装专用的SSL硬件加速卡,作用类似 GPU,释放 CPU,能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力,相当于175核 CPU,至少相当于7台24核的服务器,考虑到接入服务器其它程序的开销,一张硬件卡可以实现接近10台服务器的接入能力。


(4).远程解密


本地接入消耗过多的 CPU 资源,浪费了网卡和硬盘等资源,考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器,如此则可以充分发挥服务器的接入能力,充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当,实现机器资源复用,也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。


(5).SPDY/HTTP2


前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能,但是方法都基于不改变 HTTP 协议的基础上提出的优化方法,SPDY/HTTP2 利用 TLS/SSL 带来的优势,通过修改协议的方法来提升 HTTPS 的性能,提高下载速度等。

我们知道,HTTP 协议都是明文传输内容,在早期只展示静态内容时没有问题。伴随着互联网的快速发展,人们对于网络传输安全性的要求也越来越高,HTTPS 协议因此出现。如上图所示,在 HTTPS 加密中真正起作用的其实是 SSL/TLS 协议。SSL/TLS 协议作用在 HTTP 协议之下,对于上层应用来说,原来的发送接收数据流程不变,这就很好地兼容了老的 HTTP 协议,这也是软件开发中分层实现的体现。


SSL/TLS 握手是为了安全地协商出一份对称加密的秘钥,这个过程很有意思,下面我们一起来了解一下。


以下内容需要你对加解密、数字签名和数字证书的概念有一定了解,这里有一篇文章可以帮你快速了解这几个概念。


SSL/TLS 握手过程


上图大致描述了 SSL/TLS 的握手过程,但缺少了一些信息不利于理解,我会在后面的讲解里再列出来。


Client Hello

握手第一步是客户端向服务端发送 Client Hello 消息,这个消息里包含了一个客户端生成的随机数 Random1、客户端支持的加密套件(Support Ciphers)和 SSL Version 等信息。通过 Wireshark 抓包,我们可以看到如下信息:



Wireshark 抓包的用法可以参考这篇文章

Server Hello

第二步是服务端向客户端发送 Server Hello 消息,这个消息会从 Client Hello 传过来的 Support Ciphers 里确定一份加密套件,这个套件决定了后续加密和生成摘要时具体使用哪些算法,另外还会生成一份随机数 Random2。注意,至此客户端和服务端都拥有了两个随机数(Random1+ Random2),这两个随机数会在后续生成对称秘钥时用到。



Certificate

这一步是服务端将自己的证书下发给客户端,让客户端验证自己的身份,客户端验证通过后取出证书中的公钥。



Server Key Exchange

如果是DH算法,这里发送服务器使用的DH参数。RSA算法不需要这一步。



Certificate Request

Certificate Request 是服务端要求客户端上报证书,这一步是可选的,对于安全性要求高的场景会用到。


Server Hello Done

Server Hello Done 通知客户端 Server Hello 过程结束。



Certificate Verify

客户端收到服务端传来的证书后,先从 CA 验证该证书的合法性,验证通过后取出证书中的服务端公钥,再生成一个随机数 Random3,再用服务端公钥非对称加密 Random3 生成 PreMaster Key


Client Key Exchange

上面客户端根据服务器传来的公钥生成了 PreMaster Key,Client Key Exchange 就是将这个 key 传给服务端,服务端再用自己的私钥解出这个 PreMaster Key 得到客户端生成的 Random3。至此,客户端和服务端都拥有 Random1 + Random2 + Random3,两边再根据同样的算法就可以生成一份秘钥,握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢?这是因为 SSL/TLS 握手过程的数据都是明文传输的,并且多个随机数种子来生成秘钥不容易被暴力破解出来。客户端将 PreMaster Key 传给服务端的过程如下图所示:



Change Cipher Spec(Client)

这一步是客户端通知服务端后面再发送的消息都会使用前面协商出来的秘钥加密了,是一条事件消息。



Encrypted Handshake Message(Client)

这一步对应的是 Client Finish 消息,客户端将前面的握手消息生成摘要再用协商好的秘钥加密,这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密,能解出来说明前面协商出来的秘钥是一致的。



Change Cipher Spec(Server)

这一步是服务端通知客户端后面再发送的消息都会使用加密,也是一条事件消息。


Encrypted Handshake Message(Server)

这一步对应的是 Server Finish 消息,服务端也会将握手过程的消息生成摘要再用秘钥加密,这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密,能解出来说明协商的秘钥是一致的。



Application Data

到这里,双方已安全地协商出了同一份秘钥,所有的应用层数据都会用这个秘钥加密后再通过 TCP 进行可靠传输。


双向验证

前面提到 Certificate Request 是可选的,下面这张图展示了双向验证的过程:



握手过程优化

如果每次重连都要重新握手还是比较耗时的,所以可以对握手过程进行优化。从下图里我们看到 Client Hello 消息里还附带了上一次的 Session ID,服务端接收到这个 Session ID 后如果能复用就不再进行后续的握手过程。



除了上述的 Session 复用,SSL/TLS 握手还有一些优化技术,例如 False Start、Session Ticket 等,这方面的介绍具体可以参考这篇文章。


总结

前面我们一起详细地了解了整个 SSL/TLS 的握手过程,这部分知识在平时的开发过程中很少用到,但能让我们更清楚地了解 HTTPS 的工作原理,而不仅仅是只知道 HTTPS 会加密数据十分安全。同时这个过程也是各种加密技术的一个经典运用,也能帮助我们加深加密相关技术的理解。最后,建议大家也用 Wireshark 实际抓包体验一下这个过程来加深印象,enjoy~


图片1.png

参考资料

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html


https://segmentfault.com/a/1190000002554673


https://imququ.com/post/optimize-tls-handshake.html


http://blog.csdn.net/fw0124/article/details/40983787




HTTPs握手流程抓包解析





59cc1ed91a0be72a7148e18635b6ea4db84e0664.png@942w_174h_progressive.webp








TLS Handshake Flow:


以下是访问 https://github.com 的 wireshark 抓包截图:


C->S:Client Hello


S->C:Server Hello


S->C:Certificate, Server Key Exchange, Server Hello Done


C->S:Client Key Change


C->S:Change Cipher Spec


C->S:Encryted Handshake Message


S->C:Change Cipher Spec, Encryted Handshake Message


C->S/S->C:Application Data


第 1、2、3、4、6、7.2 步均为 TLSv1.2 Record Layer 中的 Handshake Protocol

第 5、7.1 步为 TLSv1.2 Record Layer 中的 Change Cipher Spec Protocol

第 8 步为 TLSv1.2 Record Layer 中的 Application Data Protocol: http-over-tls。


与 rfc4492-Message_flow_in_a_full_TLS_handshake 对比,服务器没有要求 client authentication,即不涉及 *+ 步骤。


在 Wireshark 解析树中,TLS 被解析为 Secure Sockets Layer。


The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.

TLS wraps all traffic in “records” of different types. A TLS message may span multiple TLS records.

The handshake record is broken out into several messages.


Client Hello

TLSv1.2 Record Layer: Handshake Protocol: Client Hello


”ssl.record.content_type=0x16

    ssl.handshake.type=0x01


  • TLS Version

  • Random

  • Cipher Suites

  • Compression Methods

  • Extension: server_name(Server Name Indication extension)

  • Extension: elliptic_curves(EllipticCurveList)

  • Extension: ec_point_formats(ECPointFormatList)

  • Extension: signature_algorithms

  • Extension: next_protocol_negotiation

  • Extension: Application Layer Protocol Negotiation(ALPN Protocol)

  • Extension: signed_certificate_timestamp

  • Extension: Extended Master Secret


ssl.record 头部的 Version 为 TLS 1.0(0x0301),为客户端首次发起 Hello 选择的最低版本。ssl.handshake 报文中的 Version 为 TLS 1.2(0x0303),为客户端支持的 TLS 最高版本。


所有的枚举能力项(Cipher Suites,Compression Methods,elliptic_curves,ec_point_formats,signature_algorithms,etc)都是按照从高到低的优先级排列(favorite choice first)。


Signature Hash Algorithm 包括 Hash 算法 和 Signature 算法。


Server Hello

TLSv1.2 Record Layer: Handshake Protocol: Server Hello


“ssl.record.content_type=0x16

   ssl.handshake.type=0x02


  • TLS Version

  • Random

  • Session ID,  (黑体新增)

  • Cipher Suite,  (斜体协定)

  • Compression Method

  • Extension: renegotiation_info

  • Extension: server_name(Server Name Indication extension)

  • Extension: ec_point_formats(ECPointFormatList)

  • Extension: Extended Master Secret

  • Extension: Application Layer Protocol Negotiation(ALPN Next Protocol: http/1.1)


ssl.record 头部的 Version 为 TLS 1.2(0x0303),表示 Server 回应 Hello 使用的版本为 TLS  1.2。ssl.handshake 报文中的 Version 也为 TLS 1.2(0x0303)。


Hello Extensions is “client-oriented”:


the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello.

the extended server hello message is only sent in response to an extended client hello message.


ssl.record 总长117,各部分长度构成如下:


  • sizeof(ssl.record.content_type)=1

  • sizeof(ssl.record.version)=2

  • sizeof(ssl.record.length)=2

  • sizeof(ssl.handshake)=112


报文(#8)  帧长 1490(tcp payload 长度为 1424),出现了 TCP 报文流粘连,117 字节的 Server Hello 后面还有 1307 个字节是服务器发送的证书报文。


Certificate

TLSv1.2 Record Layer: Handshake Protocol: Certificate


”ssl.record.content_type=0x16

   ssl.handshake.type=0x0b


This message conveys the server’s certificate chain to the client.


报文(#8) 包含证书的前 1307 个字节,报文(#9)为证书的中间部分(TCP Segment Len: 1424)。


报文(#10) 帧长 827(tcp payload 长度为 761),也出现了 TCP 报文流粘连:


  • 414 字节的证书结尾部分;

  • 338 字节的 Server Key Exchange 报文;

  • 9 字节的 Server Hello Done 报文。


整个证书 Certificate 报文由3个TCP流组成:


[3 Reassembled TCP Segments (3145 bytes): #8(1307), #9(1424), #10(414)]


ssl.record 各部分长度构成如下:


  • sizeof(ssl.record.content_type)=1

  • sizeof(ssl.record.version)=2

  • sizeof(ssl.record.length)=2

  • sizeof(ssl.handshake)=3140


正如 rfc4492 所述,The server’s Certificate message is capable of carrying a chain of certificates.

Certificate 报文下发了 GitHub 机构旗下 github.com 网站的证书及其颁发机构 DigiCert 的证书:


// 二级证书(1917 bytes)Certificate: 3082077930820661a00302010202100bfdb4090ad7b5e640... (id-at-commonName=github.com,id-at-organizationName=GitHub, Inc.,id-at-localityName=San Francisco,id-at-stateOrProvinceName=California,id-at-countryName=US,id-at-postalCode=9// 一级证书(1210 bytes)Certificate: 308204b63082039ea00302010202100c79a944b08c119520... (id-at-commonName=DigiCert SHA2 Extended Validation Server CA,id-at-organizationalUnitName=www.digicert.com,id-at-organizationName=DigiCert Inc,id-at-countryName=US)
  • 1

  • 2

  • 3

  • 4

  • 5


在 wireshark 中可依次展开 Certificate|signedCertificate 查看证书颁发机构(issuer)和证书持有主体(subject)信息及其公钥信息(subjectPublicKeyInfo)。其中 signature 指定了认证签密算法,encrypted 部分为使用 DigiCert 私钥加过密的签名。


也可右键菜单 导出分组字节流,可导出 Certificate 字段值的分组字节流(raw 二进制),并保存为 *.cer。在 macOS 下双击自动将证书导入钥匙串(Keychain Access),然后在钥匙串中可双击打开查看证书内容。


Actions of the receiver

The client validates the certificate chain, extracts the server’s public key, and checks that the key type is appropriate for the negotiated key exchange algorithm.


Server Key Exchange

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange


“ssl.record.content_type=0x16

   ssl.handshake.type=0x0c


This message is used to convey the server’s ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client.


交换 ECDH 参数(EC Diffie-Hellman Server Params):


  • TLS Version

  • Curve Type: named_curve

  • Named Curve: secp256r1

  • Pubkey

  • Signature Hash Algorithm(Hash: SHA512, Signature: RSA)

  • Signature


传输了 Curve Type 及其对应值(elliptic curve domain parameters)、Pubkey(The ephemeral ECDH public key) 及其对应签名(及其散列签名算法)。


Actions of the sender/receiver

The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [6].


The client verifies the signature (when present) and retrieves the server’s elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message.


Server Hello Done

TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done


“ssl.record.content_type=0x16

   ssl.handshake.type=0x0e


The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages.

After sending this message, the server will wait for a client response.


Client Key Exchange

TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange


”ssl.record.content_type=0x16

   ssl.handshake.type=0x10


交换 ECDH 参数(EC Diffie-Hellman Client Params):


  • TLS Version

  • Pubkey


It MUST immediately follow the client certificate message, if it is sent.  Otherwise, it MUST be the first message sent by the client after it receives the ServerHelloDone message.


With this message, the premaster secret is set, either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret.


Actions of the sender/receiver

The client selects an ephemeral ECDH public key corresponding to the  

parameters it received from the server according to the ECKAS-DH1  scheme from IEEE 1363 [6].


The server retrieves the client’s ephemeral ECDH public key from the  ClientKeyExchange message and checks that it is *on the same elliptic  

curve* as the server’s ECDH key.


Change Cipher Spec(C)

“ssl.record.content_type=0x14


  • TLS Version

  • Change Cipher Spec Message


The change cipher spec protocol exists to signal transitions in ciphering strategies.

It means has finished computing the new keying material.


The ChangeCipherSpec message is sent during the handshakeafter the security parameters have been agreed upon, but before the verifying Finished message is sent.


The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.


Reception of this message causes the receiver to instruct the record layer to immediately copy the read pending state into the read current state.

Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state.


Encryted Handshake Message(C)

TLS Client Finished


”ssl.record.content_type=0x16


  • TLS Version

  • Encrypted Handshake Message


verify that their peer has calculated the same security parameters.


A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful.

It is essential that a change cipher spec message be received between the other handshake messages and the Finished message.


The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets.

Recipients of Finished messages MUST verify that the contents are correct.

Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.


Change Cipher Spec(S)

“ssl.record.content_type=0x14


  • TLS Version

  • Change Cipher Spec Message


机制同 Change Cipher Spec(C)。


Encryted Handshake Message(S)

TLS Server Finished


“ssl.record.content_type=0x16


  • TLS Version

  • Encrypted Handshake Message


机制同 Encryted Handshake Message(C)。


图片1.png

参考

从wireshark抓包开始学习https

传输层安全协议抓包分析之SSL/TLS  


续接上篇《HTTPs握手流程抓包解析》,本篇补充阐述了  TLS 握手协商机制流程细节。


按照惯例,还是先贴上 TLS Handshake Flow,方便对照跟踪整体流程。




Hello 协商加密套件与密码套件

在 Client Hello 报文中,客户端告诉服务器自己支持的 TLS Version、Cipher Suites、Compression MethodsExtension(server_name,elliptic_curves,ec_point_formats(Elliptic curves point formats),signature_algorithms,ALPN Protocol,Extended Master Secret) 等信息。


服务器收到 Client Hello 后,会结合双方支持的加密基础设施(proposed by the client and supported by the server),给客户端回应  Server Hello 反馈(in response to)选择的 TLS 版本以及密码套件(common Cipher Suite)。


在 Packet 8 Server Hello  中包含 elliptic_curves 和 signature_algorithms 等 Extension,协商出的 Cipher Suite 为 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。


TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 解构如下:


1、ECDHE_RSA:密钥协商交换算法


”rfc4492 & rfc5289 定义了该 CipherSuite 的具体实现。

the long term authenticity is confirmed via the server cert’s RSA signature but the transient keys are derived via ephemeral EC keys (which then generate the symmetric key)

 ECDHE-RSA uses Diffie-Hellman on an elliptic curve group while DHE-RSA uses Diffie-Hellman on a modulo-prime group.


  • ECDHE:使用基于椭圆曲线签密方案(EC, Elliptic Curve)的 Diffie-Hellman(DH)密钥协商协议。尾部的E为 Ephemeral 首字母,表示协商的是临时会话密钥。相对每次会话协商的临时密钥,证书中的公钥则是永久的(long-term)。


  • RSA:证书公钥加密算法,用于对证书数据部分的散列值进行签密、对  ECDHE 交换参数(的 HASH 值)进行签密。可能替换值为 ECDSA(椭圆曲线数字签名算法)。


2、AES_128_GCM:传输会话(对称)加解密使用 GCM 模式的 AES-128 算法。


“主流加密算法趋势是 AES(128/256),加密模式的趋势是 GCM。

    GCM 是一种特殊的称为 AEAD 的加密模式,不需要配合 MAC。


  • AES_128:使用128位的会话对称加密算法,双方通过 ECDHE 交换参数协商出对称密钥。


  • GCM:Galois计数器模式(Galois/Counter Mode)。消息认证码(MAC,Message Authentication Code)用于保障消息的完整性,防止各种伪造。AES-CMAC 使用分组密码,取代 HMAC 的加密散列函数。Galois 消息认证码(GMAC)则采用了 AES 算法的一种特殊模式。


3、SHA256:消息认证码算法,基于有密钥的加密散列函数,用于创建消息摘要/指纹。


”使用安全散列算法2(SHA-2)生成256字节的摘要,确保消息的完整性(没有被篡改)。


关于 Cipher Suites 可参考《TLSPARAMS - Cipher Suites》。


客户端基于 Certificate 和 Server Key Exchange 计算对称密钥

客户端首先要校验服务端下发证书(Certificate)的合法性(validates the certificate chain):


1.证书路径信任链逐级校验通过(证书确由可信 CA 认证签发);

2.签名解密成功(确系证书持有者亲笔);

3.从签名解析出的摘要和证书公开内容的摘要一致(证书内容完整,未被篡改);

4.主题 CN 子域(Subject.CN)与 URL 中的 HOST 一致,综上确保访问的网站是来自预期目标服务器且非劫持或钓鱼。


然后,客户端在接收到 Server Key Exchange 报文后,首先需要使用证书中的公钥对签名进行 RSA 解密并校验散列值。如果解密校验通过,则基于 ECDH[^ECDH] 参数中的 Pubkey(the server’s ephemeral ECDH public key) 通过一定的算法计算出 Pre-Master Secret(resultant shared secret)。


紧接着,客户端将基于 Client Hello、Server Hello 中的 2 个 28 bytes 随机数(Random)和这个 Pre-Master Secret 计算出用于派生后续传输所用对称密钥的种子—— Master Secret(Shared Secret)。


“两个 Hello 随机数都是明文透传。

   ECDH 参数(EC Diffie-Hellman Server Params)携带了  Signatue,需要 Certificate 中的公钥进行 RSA 解密和 HASH 校验,从而保证整个握手协商的安全性。


Master Secret 作为数据加解密相关的 secret 的 Key Material 的一部分。

Key Material 的计算跟 Master Secret(Key) 的计算类似,只不过计算的次数要多。

Key Material需要计算12次,从而产生12个hash值。产生12个hash之后,紧接着就可以从这个 Key Material 中获取 Session Secret 了。


  • Client/Server write MAC key:用来对数据完整性进行验证;

  • Client/Server write encryption key:用来对数据进行加解密的 Session Secret(Session Key)。


在收到 Server Hello Done 且客户端已成功协商计算出 Session Secret 之后,客户端向服务器发送 Client Key Exchange、Change Cipher Spec 和 Encryted Handshake Message 报文 。


1.发送 ChangeCipherSpec,表示客户端确认接受 Server Hello 中服务器选定的 Cipher Suite。

2.发送 Client Key Exchange,这样服务器也能基于 Server Hello 指定的 Cipher Suite 和 Client Hello、Server Hello 中的 2 个 28 bytes 随机数以及 Client Key Exchange 中的 ECDH 参数最终协商出 Session Secret。

3.发送 Encryted Handshake Message,表示客户端基于计算出的会话密钥加密一段数据(verify_data,Finished message),在正式传输应用数据之前对握手协商的会话加解密通道进行验证。


”服务器只有确保收到了 Change Cipher Spec、Client Key Exchange 报文并成功协商出了 Session Secret,才能解密(验证)加密的 Finished message。


服务端基于 Client Key Exchange 计算对称密钥

服务器在收到客户端的 ChangeCipherSpec 报文后,也回应一个 ChangeCipherSpec  告知客户端确定使用双方都支持确认的 Cipher Suite。


服务端在接收到 Client Key Exchange 报文后,基于 ECDH 参数中的 Pubkey 通过一定的算法计算出 Pre-Master Secret(resultant shared secret)。


然后,服务端再基于 Client Hello、Server Hello 中的 2 个 28 bytes 随机数(Random)和这个 Pre-Master Secret 计算出用于派生后续传输所用对称密钥的种子—— Master Secret(Shared Secret)。


ECDH 参数(EC Diffie-Hellman Client Params)使用 Certificate 中的公钥加密,需要使用对应的私钥解密——只有持有证书的服务器才能解开,确保了交换参数的安全性。


Master Secret 作为数据加解密相关的 secret 的 Key Material 的一部分,最终从 Key Material 中获取用于会话加密的对称密钥 Session Secret(Session Key)。


服务端在接收到客户端发过来的 Encryted Handshake Message 后,若使用 Session Secret 能解密出原始校验数据(verify_data,Finished message),则表明 C->S 方向的加解密通道就绪。

同时,服务器也会给客户端发送一份使用 Session Secret 加密的校验数据报文 Encryted Handshake Message。若客户端也能正确解密,则表明 S->C 方向的加解密通道就绪。


至此,基于非对称加解密(私钥签名公钥解密,公钥加密私钥解密)和 ECDHE 协商出来的对称会话密钥,已被 C=S 双向通道验证,TLS HandShake 成功。


HTTP over TLS(HTTPs)

接下来,双方可以使用协商计算出的 Session Secret 和 ALPN Protocol 来进行应用数据(Application Data)的加密传输。


具体来说,双方以 Session Secret 为对称密钥,使用 AES 对称加密算法对 HTTP  Request/Response 报文进行加密传输。


所谓 HTTPs 全称为 Hyper Text Transfer Protocol over Secure Socket Layer,意即 over TLS 的 Secure HTTP。



图片1.png


参考

SSL/TLS协议运行机制的概述

图解SSL/TLS协议  


How HTTPS Secures Connections / HTTPS是如何保证连接安全

The First Few Milliseconds of an HTTPS Connection  


HTTPS 工作原理和 TCP 握手机制

也许,这样理解HTTPS更容易

一个故事讲完https  


百度全站 HTTPS 实践

TLS 协议分析 by 微信后台团队







也许您对下面的内容还感兴趣:

留言0

评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。