这是我参与8月更文挑战的第3天，活动详情查看：8月更文挑战

8月份更文挑战主题：TLS1.3协议
TLS1.3系列文章（3）：TLS1.3握手之服务端参数阶段

tls1.3的握手流程可以分成下面的三个阶段，下面按照这个三个阶段介绍包括的握手消息。

密钥交换阶段(Key Exchange)： 协商加密算法以及共享密钥信息，此阶段完成后，所有消息都需要加密。

服务端参数阶段(Server Parameters): 协商其他握手阶段参数。

认证阶段(Authentication)：协商双方认证、密钥确认以及握手报文校验。

2.2 服务端参数阶段

服务端参数阶段主要包括：加密的扩展载荷(EncryptedExtensions)和证书请求载荷(CertificateRequest)。

2.2.1 EncryptedExtensions载荷

在TLS1.3所有的握手场景中，服务端必须在ServerHello后立即发送EncryptedExtensions载荷；它是经过server_handshake_traffic_secret衍生密钥加密的第一个报文。EncryptedExtensions消息包含可以一些被保护的扩展，例如任何不需要加密上下文以及证书无关的扩展。 客户端必须检查EncryptedExtensions是否存在任何被禁止的扩展，如果发现任何扩展，必须以 "illegal_parameter "告警中止握手。

EncryptedExtensions消息格式如下：

通过Wireshark抓包发现，加密扩展载荷内容是：ALPN(应用层协议协商) 。详情见下图：

2.2.2 CertificateRequest

对于使用证书进行身份验证的服务器，可以选择性的向客户端发送证书请求载荷来获取客户端证书(双向认证时，一般情况下不对客户端进行认证)。如果发送了证书请求消息，则它必须在EncryptedExtensions之后。

此消息的结构如下：

certificate_request_context：一个加密的字符串，用于表示证书请求，并在客户端的证书消息中被携带回来。 certificate_request_context在此连接的整个生命周期内必须是唯一的（从而防止客户端CertificateVerify消息的重放）。该字段应为零长度，除非用于RFC8446的4.6.2节中描述的post-handshake身份验证交互。当请求post-handshake认证时，服务器应该使上下文对客户端不可预测（比如随机生成），从而防止临时访问客户端私钥的攻击者预先计算出有效的CertificateVerify消息。

Extensions：描述正在请求的证书参数的扩展集。必须指定“signature_algorithms”扩展名，如果此消息定义了其他扩展也可以选择性包含。客户端必须忽略不认识的扩展。

在TLS的先前版本中，CertificateRequest消息携带服务器接受的签名算法和证书授权列表。在TLS 1.3中，前者通过发送“signature_algorithms”和可选的"signature_algorithms_cert"扩展来表示。后者通过发送“certificate_authorities”扩展来表示。

使用PSK认证的服务器不得在主握手中发送CertificateRequest消息。