Schimb simplu de chei, un singur server

Încerc să înțeleg mai bine cum funcționează TLS. Înțeleg că în cazul de utilizare normal aveți nevoie de diverse valori aleatorii generate și utilizate în schimbul de chei, pentru a preveni ca unele MITM să reutilizeze o transmisie anterioară pentru a falsifica serverul sau clientul.

Cu toate acestea, să presupunem un caz degenerat în care există un singur server a cărui cheie publică unică este deja cunoscută de clienții săi, precum și de diverși adversari. În acest caz, aș crede că tot ceea ce este strict necesar pentru a efectua un schimb de chei securizat ar fi următorul:

1. Clientul folosește cheia RSA publică a serverului pentru a cripta cheia de sesiune simetrică aleatorie
2. Clientul trimite serverul cheie de sesiune criptată
3. Serverul decriptează cheia de sesiune folosind cheia RSA privată a serverului
4. Serverul folosește cheia de sesiune pentru a cripta un mesaj „terminat”.
5. Serverul trimite clientului un mesaj criptat „terminat”.
6. Clientul folosește cheia de sesiune pentru a decripta mesajul „terminat”.
7. Clientul verifică că mesajul este „terminat”, strângerea de mână este finalizată

Deci, în acest proces simplificat, singura valoare care schimbă fiecare sesiune este cheia de sesiune în sine, astfel încât nu se utilizează aleatoriu client sau server anterior; și nu există un secret pre-master, din nou doar cheia de sesiune.

Se simte ca o simplificare excesivă a lucrurilor, dar întâmpin dificultăți în a vedea ce îmi lipsește. Dacă scopul principal al schimbului de chei este de a se asigura că serverul este singurul care primește cheia de sesiune, aceasta pare să fie sigură. Dovadă prin contradicție, urmărind din nou procesul de mai sus, dar din perspectiva unui adversar:

1. Adversary are deja cheia publică a serverului, și-ar putea cripta propria cheie de sesiune simetrică în scopuri MITM
2. Adversarul poate vedea cheia de sesiune criptată de la client, dar nu o poate decripta; poate trimite serverului propria sa cheie de sesiune MITM criptată
3. Serverul decriptează cheia de sesiune MITM, neștiind originea acesteia
4. Serverul folosește cheia de sesiune MITM pentru a cripta „terminat”
5. Serverul trimite clientului (de fapt adversarului) criptat „terminat”
6. Adversarul poate decripta „terminat”, dar nu poate recripta și trimite către client cu cheia de sesiune a clientului, pe care adversarul nu o poate decripta
7. Clientul nu va primi niciodată „terminat” criptat corect, fie de la server, fie de la adversar

Deci, se pare că singura slăbiciune potențială aici este că serverul nu are de unde să știe dacă comunică cu un client legitim sau cu un adversar - dar, după cum am înțeles, autentificarea clientului nu a fost niciodată în vedere de la început. Autentificarea serverului este, dar în acest caz nu este o problemă, deoarece există doar un singur server.

Deci am dreptate să înțeleg că dacă cineva ar folosi această schemă, ar fi imposibil ca un adversar să efectueze un atac MITM? Sau cum ar putea fi învins asta?

O problemă evidentă cu „TLS de caz degenerat” este că, pe măsură ce TLS este implementat, nu se poate presupune că clientul are cunoștințe a priori despre cheia publică a serverului; care trebuie transferat (și autentificat) cumva.

Cu toate acestea, întrebarea dvs. a fost:

Sau cum ar putea fi învins asta?

Ei bine, o problemă evidentă este că este destul de vulnerabilă la atacurile de reluare la nivelul clientului. Să presupunem că clientul valid efectuează o negociere cu serverul valid și apoi trece la trimiterea unor comenzi. Ceea ce ar putea face un adversar este să înregistreze ceea ce a trimis clientul și, mai târziu, să trimită acele mesaje din nou. Serverul va efectua exact aceleași operațiuni, va genera aceleași chei simetrice și apoi va procesa aceleași comenzi criptate. Cât de rău ar fi ar depinde de comenzile respective - dacă ar fi o necesitate pentru a descărca o pagină web, nu o problemă - dacă ar fi o comandă pentru a face o tranzacție bancară, ei bine, probabil că ar fi oarecum o problemă.

Cealaltă problemă (din perspectiva TLS modern) este că îi lipsește Perfect Forward Secrecy - dacă cineva reușește să fure cheia privată a serverului, nu numai că s-ar putea masca ca server (ceea ce este inevitabil; dacă înveți tot ce știe serverul, puteți face orice poate serverul valid), ei pot reveni și decripta sesiunile anterioare. Versiunile recente de TLS (în special, TLS 1.3) nu permit unui atacator să facă asta.