握手简述（以RSA为例）：
- client hello:客户端给出TLS协议版本号，支持的加密算法、随机数Client random、扩展字段
- server hello:服务端确认双方可支持的加密算法，并把数字证书下发给客户端。同时也会生成一个随机数Server random
- 客户端验证证书的有效性，并重新生成一个随机数Pre-main secret，使用证书中的公钥加密随机数，发送给服务端
- 服务端使用私钥获取随机数
- 客户端与服务端根据约定的加密算法，使用前面的三个随机数，生成对话密钥Session key，用来加密后续会话。
1.会话密钥（Session key）
这是握手的最终结果。它是对称密码的密钥，并允许客户端和服务器相互加密消息。
2.客户端随机（Client random）
这是由客户端创建的32个字节的序列。它对于每个连接都是唯一的，并且应该包含四个字节的时间戳，后跟28个随机字节。最近，谷歌浏览器切换为使用32个字节的随机数，以防止客户端指纹。这些随机值通常称为随机数（nonce）。
3.服务器随机数(Server random)
服务器随机数与客户端随机数相同，只是服务器生成的随机数相同。
4.Pre-main密钥(Pre-main secret)
这是一个48字节的数据块。它可以与客户端随机变量和服务器随机变量结合使用，以使用“伪随机函数”（PRF）创建会话密钥(Session key）。
5.密码套件（Cipher suite）
CipherSpecs 用于认证加密算法和信息摘要算法的组合，通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合，该组合包含三种不同的算法：
- 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
- 加密算法 (用于握手完成后的对称加密，常用的有 AES、3DES等)
- 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)
CipherSuites是用于组合构成TLS连接的算法的唯一标识符。它为以下列出的每个功能定义一种算法：
- 密钥建立（通常是Diffie-Hellman变体或RSA）
- 认证（证书类型）
- 机密性（对称密码）
- 完整性（哈希函数）
例如，密码套件是“ ECDHE-ECDSA-AES256-GCM-SHA384”，它定义了一个使用以下内容的会话：
- Elliptic Curve Diffie-Hellman Ephemeral（ECDHE）密钥交换以建立密钥
- Elliptic Curve Digital Signature Algorithms（ECDSA）进行身份验证
- 256-bit Advanced Encryption Standard in Galois/Counter mode (GCM) 用于确保机密性
- 384位的SHA(安全哈希算法)确保完整性
消息1：Client Hello
client hello包含客户端要使用的协议版本，以及一些开始握手的其他信息，包括客户端随机数（client random）和密码套件（cipher suites）列表。现行浏览器还包括他们要查找的主机名，称为服务器名称指示（SNI）。SNI使Web服务器可以在同一IP地址上托管多个域。
消息2：Server Hello
收到client hello后，服务器将选择进行握手的参数。密码套件的选择确定执行哪种类型的握手。服务器“ hello”消息包含服务器随机数，服务器选择的密码套件以及服务器的证书。证书包含服务器的公钥和域名。
消息3：Client Key Exchange
在验证证书是受信任的并且属于他们尝试访问的站点之后，客户端将创建一个随机的pre-main secret。此密钥使用证书中的公钥加密，然后发送到服务器。
收到此消息后，服务器将使用其私钥来解密此密钥。既然双方都有pre-main secret，并且客户端和服务器都具有随机性，那么他们都可以导出相同的会话密钥。然后，他们交换一条短消息以指示他们发送的下一条消息将被加密。
当客户端和服务器交换“完成”消息时，握手正式完成。正式的文本描述是：使用session key加密“client finished” or “server finished” 。双方之间的任何后续通信都使用session key加密。
这种握手优点是，在一个步骤中将密钥交换和身份验证结合在一起。理论上如果服务器可以正确导出会话密钥，则它们必须有权访问私钥，因此必须是证书的所有者。
这种握手的缺点是，它所保护的消息仅与私钥一样安全。假设第三方已记录了握手和随后的通信。如果该方将来可以访问私钥，则他们将能够解密主密码并导出会话密钥。这样他们就可以解密整个消息。即使证书已过期或吊销，也是如此。这将导致我们采用另一种形式的握手，即使私钥遭到破坏，该握手也可以提供机密性。
Ephemeral Diffie-Hellman 握手
它使用两种不同的机制：一种用于建立shared pre-main secret，另一种用于认证服务器。这依赖的关键功能是Diffie-Hellman密钥协商算法。
算法工作原理类似如下：
- a有密钥a，将g^a发送给b
- b有密钥b，将g^b发送给a
- a计算(gb)a
- b计算(ga)b
- a和b都以gab结尾，这是他们的共同密钥
消息1：Client Hello
就像在RSA中一样，client hello包含协议版本，客户端随机值，密码套件列表以及SNI扩展（可选）。
消息2：Server Hello
收到client hello后，服务器将选择进行握手的参数，包括ECDHE的曲线。服务器“ hello”消息包含服务器随机数，服务器选择的密码套件以及服务器的证书。
RSA和Diffie-Hellman握手在这一点上因新的消息类型而开始不同。
消息3：Server Key Exchange
为了启动Diffie-Hellman密钥交换，服务器需要选择一些启动参数并将其发送给客户端-这与我们上面描述的g^a相对应。服务器还需要一种方法来证明它具有对私钥的控制权，因此服务器会计算到目前为止所有消息的数字签名。Diffie-Hellman参数和签名都在此消息中发送。
消息4：Client Key Exchange
在验证证书是受信任的并且属于他们尝试访问的站点之后，客户端将验证从服务器发送的数字签名。他们还向客户端发送Diffie-Hellman握手的一半（对应于上面的g^b）。
此时，双方都可以根据Diffie-Hellman参数（对应于上面的gab）计算出pre-main secret。使用pre-main secret以及客户端和服务器的随机密钥，它们可以派生相同的会话密钥。然后，他们交换一条短消息以指示他们发送的下一条消息将被加密。
就像在RSA握手中一样，当客户端和服务器交换“Finished”消息时，此握手已正式完成。双方之间的任何后续通信都使用会话密钥加密。
Tips:与RSA相比采用DH算法后，Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。
Abbreviated handshakeTLS提供了一项好的机制，称为“会话恢复（session resumption）”。如果客户端先前已经与服务器建立了会话，并尝试再次连接，则可以使用Abbreviated handshake。有两种机制可以实现：会话ID和会话票证（session IDs and session tickets）。
会话ID要求服务器保持会话状态（即会话密钥）就绪，以防需要恢复先前的会话。对于会话票证，服务器在初始握手期间将会话票证（由用票证密钥加密的会话密钥组成）发送给客户端。在恢复会话时，客户端将加密的密钥发送回服务器，由服务器解密并恢复会话。无需使用私钥来恢复会话。
Firefox和Chrome是支持会话票证的主要浏览器。所有其他现行浏览器都通过会话ID支持恢复。大规模使用这些技术时面临的挑战之一是负载平衡。为了使服务器恢复连接，它需要具有先前建立的会话密钥。如果访问者尝试恢复与新服务器的连接，则该服务器需要以某种方式获取原始会话密钥（original session key ）。
会话恢复的主要问题在于，这并不意味着可以扩展到负载平衡的服务器。如果客户端在一个服务器上启动会话，则无法在另一台服务器上恢复该会话。这不是协议的失败，只是开源Web服务器中缺少的功能。
通过Keyless SSL，我们引入了高级会话恢复功能来解决此问题。这包括通过会话票证在全球范围内恢复会话，以及通过会话ID在数据中心内恢复会话。会话恢复使重复访问者的连接时间很快，因为无需返回到密钥服务器即可恢复连接。
补充知识SNI：
在TLS握手阶段，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。SNI使Web服务器可以在同一IP地址上托管多个域。
Keyless服务
放到CDN上的网站，可以不用提供自己的私钥，也能使用SSL加密链接。
如何做到：将密钥放到密钥服务器上
数字证书（digital certificate)
在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。
证书验证过程- 服务端生成公钥和私钥
- 服务端发送公钥给CA
- CA生成证书给服务端
- 服务端再客户端请求时发送证书给客户端
- 客户端接收到证书之后发送给CA验证证书有效性
- 确认证书有效之后，才可以进行后续https通信
- 检查数字签名
- 验证证书链
- 验证证书有效期
- 验证证书撤回状态
- 证书中有什么
- 证书所有者的公钥
- 证书所有者的专有名称
- 证书颁发机构的专有名称
- 证书的有效起始日期
- 证书的过期日期
- 证书数据格式的版本号
- 序列号，这是证书颁发机构为该证书分配的唯一标识符
流量解密
工具：wireshark
法一:使用私钥解密
条件：拥有私钥证书
缺点：无法解密 ECDHE 进行密钥交换的加密流量。
步骤
配置wireshark
编辑–>首选项–>protocols–>TLS
按照下图中填写IP地址、端口、协议、以及私钥文件。
保存配置，重新打开wireshark捕获流量，然后访问私钥对应的网站就可以解密流量了。
法二:SSLKEYLOGFILE
此方法对使用ECDHE 密钥交换方式的流量也可以，不需要私钥
步骤
添加环境变量：SSLKEYLOGFILE
Firefox 和 Chrome 会将每个 HTTPS 连接产生的 Premaster Secret 或 Master Secret 存储在环境变量SSLKEYLOGFILE对应的文件路径中。
Wireshark配置：
TLS debug file : 解密过程中的日志会记录到这里，可选配置
(Pre)-Master-Secret log filename 选项中选择环境变量SSLKEYLOGFILE配置的文件路径。
配置完成后，再访问 HTTPS 网站，sslkeylog.log 文件中将会有浏览器写入的数据。
确认之后就可以重新打开Wireshark进行抓包，可以看到解密流量了
参考资料
SSL/TLS协议运行机制的概述
三种解密 HTTPS 流量的方法介绍
————————————————
版权声明：本文为CSDN博主「BlackFee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013315560/article/details/108286278