Uporaba kriptografije v internetu
Kazalo   
 

SSL Handshake Protocol

Odjemalec in strežnik se morata medsebojno overiti in se dogovoriti za algoritme in ključe, s katerimi bo potekala šifrirana izmenjava podatkov med njima.

Glede medsebojnega overjanja so možne naslednje kombinacije:

  • ni overjanja
  • anonimni odjemalec preveri certifikat strežnika
  • vsak preveri certifikat sogovornika

Prva možnost je najslabša - podatki se sicer izmenjujejo zašifrirani, vendar jih lahko kdo prestreže in spremeni (man-in-the-middle attack). Pri overjanju so certifikati po standardu X509v3. Certifikat vsebuje poleg lastnega še certifikat overovitvene ustanove - agencije, ki ga je izdala, lahko pa tudi verigo certifikatov nadrejenih agencij.

Nabor algoritmov se spreminja - dodajajo nove, opuščajo pa tiste, ki ne veljajo več za varne. V RFC 2246, ki je nastal leta 1999, imamo naslednji nabor algoritmov (Cipher Suite), med njimi so 

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_EXPORT_WITH_RC4_40_MD5

Pet let kasneje pa opuščajo algoritem MD5, kot simetrični algoritem pa se uvaja AES, kar lahko vidimo iz nabora OpenSSL verzija 0.9.7d.

Dokler se ne dogovorita za nabor, je v veljavi SSL_NULL_WITH_NULL_NULL, torej Record Protocol ne šifrira podatkov. Na začetku dogovarjanja klient pošlje strežniku vse kombinacije algoritmov, ki jih podpira, strežnik pa izbere tisto, ki jo tudi sam podpira in je našteta prej, Če ne najdeta skupnega nabora algoritmov, zveze ne moreta vzpostaviti. Algoritmi za komprimiranje podatkov (ZIP ipd.) niso vključeni v "Cipher Suite".

SSL loči podatke seje (Session), ki se hranijo dalj časa, in podatke povezave (Connection). S sejo označujemo neprekinjeno izmenjavo podatkov med klientom in strežnikom. Vsaki seji pa lahko pripada več povezav (connections), tudi istočasnih, n.pr. za prenos slike poleg teksta. Seji pripadajo naslednji podatki, ki si jih oba zapomnita in s tem skrajšata naslednja dogovarjanja:

  • oznaka seje - 32 bajtov
  • certifikat sogovornika (če ga ima oziroma če je tako določeno)
  • simetrični algoritem za šifriranje podatkov
  • zgostitveni algoritem za računanje MAC (Message Authentication Code)
  • postopek za komprimiranje
  • Master Secret - 48 bajtov (osnova za izračun simetričnega ključa in drugih parametrov)
  • is_resumable Flag (če je to stikalo vključeno, bosta za naslednjo povezavo te seje uporabila iste pravkar naštete parametre)

Za povezavo (connection) pa so značilni naslednji podatki:

  • Client Challenge (32-bajtno naključno generirano število)
  • Server Challenge (32-bajtno naključno generirano število)
  • zaporedno številko poslanega paketa
  • zaporedno številko dobljenega paketa
  • števila, ki jih izračunata iz Master Secret
    • simetrični ključ klienta
    • simetrični ključ strežnika
    • overitveno število klienta (MAC secret)
    • overitveno število strežnika
    • začetni vektor za klienta (če je potreben)
    • začetni vektor za strežnik (če je potreben)

Za vsako povezavo si izmenjata drugo osnovo za ključ (Challenge), zato s ključem ene povezave ne moremo dešifrirati podatkov druge povezave - poznati bi morali 48-bajtni Master Secret. Dolžina ene seje je po protokolu omejena na 24 ur (če je seveda klient in strežnik prej ne prekineta), kar bi veljalo skrajšati na nekaj ur.

Postopek poteka v naslednjih korakih:
V tem pregledu predpostavimo, da gre za RSA. Če izbereta DH ali Fortezzo, je postopek v korakih, kjer se tvori skupni ključ, drugačen. Z modro so označeni opcijski koraki, odvisni od načina overjanja (ali imata certifikate ali ne).

I. Začetek (Client Hello)
Odjemalec pošlje strežniku številko verzije SSL, kombinacije algoritmov, ki jih podpira, in 32 bajtov dolgo naključno generirano število (Client Challenge). Če to ni prvi poskus povezave in hoče le nadaljevati že prej začeto sejo, pošlje tudi oznako seje (Session ID), sicer je to polje prazno.

