在 TLS 1.3 中,為 Resumption Master Secret 與 Application Traffic Secrets 使用不同的握手記錄的原因是什麼?
TLS 1.3 RFC 第 7.1 節將此列為密鑰計劃的最後一部分:
https://datatracker.ietf.org/doc/html/rfc8446#section-7.1
... 0 -> HKDF-Extract = Master Secret | +-----> Derive-Secret(., "c ap traffic", | ClientHello...server Finished) | = client_application_traffic_secret_0 | +-----> Derive-Secret(., "s ap traffic", | ClientHello...server Finished) | = server_application_traffic_secret_0 | +-----> Derive-Secret(., "exp master", | ClientHello...server Finished) | = exporter_master_secret | +-----> Derive-Secret(., "res master", ClientHello...client Finished) = resumption_master_secret
前三個計算採用
Master Secret
, 將它們與 labelS"c ap traffic"
//"s ap traffic"
("exp master"
分別)和Client Hello到Server Finished*的握手腳本雜湊結合起來。*每一個的結果都是三個鍵:client_application_traffic_secret_0
,server_application_traffic_secret_0
,exporter_master_secret
。最後一個計算
Master Secret
將它與標籤結合起來"res master"
,以及客戶端 Hello到Client Finished*的握手腳本散列。*這樣做的結果是resumption_master_secret
。我的問題:
在計算 Resumption Master Secret 時,使用 Client Hello through Client Finished 而不是 Client Hello through Server Finished 背後的原因是什麼?
實際上這是一個有趣的問題,我不能肯定地告訴你 100%,但我對此的想法是:一旦伺服器發送了“完成”消息,它就已經可以開始發送應用程序數據了(即使客戶端沒有已發送完成消息)。因此,server_application_traffic_secret 涉及 ClientHello….ServerFinished 是有道理的。
關於resumption_master_secret,我認為由於它用於恢復會話,因此涉及ClientHello…ClientFinished 的重點是讓整個握手都參與到這個秘密中。更重要的是,如果伺服器要求對客戶端進行證書身份驗證,那麼這也將是握手記錄的一部分。
據我所知,規範並不能證明所有的設計決策都是合理的,但我個人認為這是有道理的,因為(正如您在下面的握手協議中所見),ClientHello…ClientFinished 涉及整個握手。
Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data]