计网--HTTPS+ECDHE

解密

校验证书合法；客户端会⽣成⼀个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前⾯给的信息，⽣成客户端的椭圆曲线公 钥，然后⽤「Client Key Exchange」消息发给服务端。

服务端公钥

TCP ACK

加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供服务端校验。

ACK

服务器使用的证书server certificate

随机数s

「Server Key Exchange」

公钥加密传递到服务端

为什么多级：确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有 问题。

⼀个记录（record）是 TLS 收发数据的基本单 位，类似于 TCP ⾥的 segment。多个记录可以组合成⼀个 TCP 包发送，所以通常经过「四个消息」就可以完成 TLS 握⼿

随机数c

⾄此，双⽅都有对⽅的椭圆曲线公钥、⾃⼰的椭圆曲线私钥、椭圆曲线基点 G。于是，双⽅都就计算出点（x， y），其中 x 坐标值双⽅都是⼀样的，前⾯说 ECDHE 算法时候，说 x 是会话密钥，但实际应⽤中，x 还不是最终 的会话密钥。最终的会话密钥，就是⽤「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料⽣成的。

SYN

服务器证书hash得到摘要，使用CA私钥签名

整个 SSL/TLS 的握⼿阶段开始

⽤双⽅协 商的加密算法，各⾃⽣成本次通信的「会话秘钥」= 「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」

私钥

随机数作为私钥

会话对称秘钥

2 发现中间证书上级是根CA颁发的，请求根证书

使⽤了 ECDHE，在 TLS 第四次握⼿前，客户端就已经发送了加密的 HTTP 数据，⽽ 对于 RSA 握⼿过程，必须要完成 TLS 四次握⼿，才能传输应⽤数据。ECDHE 相⽐ RSA 握⼿过程省去了⼀个消息往返的时间

SYN+ACK

3使用自己的本地公钥验证通过，信任root证书

root CA根证书

TLS四次握手图示每一种颜色是合并在一起发送的

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」密钥协商算法使⽤ ECDHE； 签名算法使⽤ RSA； 握⼿后的通信使⽤ AES 对称算法，密钥⻓度 256 位，分组模式是 GCM； 摘要算法使⽤ SHA384；

没有传输对称秘钥

4 中间是受信任的

⽬前客户端和服务端通过明⽂共享了这⼏个信息：Client Random、Server Random 、使⽤的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥，

加密

客户端公钥

中间证书

1RTT

1根据颁发的CA请求CA中间证书

收到的服务器证书

server hello随机数s，确认TLS版本号，使用的密码套件（RSA）

Server hello down服务器hello完成

信任OS或者浏览器

⽤双⽅协 商的加密算法，各⾃⽣成本次通信的「会话秘钥」= 「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」

服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘 要，⽤来供客户端校验。

选择了名为 named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客 户端； ⽣成随机数作为服务端椭圆曲线的私钥，保留到本地； 根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。为了保证这个椭圆曲线的公钥不被第三⽅篡改，服务端会⽤ RSA 签名算法给服务端的椭圆曲线公钥做个签名。

对⽅的椭圆曲线公钥、⾃⼰的椭圆曲线私钥、椭圆曲线基点 G。于是，双⽅都就计算出点（x， y），其中 x 坐标值双⽅都是⼀样的

CA证书认证机构

证书信任链：收到的时候本地只有根证书公钥

整个 SSL/TLS 的握⼿阶段全部结束

验证证书hash结果和公钥解密的结果是否一致，一致才可信，说明没(篡改)，比对请求服务器(冒充）

数字证书公钥； 持有者信息； 证书认证机构（CA）的信息； CA 对这份⽂件的数字签名及使⽤的算法； 证书有效期； 还有⼀些其他额外信息；