II. Odgovor strežnika
Strežnikov odgovor vsebuje verzijo SSL, seznam algoritmov, ki jih je strežnik izbral iz nabora, ki ga je predlagal odjemalec, in 32-bajtno število (Server Challenge). Če je od odjemalca dobil oznako seje, išče podatke o njej in če jih še ima, velja, da bosta ohranila iste podatke seje. V tem primeru strežnik vključi isto oznako seje in postopek je krajši.
Če pa gre za novo sejo, mora strežnik poslati klientu svoj javni ključ, da si bosta lahko izmenjala ključ za simetrični algoritem - lahko s certifikatom v koraku Certificate. Klient delno preveri ime strežnika za certifikat tako, da vpraša imenski strežnik (DNS). Kaj več se zaenkrat ne da avtomatizirati, zato bi uporabniki morali imeti brkljalnike nastavljene tako, da vedno sami preverijo certifikat in imena strežnika ter overitvenih agencij.
Če overjanje strežnika ni bilo izbrano, mora tvoriti začasni par ključev, da lahko pošlje javni ključ (Server Key Exchange).
Ob konfiguriranju strežnika lahko določimo, da zahteva certifikat klienta. V Certificate Request navede tiste CA (ustanove za overjanje javnih ključev), ki jim zaupa. Zvezo bo vzpostavil samo s tistimi klienti, ki imajo certifikat izbranih CA.

III. Odgovor klienta
Klient pošlje svoj certifikat, če ga ima in če ga je strežnik zahteval.
V naslednjem koraku (Client Key Exchange) izračuna 48-bajtno osnovo za simetrični ključ (Pre-Master Secret - PMS) iz verzije SSL in 46 bajtov dolgega števila. Zašifrira jo s strežnikovim javnim ključem. Iz tega bosta oba na enak način izračunala Master Secret (MS): 

MS = MD5(PMS + SHA('A' + PMS + Client Challenge + Server Challenge)) +
     MD5(PMS + SHA('BB' + PMS + Client Challenge + Server Challenge)) +
     MD5(PMS + SHA('CCC' + PMS + Client Challenge + Server Challenge))

Z znakom + označujemo spojitev (konkatenacijo) polj. A,B,C so konstante (A=0x41, B=0x42, C=0x43, ...). Na podoben način izračunata tako dolgo polje, kot ga potrebujeta, da iz njega izrežeta simetrična ključa in druge potrebne parametre, ki smo jih našteli na začetku: 

     MD5(MS + SHA('A' + MS + Client Challenge + Server Challenge)) +
     MD5(MS + SHA('BB' + MS + Client Challenge + Server Challenge)) + ...

Tako sta dosegla, da znata samo onadva izračunati skupni skriti ključ, čeprav so bila doslej izmenjana sporočila vsa nezašifrirana.

Če mora klient poslati certifikat, bo zdaj poslal še potrdilo, da res pozna pripadajoči skriti ključ (Certificate Verify) - z njim zašifrira povzetek, dobljen iz Master Secret in vseh doslej izmenjanih sporočil v tej Handshake povezavi. Strežnik ga bo dešifriral s klientovim javnim ključem in tako overil klienta.

Sledi Change Cipher Spec, ki pove, da bodo vsa naslednja sporočila zašifrirana s pravkar izračunanimi parametri.

V zadnjem sporočilu (Client Finished) klient zašifrira povzetek doslej izmenjanih sporočil v tej Handshake povezavi. Strežnik izračuna isti povzetek in če nista enaka, pomeni, da so bila sporočila na poti spremenjena, in prekine povezavo.

IV. Zaključek

Strežnik pošlje sporočilo Change Cipher Spec. Zaključi na enak način kot klient - pošlje povzetek vseh izmenjanih sporočil in tako dokaže klientu, da pozna svoj skriti ključ ter PMS in MS. Tako je dogovarjanje končano in bo Record Protocol začel šifrirati sporočila.

Na tem nivoju sta definirana še protokola:

Change Cipher Spec Protocol

To je signal, ki ga klient in strežnik pošljeta drug drugemu kot potrditev, da se bo šifriranje nadaljevalo s pravkar dogovorjenimi parametri. Tako n.pr. na koncu Handshake protokola z izmenjavo tega signala dosežeta, da se nabor algoritmov SSL_NULL_WITH_NULL_NULL zamenja z dogovorjenim.

Alert Protocol

je namenjen obvestilu sogovornika, da je prišlo do napake. Ob usodnih napakah vedno zaključita povezavo. Take napake so n.pr. če nimata skupnih algoritmov, če je MAC napačen. Napake ob preverjanju certifikatov pa niso vedno usodne - odvisno od nastavitev.

Marec 1999, ažurirano oktobra 2004