înregistrare Logare
Puncte:1
avatar Crypto

Mesaj de finalizare a clientului TLS 1.2

drapel pk
Aiin Zul

Lucrez la TLS1.2 pe suita de criptare ECDHE_ECDSA_AES_128_CBC_SHA256. Sunt în prezent în stadiul de mesaj criptat client, unde am primit întotdeauna o eroare pe wireshark de la server care spune că Fatal, Descriere: Handshake Failure. Deci, din ceea ce am făcut cercetările mele, mesajul de finalizare conține pentru acest client presupune să parcurgă acești pași:

  1. 1 octet de tip de strângere de mână: terminare = 0x14
  2. 3 octeți de data_verify_length = 12
  3. 12 octeți de date_verificare
  4. Acești 16 octeți de la pașii 1), 2) și 3) sunt trecuți prin hmac_sha256 și dă și produce 32 de octeți hash. Poate cineva să-mi confirme intrările? 5) Cei 32 de octeți sunt precedați cu 16 octeți de la pașii 1), 2) și 3) și oferă un total de 48 de octeți înainte de completare
  5. Am adăugat o lungime de 1 octet de umplutură și 15 octeți de umplutură de 0x0F și oferă un total de 64 de octeți
  6. Cei 64 de octeți sunt apoi criptați cu client IV și cheie de criptare client
  7. Cei 64 de octeți sunt precedați de 16 octeți de IV înainte de a fi trimisi la server

Ar putea cineva să verifice toți pașii și să mă corecteze dacă greșesc, deoarece am continuat să nu strâng de mână în acest moment.

Multumesc anticipat!

60
0 + 0
aes
Puncte:2
dave_thompson_085 avatar Crypto
drapel cn
dave_thompson_085

După cum se precizează în această întrebare din 2015 plus răspunsul meu pe care se pare că nu l-ați citit nici măcar în timp ce comentați celălalt răspuns, TLS <=1,2 HMAC este calculat pe:

  • cel record secvnum, tip, versiune și lungime: hex 00 00 00 00 00 00 00 00 16 03 03 00 10

  • plus Terminat mesaj pe care îl aveți corect ca tip de 1 octet = 14, lungime de 3 octeți = 00 00 0C și 12 octeți „verify_data”

folosind cheia MAC client (din procesul de derivare a cheii).

Aveți partea ulterioară corectă: criptați CBC corpul înregistrării (care este exact mesajul de strângere de mână) plus HMAC plus padding (de 16 ori 0F) și puneți înainte IV-ul de 16 octeți utilizat (care ar trebui să fie imprevizibil, în mod normal aleatoriu). Și adaugă la acea antetul înregistrării de tip = 16, versiunea = 03 03, lungime = 00 50.

Rețineți că, pe lângă înregistrarea formatată, HMACed și criptată corect, verifica_data în mesajul trebuie să fie corect, iar IME majoritatea oamenilor întâmpină mai multe probleme în a remedia acest lucru decât procesarea înregistrărilor.

Referinţă: RFC5246 6.2.3.1 (și 6.2.3.2 pentru criptarea CBC)

0 + 0
drapel pk
Aiin Zul
Numărul total de octeți de intrare pentru hmac este de 29 de octeți conform postării dvs.: hex 00 00 00 00 00 00 00 00 16 03 03 00 10 + 16 octeți (tip de octet + lungime de 3 octeți + date de verificare de 12 octeți)?
0
Răspunde
drapel pk
Aiin Zul
Mi-am corectat introducerea hmac în funcție de postarea dvs. Dar încă am o problemă de eșec de strângere de mână. Ei bine, să începem de la modul în care am produs verifica_data: 1) hash al tuturor mesajelor anterioare de strângere de mână: SHA256(all_handshake_messages) 2) Apoi am făcut prf(maseter_secret, "client_finished", SHA256(all_handshake_messages)) Acestea produc 12 octeți de verify_data Apoi am concatenat datele de la pasul 3) cu datele de la pasul 1) și 2) în prima mea postare am făcut restul pașilor. Ce ar fi putut cauza eșecul strângerii de mână?
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

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.