Puncte:1

În TLS 1.3, care este rațiunea pentru utilizarea diferitelor transcriere de strângere de mână pentru Secretul principal de reluare vs Secretele de trafic de aplicație?

drapel in

TLS 1.3 RFC, secțiunea 7.1 listează aceasta ca ultima parte a programului cheie:

https://datatracker.ietf.org/doc/html/rfc8446#section-7.1

            ...
   0 -> HKDF-Extract = Master Secret
             |
             +-----> Derive-Secret(., "c ap trafic",
             | ClientHello...server terminat)
             | = client_application_traffic_secret_0
             |
             +-----> Derive-Secret(., "s ap traffic",
             | ClientHello...server terminat)
             | = server_application_traffic_secret_0
             |
             +-----> Derive-Secret(., "exp master",
             | ClientHello...server terminat)
             | = exporter_master_secret
             |
             +-----> Derive-Secret(., "res master",
                                   ClientSalut...client Terminat)
                                   = reluare_master_secret

Primele trei calcule iau Maestrul Secret, le combină cu etichetele "trafic c ap" / "s ap trafic" / "exp master" (respectiv) și a transcrierea strângerii de mână hash al Client Buna ziua prin Server terminat. Rezultatul fiecăreia dintre acestea sunt trei chei: client_application_traffic_secret_0, server_application_traffic_secret_0, exporter_master_secret.

Ultimul calcul ia Maestrul Secret, îl combină cu eticheta "res master", și a transcrierea strângerii de mână hash al Client Buna ziua prin Client terminat. Rezultatul acestui lucru este reluare_master_secret.

Intrebarea mea:

Care este raționalitatea din spatele utilizării Client Hello prin Client Finished în loc de Client Hello prin Server Finished atunci când se calculează Secretul principal de reluare?

Puncte:1
drapel gb

De fapt, aceasta este o întrebare interesantă și nu vă pot spune 100% cu siguranță, dar părerile mele despre aceasta sunt: ​​Odată ce Serverul și-a trimis mesajul „Terminat”, poate începe deja să trimită Date aplicației (chiar dacă Clientul nu a a trimis încă mesajul Terminat). Astfel, are sens ca server_application_traffic_secret să implice ClientHello....ServerFinished.

În ceea ce privește resumption_master_secret, aș susține că, deoarece este folosit pentru reluarea unei sesiuni, scopul implicării ClientHello...ClientFinished este de a avea întreaga strângere de mână implicată în acest secret. Mai mult decât atât, dacă serverul solicită autentificarea prin certificat a clientului, atunci aceasta ar face parte și din transcrierea strângerii de mână.

Din câte știu, specificația nu justifică toate deciziile de proiectare, dar personal cred că acest lucru are sens, deoarece (după cum puteți vedea în protocolul de strângere de mână de mai jos), a avea ClientHello...ClientFinished implică întreaga strângere de mână.

       Client server

Cheie ^ ClientSalut
Exch | + key_share*
     | + algoritmi_semnătură*
     | + psk_key_exchange_modes*
     v + pre_shared_key* -------->
                                                  ServerHello ^ Cheie
                                                 + key_share* | Exch
                                            + pre_shared_key* v
                                        {EncryptedExtensions} ^ Server
                                        {CertificateRequest*} v Params
                                               {Certificat*} ^
                                         {CertificateVerify*} | Auth
                                                   {Terminat} v
                               <-------- [Datele aplicației*]
     ^ {Certificat*}
Auth | {CertificateVerify*}
     v {Terminat} -------->
       [Datele aplicației] <-------> [Datele aplicației]
```
Eddie avatar
drapel in
Multumesc pentru raspuns. Are sens perfect de ce includeți „ambele părți” ale strângerii de mână.Dar cred că principala mea preocupare a fost de ce să nu includ și Server Finished în calculul cheii de reluare? De ce cele trei chei de dinainte au inclus Server Finished, dar cheia de reluare include doar până la Client Finished. De ce să faceți *acea* cheie diferită de cele anterioare?
Eddie avatar
drapel in
Așteaptă... când îți răspund, cred că acum înțeleg mai bine răspunsul tău.Serverul terminat este strângerea de mână completă în momentul în care serverul vrea să înceapă să utilizeze cheile de trafic ale aplicației C/S. Dar în acel moment, serverul nu are rost să aibă o cheie de reluare, așa că se mulțumește să aștepte până la următorul mesaj de la client pentru a-l calcula -- prin urmare, dacă cheia de reluare include „mai multe” informații din strângerea de mână inițială.
Eddie avatar
drapel in
Îți dau bifa. Văzând ce se întâmplă în chei în comparație cu strângerea de mână a arătat clar de ce cheia de reluare are posibilitatea de a include mai multă transcriere de strângere de mână în generarea cheilor decât cheile de trafic ale aplicației. Mulțumesc Reppiz!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.