老赵揉搓苏清雅双乳的视频_老头老太性行交视频_老同学3免费集_老师没戴套子C了我一天视频_老师的丰满大乳奶_老师把我添高潮了A片潘金莲

為了解決安全問題、提升性能，IETF于2018年發布了TLS協議的1.3版本，目前已在大量場景中應用。下面，將從商用密碼應用安全性評估的視角對TLS1.3協議展開分析。 

一、TLS1.3協議棧
TLS1.3協議和早期版本一樣，主要由握手協議和記錄層協議組成，工作于應用層和傳輸層之間，框架見下圖：

其中，記錄層協議結構如下：

根據上述內容可知，握手協議、密碼規格變更協議、報警協議和應用數據協議在記錄層協議之上，通過不同的值來表示。例如，應用數據協議值為23，見下圖：

Legacy record version用于兼容早期TLS版本。需要注意的是，為了實現最大向后兼容，初始Client Hello中的Legacy record version應為TLS1.0（0x0301），其他的消息中的Legacy record version應為TLS1.2（0x0303）。此字段僅起到兼容作用，不代表TLS實際協商后的版本。TLS版本與版本號對應關系見第三章。

二、TLS1.3握手過程
TLS1.2版本在2008年推出，到TLS1.3誕生已使用了十年之久，因此很多應用軟件僅支持早期協議格式。為了盡快普及，TLS1.3的格式與早期版本保持一致，通過擴展來達到提升性能和安全性并向后兼容的目的。下圖是TLS1.3協議的完整握手過程：

其中，+號代表重要擴展消息，*號代表可選或依賴上下文關系的消息，{}號代表被加密的握手消息，[]號代表不屬于握手協議的被加密的應用數據消息。
在密鑰交換階段，客戶端發送Client Hello消息給服務端，其中包含客戶端隨機數、supported_groups（客戶端支持的密鑰交換參數）、key_share（密鑰交換參數和對應的客戶端公鑰）。

服務端返回Server Hello消息給客戶端，其中包含服務端隨機數、key_share（協商后的密鑰交換參數和對應的服務端公鑰）。

為了保證前向安全性，TLS1.3去掉了靜態RSA和DH等密鑰交換算法，目前僅支持ECDHE和DHE兩種。因此，客戶端和服務端可以在Server Hello消息之后就分別計算出預主密鑰，再通過HKDF（HMAC-based Extract-and-Expand Key Derivation Function）生成主密鑰，進而生成工作密鑰用于保護后續消息。因此Change Cipher Spec消息之后的所有內容均為密文。

如上所述，TLS1.3握手過程與早期版本最大的不同是通過擴展將密鑰交換參數發送提前，減少握手消息往返，使完整握手時間降低為1-RTT（Round-Trip Time）。在session 重用的場景，則將早期版本的session ID和session ticket更換為預共享密鑰PSK（pre-shared key），從而Client Hello消息即可包含使用PSK加密的應用數據，使握手時間降低為0-RTT。不過0-RTT不具備前向安全性，可能導致重放攻擊。

三、TLS1.3版本號
IETF將SSL標準化后，第一個TLS版本為1.0，版本號為0x0301，后續版本依次遞增，TLS1.3版本號為0x0304，TLS幾個版本與版本號的對應關系見下表。

前文提到TLS1.3采用擴展來實現新功能。為了實現與早期版本的兼容，TLS1.3在Client Hello和Server Hello里通過supported_versions擴展來協商TLS的版本。

 從Client Hello的結構體可以看出，legacy version默認為TLS1.2（0x0303），當supported version與legacy version不一致時，以supported version協商后的版本為準。如下圖：

四、TLS1.3支持的密碼算法套件
TLS1.3協議的密碼算法套件做了很大調整，僅保留AEAD算法（Authenticated Encryption with Associated Data）和2個SHA-2算法，如下表：

其中，AEAD算法用于實現通信數據完整性和通信過程中重要數據機密性，雜湊算法用于計算HKDF（HMAC-based Extract-and-Expand Key Derivation Function）。另外，TLS1.3強制要求支持TLS_AES_128_GCM_SHA256算法套件，從密碼算法套件也可以間接確定通信信道TLS協議的版本。
當客戶端既支持TLS1.2版本又支持TLS1.3版本時，Client Hello中將包含兩種版本分別支持的密碼算法套件，服務端從中選擇自己也支持的密碼算法套件，因此最終協商確定的密碼算法套件可以從Server Hello中獲取，如下圖：

五、TLS1.3密鑰交換
TLS1.3協議的密碼算法套件中不再包含密鑰交換算法。前文提到TLS1.3僅支持ECDHE和DHE兩種密鑰交換算法，加上新增的PSK，組合成三種密鑰交換模式：
●（EC）DHE
● PSK-only
● PSK with (EC)DHE
第一種是完整握手時使用的模式，另外兩種需要復用或者外部導入PSK。
我們先來看下第一種密鑰交換模式。根據TLS1.3握手過程可知，supported_groups擴展代表密鑰交換參數，支持DH參數和ECDH參數，優先級從高到低。其中，僅支持secp256r1、secp384r1、secp521r1、 X25519 和 X448五條橢圓曲線用于ECDHE密鑰交換。由于DH已逐漸退出歷史舞臺，此處不做分析。
如果需要采用PSK密鑰交換模式，Client Hello中需要包含psk_key_exchange_modes擴展，包括psk_ke（PSK-only）和psk_dhe_ke（PSK with (EC)DHE）兩種，同時需要包含pre_shared_key擴展，給出具體的PSK，PSK可為多條。服務端從客戶端提供的PSK列表中進行選擇，并通過Server Hello返回pre_shared_key擴展，確定后續使用的PSK。需要注意的是，當需要在Client Hello中就發送應用數據時，應包含early_data擴展并默認選擇PSK第一條進行保護。

六、TLS1.3簽名算法
TLS1.3協議的密碼算法套件中同樣也不再包含簽名算法。通過Client Hello的擴展來進行確認，其中signature_algorithms_cert擴展表示證書中使用的簽名算法，即CA簽發證書時的簽名算法。signature_algorithms擴展表示CertificateVerify消息使用的簽名算法，即身份鑒別算法。當未包含signature_algorithms_cert擴展時，證書中使用的簽名算法應與signature_algorithms擴展一致。需要注意的是，簽名算法是將任意長度的消息作為輸入，而不是將摘要值作為輸入。
TLS1.3支持以下簽名算法：

其中，RSASSA-PKCS1-v1_5 algorithms和Legacy algorithms僅用于證書簽發。下圖為簽名算法示例：

為了便于分析最終協商確定的簽名算法，我們先對通信數據包進行解密，從Certificate Verify消息中即可分析出身份鑒別算法。

其他測評按照常規流程操作即可。