Utilizarea parametrilor DH personalizați pentru decriptarea TLS

Există mai multe moduri de a decripta TLS, de ex. într-un mediu de întreprindere. Nu am văzut folosirea parametrilor DH „backdoored” menționați undeva, deși, după înțelegerea mea, ar trebui să funcționeze în principiu: Cum permite un modul non-prime pentru Diffie-Hellman o ușă din spate?

Ar fi posibil ca un procesor desktop recent să decripteze traficul în (aproape) în timp real? Depinde de criptare sau versiunea TLS? Există avantaje/dezavantaje pentru utilizarea acestei opțiuni? Bănuiesc că furtul parametrilor personalizați este similar cu furtul privatului și pierdeți PFS?

Ar fi posibil ca un procesor desktop recent să decripteze traficul în (aproape) în timp real?

Dacă întrebați în mod special despre grupurile DH backdoored, ei bine, dacă utilizați o versiune de TLS care permite serverului [1] să propună un grup DH nestandard (și clientul ar accepta acel grup; cei sănătoși nu ar accepta) , atunci da, ar putea propune un grup extrem de slab (de exemplu unul pentru care $p-1$ nu are factori mari), iar acest lucru ar face ușoară recuperarea secretului partajat (și, prin urmare, a cheilor de trafic).

Astfel de „grupuri DH slabe” nu sunt posibile dacă faceți o versiune corectă a TLS (sau clientul refuză să accepte unele opțiuni destul de ciudate); pe de altă parte, dacă faceți DH, puteți solicita serverului să folosească o valoare privată DH ghicibilă (de exemplu, una care este o funcție a cookie-urilor hello server); atacatorul ar putea folosi asta pentru a asculta.

Pe de altă parte, dacă deții controlul serverului, de ce să te deranjezi? Serverul are cheile de trafic în mână; dacă adversarul controlează asta, ar fi și mai ușor ca serverul să dea cheile de sesiune oricui ascultă.

[1]: I gândi este serverul care propune grupul DH în TLS 1.2; dacă nu, schimbați doar client și server în argumentul de mai sus.

În protocolul TLS, serverul decide asupra grupului pentru schimbul de chei: grup Diffie-Hellman cu câmp finit sau curbă eliptică. Serverul trebuie să aleagă în constrângerile date de client. În TLS 1.3, grupurile sunt identificate dintr-o mică listă de grupuri standard. Versiunile anterioare ale protocolului permit serverului să descrie un grup personalizat. Pentru curbele eliptice, acest lucru este rar acceptat: majoritatea software-ului acceptă doar curbe numite. Dar pentru Diffie-Hellman cu câmp finit, clientul constrânge în mod clasic doar dimensiunea grupului, iar serverul trimite valoarea numerică a parametrilor. În timp ce majoritatea software-ului de astăzi acceptă extensia NamedGroup, majoritatea clienților vor accepta valori numerice pentru compatibilitate cu versiunea anterioară. Deci, un client poate fi păcălit să accepte parametrii FFDH care sunt backdoor.

Cu toate acestea, acest lucru este destul de irelevant ca o amenințare de securitate, deoarece server-ul alege parametrii. Dacă serverul dorește să compromită schimbul de chei, poate, de asemenea, să facă un schimb de chei perfect puternic și apoi să înregistreze secretul partajat undeva. Deci, pentru ca parametrii FFDH slabi să fie o problemă de securitate, trebuie să existe un model de securitate extrem de puțin probabil:

• Serverul rulează cod backdoored (sau are o configurație backdoored) și nu puteți detecta dacă backdoorul a fost introdus.
• Codul cu ușă în spate se află doar într-o mică parte a stivei TLS și sunteți încrezător că nu există nicio ușă în spate în altă parte care ar putea, de exemplu, să scurgă textul simplu sau secretul partajat direct.

Practic, FFDH cu ușă în spate în TLS poate fi doar serverul care își trage singur piciorul. Este irelevant pentru interceptarea traficului dintre alte gazde. Fie serverul este backdoor și nu aveți nevoie de el, fie serverul nu este backdoor și nu vă va ajuta la nimic.