Puncte:2

În TLS, clientul cunoaște cheia publică a serverului înainte de a începe schimbul de date?

drapel cn

Citesc despre atacul de blocaj. Am fost întrebat dacă atacul poate fi prevenit prin verificarea integrității Server Salut mesaj.

Răspunsul meu ar fi nu, deoarece omul din mijloc încă nu poate trimite originalul Server Salut mesaj și trimite-l pe al său.

Din cercetările mele, se pare că clientul ajunge doar la cheia publică a serverului în timpul Server Salut mesaj care include cheia publică a serverului.

Dacă este așa, răspunsul meu ar trebui să fie corect.

Există o modalitate prin care clientul să cunoască cheia publică a serverului înainte de Server Salut mesaj?

dave_thompson_085 avatar
drapel cn
Ce cheie publică de server? Cel folosit pentru autentificare sau cel folosit pentru schimbul de chei care este întotdeauna diferit în 1.3 și adesea, dar nu întotdeauna diferit în protocoalele anterioare? _Numai_ cheia efemeră kx din 1.3 este în ServerHello și nu poate fi folosită pentru a verifica integritatea nimicului. Dar Logjam nu s-ar aplica la 1.3, deoarece nu mai permite grupuri FFDH prea mici sau nevalidate și potențial defecte pentru kx.
Jack avatar
drapel cn
@dave_thompson_085 așa cum se vede aici: https://cryptologie.net/upload/logjam.png mesajul ServerHello trimite certS, semn(skS,[p512, g, g^b]). Încerc să aflu dacă în acest moment clientul poate verifica identitatea serverului poate fi prevenit atacul de blocaj?
dave_thompson_085 avatar
drapel cn
Acea diagramă arată doar elementele de date specifice relevante pentru atac, nu aproape de tot protocolul și cu siguranță nu mesajele care le conțin. Vezi RFC 2246 și următoarele. Deși, așa cum spune Maarten, elementul critic de _verificare_ este pachetul de criptare aleasă și _care_ este într-adevăr în ServerHello.
Puncte:1
drapel in

Atacul, pe care îl numim Logjam, este reprezentat în Figura 2 și se bazează pe un defect în modul în care TLS compune DHE și DHE_EXPORT. Când un server selectează DHE_EXPORT Pentru o strângere de mână, se procedează prin emiterea unui semnat ServerKeyExchange mesaj care conține un mesaj pe 512 biți $p_{512}$, dar structura acestuia mesajul este identic cu mesajul trimis în timpul DHE standard ciphersuites. În mod critic, porțiunea semnată a serverului mesajul nu reușește să includă nicio indicație a suitei de cifrare specifice pe care serverul l-a ales. Cu condiția ca un client să ofere DHE, un atacator activ poate rescrie clienții ClientSalut la oferi o corespondență DHE_EXPORT ciphersuite acceptat de server și eliminați alte suite de criptare care ar putea fi alese in schimb. Atacatorul rescrie ServerSalut raspuns catre înlocuiți cel ales DHE_EXPORT ciphersuite cu o potrivire non-export ciphersuite și redirecționează ServerKeyExchange mesaj către client așa cum este. Clientul va interpreta tuplu cu grad de export $(p_{512}, g, g^b)$ ca parametri DHE validi aleși de server și continuați cu strângerea de mână. The clientul și serverul au transcrieri diferite de strângere de mână stadiu, ci un atacator care poate calcula $b$ aproape de real timpul poate obține apoi secretul principal și cheile de conexiune pentru a finaliza strângerea de mână cu clientul și apoi liber citiți și scrieți datele aplicației pretinzând a fi serverul.

Și întrebarea ta sună:

Citesc despre atacul de blocaj. Am fost întrebat dacă atacul poate fi prevenit prin verificarea integrității mesajului Server Hello.

Și bănuiesc că răspunsul este da, dar numai dacă ar semna/verifica setul de suite de criptare care este oferit în cadrul ServerSalut, și se pare că cel puțin TLS până la 1.2 nu reușește să facă acest lucru. Cu alte cuvinte, ar trebui să modificați protocolul TLS pentru a include suitele de criptare oferite în generarea/verificarea semnăturii, făcându-l incompatibil cu orice alt software TLS.

Deci, în prezent, se pare că pur și simplu nu vă permiteți implementare a executa DHE_EXPORT (sau DH efemer pe 1024 de biți) este calea de urmat pentru TLS până la 1.2.

Jack avatar
drapel cn
Bună, îmi pare rău, dar de ce ai spus că este un da? De asemenea, întrebarea ar fi doar la etapa ServerHello (verificarea identității acolo)
Maarten Bodewes avatar
drapel in
Am vrut să spun că **teoretic** poți semna și suita de criptare în `ServerHello`, dar asta ar însemna schimbarea protocolului general. Dacă doar **folosești** protocolul, atunci este un **nu** puternic.
dave_thompson_085 avatar
drapel cn
Din punct de vedere tehnic, standardele pentru 1.1 și 1.2 (RFC 4346 și 5246) interzic deja toate suitele de export (DHE, staticDH, DHanon, plainRSA și (!) Kerberos, vă amintiți asta?), așa că aceasta _ar trebui_ să fie o problemă numai până la 1.0, dar în exersează, ei bine,...

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.