Slabosti protokola SSL/TLS na napad čovjekom u sredini

SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br. 1749 Slabosti protokola SSL/TLS na napad čovjekom u sredini Branimir Pačar Zagreb, studeni 2008.

Sažetak Glavnina sigurne komunikacije i Internet trgovine koristi SSL/TLS protokole. Iako se smatra da su SSL/TLS protokoli sigurni, u ovom radu će biti pokazano da to nije slučaj i da su posebno ranjivi na napade čovjekom u sredini. Ujedno će biti pokazano i da postoje načini kojima se može spriječiti takve napade i kako se mogu implementirati u već postojeće sustave. Praktični dio rada se sastoji od animacija koje prikazuju način rada SSL/TLS protokola, ali i od načina obrane od napada čovjekom u sredini. Abstract Majority of secure Internet communication and e-commerce uses SSL/TLS protocols. Although it is considered that these protocols are safe, this thesis will show that this is not truth and that SSL/TLS are especially vulnerable against man in the middle attacks. Also it will be shown that there are ways to protect against these kind of attacks and how they can be implemented in existing systems. Practical part of thesis consists of animations that show how SSL/TLS works and solutions against MITM attacks.

Sadržaj 1. UVOD... 1 2. SIGURNOSNI PROTOKOL ZA PRIJENOS PODATAKA SSL... 2 2.1. ULOGE U PROTOKOLU... 2 2.2. SSL PORUKE... 2 2.3. USPOSTAVA KRIPTIRANE KOMUNIKACIJE... 3 2.3.1. Pozdravna poruka klijenta... 4 2.3.2. Pozdravna poruka poslužitelja... 5 2.3.3. Poslužiteljeva poruka razmjene ključa... 5 2.3.4. Poruka kojom poslužitelj završava pozdrav... 6 2.3.5. Klijentova poruka razmjene ključa... 6 2.3.6. Poruka izmjene sigurnosnih postavki... 6 2.3.7. Završna poruka... 8 2.4. ZAVRŠETAK SIGURNE KOMUNIKACIJE... 8 2.5. AUTENTIFIKACIJA POSLUŽITELJA... 9 2.5.1. Poruka koja sadrži certifikat... 10 2.5.2. Klijentova poruka razmjene ključa... 10 2.6. RAZDVAJANJE AUTENTIFIKACIJE I ENKRIPCIJE... 10 2.6.1. Poslužiteljeva poruka razmjene ključa... 12 2.6.2. Klijentova poruka razmjene ključa... 12 2.7. AUTENTIFIKACIJA KLIJENTA... 12 2.7.1. Zahtjeva za certifikatom... 13 2.7.2. Poruka koja sadrži certifikat... 14 2.7.3. Potvrda certifikata... 14 2.8. NASTAVAK PRETHODNE SJEDNICE... 14 3. FORMATI PORUKA... 16 3.1. SLOJ ZAPISA... 16 3.2. PROTOKOL IZMJENE SIGURNOSNIH POSTAVKI... 18 3.3. PROTOKOL UZBUNE... 19 3.3.1. Nivo opasnosti... 19 3.3.2. Opis uzbune... 19 3.4. PROTOKOL RUKOVANJA... 20 3.4.1. Zahtjev za pozdravom... 20 3.4.2. Pozdravna poruka klijenta... 20 3.4.3. Pozdravna poruka poslužitelja... 23 3.4.4. Poruka koja sadrži certifikat... 23 3.4.5. Poslužiteljeva poruka razmjene ključa... 24

3.4.6. Zahtjev za certifikatom... 26 3.4.7. Poruka kojom poslužitelj završava pozdrav... 27 3.4.8. Klijentova poruka razmjene ključa... 27 3.4.9. Potvrda certifikata... 29 3.4.10. Završna poruka... 30 3.5. OSIGURAVANJE PORUKA... 31 3.5.1. Autentifikacija poruke... 31 3.5.2. Kriptiranje... 33 3.6. KREIRANJE KRIPTOGRAFSKIH PARAMETARA... 34 3.7. KRIPTOGRAFSKI PAKETI... 38 3.7.1. Algoritmi za razmjenu ključeva... 39 3.7.2. Kriptografski algoritmi... 39 3.7.3. Algoritmi za računanje sažetka... 40 4. TLS... 41 4.1. TLS VERZIJA PROTOKOLA... 41 4.2. TIPOVI PORUKA PROTOKOLA UZBUNE... 41 4.3. AUTENTIFIKACIJA PORUKA... 43 4.4. GENERIRANJE KLJUČA... 44 4.5. POTVRDA CERTIFIKATA... 47 4.6. ZAVRŠNA PORUKA... 47 4.7. OSNOVNI KRIPTOGRAFSKI PAKETI... 47 5. NAPADI S ČOVJEKOM U SREDINI... 49 5.1. NAPAD S ČOVJEKOM U SREDINI... 49 5.2. PRIJEDLOZI RJEŠENJA... 50 5.3. AUTENTIFIKACIJA OVISNA O SJEDNICI... 51 5.4. IMPLEMENTACIJA TLS-SA... 52 5.4.1. Osnovno rješenje... 53 5.4.2. Sustavi zasnovani na pobudi i odzivu... 54 5.4.3. Sustavi zasnovani na jednokratnoj bilježnici... 55 5.4.4. Proširenja i poboljšanja... 56 6. OPIS PRAKTIČNOG RADA... 58 7. ZAKLJUČAK... 63 8. LITERATURA... 64

1. Uvod Većina trgovine preko Interneta se temelji na protokolima SSL (engl. Secure Socket Layer) ili TLS (engl. Transport Layer Security) [1]. Njihov je zadatak uspostava sigurne komunikacije između poslužitelja i klijenta, a ujedno i uspješna autentifikacija i poslužitelja i klijenta. Iako SSL/TLS podržava autentifikaciju putem certifikata, u praksi se najčešće koriste oblici autentifikacije lozinkama, pin-ovima, ali i uz pomoć snažnijih autentifikacijskih mehanizama kao što su korištenje jednokratne lozinke (engl. OTP one time password), ili sustava pobude i odziva (engl. challenge/response systems). Iako se protokoli SSL i TLS smatraju sigurni, većina SSL/TLS temeljene Internet trgovine je ranjiva na različite vrste napada, među kojima je najvažniji napad čovjekom u sredini (engl. MITM man in the middle). Ako se napadač uspije smjestiti u komunikacijskom kanalu između klijenta i poslužitelja i uspješno zavarati obje strane koje komuniciraju, potencijalno može napraviti veliku štetu i klijentu i poslužitelju. Glavnina trgovine Internetom su male transakcije pa je upitna isplativost izvođenja napada čovjekom u sredini, koji su relativno složeni, no daljnjim razvojem Internet trgovine i transakcije će postajati sve veće, pa će i napadi biti češći. Kako bi se spriječile mogućnosti takvih napada, SSL/TLS protokoli moraju doživjeti izmjene. U ovom radu su opisani prijedlozi nadogradnje SSL/TLS protokola koje su predložili Rolf Oppliger, Ralf Hauser i David Basin [2][3]. Oni su uvjereni da bi koristeći postupke koje oni predlažu, mogli uspješno koristiti SSL/TLS protokole bez bojazni od napada čovjekom u sredini. 1

2. Sigurnosni protokol za prijenos podataka SSL 2.1. Uloge u protokolu Kod SSL protokola definirane su dvije uloge za jedinice koje komuniciraju. Jedna je klijent, druga poslužitelj. Razlike su značajne, a SSL sustav zahtjeva da jedan sustav bude klijent, a drugi poslužitelj. Klijent je sustav koji inicira komunikaciju, dok poslužitelj odgovara na klijentove zahtjeve. Pošto je najčešće mjesto upotrebe SSL-a sigurno surfanje Internetom, SSL klijentom možemo smatrati web preglednik, a web stranice imaju ulogu SSL poslužitelja. Najvažnija razlika među klijentom i poslužiteljem se vidi kod procesa razmjena poruka i pregovaranja oko sigurnosnih postavki. Pošto klijent inicira komunikaciju, na njemu je da predloži sigurnosne parametre koji će se koristiti. Poslužitelj izabire među ponuđenim postavkama i odlučuje koje će postavke sustavi koristiti. 2.2. SSL poruke Komunikacija između klijenta i poslužitelja se odvija uz pomoć poruka. Oblici poruka su unaprijed definirani. Točan format poruka će biti naknadno objašnjen. Ovdje je naglasak na funkcionalnosti poruka. Slijedi popis svih poruka i njihov opis: Alert obavještava sudionike o mogućem sigurnosnom propustu ili grešci u komunikaciji; ApplicationData podaci koje dvije strane razmjenjuju, a kriptirani su, autentificirani i verificirani od strane SSL-a; Certificate poruka koja prenosi certifikat sa javnim ključem; CertificateRequest zahtjev poslužitelja klijentu za klijentovim certifikatom; CertificateVerify poruka kojom klijent potvrđuje da ima tajni ključ koji odgovara javnom ključu u certifikatu; ChangeCipherSpec obavijest o početku korištenja dogovorenih sigurnosnih postavki; ClientHello poruka od strane klijenta kojom obavještava poslužitelja o sigurnosnim servisima koje želi i koje podržava; ClientKeyExchange klijentova poruka koja sadrži kriptografske ključeve za komunikaciju; Finished obavijest da su svi koraci pregovora gotovi i da je uspostavljena sigurna komunikacija; HelloRequest zahtjev poslužitelja klijentu za početak ili ponovni početak pregovora oko sigurnosnih parametara u komunikaciji; ServerHello poruka poslužitelja kojom javlja koji će sigurnosni servisi biti korišteni; ServerHelloDone obavijest poslužitelja da je poslao sve zahtjeve klijentu za uspostavu komunikacije; ServerKeyExchange poruka poslužitelja koja sadrži kriptografske ključeve za komunikaciju. 2

2.3. Uspostava kriptirane komunikacije Osnovna zadaća SSL-a je omogućavanje klijentu i poslužitelju uspostavu kanala za kriptiranu komunikaciju. Opis postupka: Slika 2.1 Uspostava sigurne komunikacije 1. Klijent šalje ClientHello poruku predlažući parametre za SSL komunikaciju; 2. Poslužitelj odgovara sa ServerHello porukom i odabire parametre; 3. Poslužitelj šalje svoj javni ključ u ServerKeyExchange poruci; 4. Poslužitelj zaključuje svoj dio pregovora sa ServerHelloDone porukom; 5. Klijent šalje ključ kriptiran javnim ključem poslužitelja u ClientKeyExchange poruci; 6. Klijent šalje ChangeCipherSpec poruku kako bi aktivirao sigurnosne opcije za sve daljnje poruke; 7. Klijent šalje poruku Finished i javlja poslužitelju da provjeri novo postavljene opcije; 8. Poslužitelj šalje ChangeCipherSpec poruku kako bi aktivirao sigurnosne opcije za sve daljnje poruke; 9. Poslužitelj šalje poruku Finished i javlja klijentu da provjeri novo postavljene opcije. 3

2.3.1. Pozdravna poruka klijenta Pomoću ClientHello poruke započinje SSL komunikacija između dvije strane. Pomoću nje klijent zahtjeva od poslužitelja da započne pregovore oko sigurnosnih servisa koji će se koristiti u komunikaciji. Važni dijelovi poruke su: Verzija (engl. Version) definira najveću verziju SSL protokola koju klijent podržava; Slučajni broj (engl. RandomNumber) 32 bajtni slučajni broj koji se koristi u kriptografskim izračunima; ID sjednice (engl. SessionID) identificira SSL sjednicu; Kriptografski paket (engl. CipherSuite) popis kriptografskih paketa koje klijent može podržati; Kompresijske metode (engl. CompressionMethod) popis kompresijskih metoda koje klijent može podržati. Polje verzija ClientHello poruke sadrži broj najviše verzije protokola koju podržava klijent. Trenutna verzija je 3.0. Poslužitelj može pretpostaviti da klijent podržava verziju koju navodi, ali i sve ranije verzije protokola. Stoga ako klijent u svojoj poruci pošalje da podržava verziju 3.0, a poslužitelj podržava samo SSL verziju 2.0, poslužitelj može odgovoriti porukama verzije 2.0 i očekivati da će klijent to razumjeti. U takvim slučajevima klijent može odlučiti želi li nastaviti komunicirati i to koristeći SSL verziju 2.0 ili želi odustati od daljnje komunikacije, jer verzija 2.0 pruža manju sigurnost u komunikaciji od verzije 3.0. Polje slučajni broj sadrži 32 bajtni slučajni broj koji služi za izračun kriptografskih vrijednosti. SSL specifikacija predlaže da se u 4 bajta koristi vrijeme i datum, kako niti jedan slučajni broj ne bi ponavljao i tako štiti od mogućnosti kopiranje neke stare SSL poruke i njenog iskorištavanja u svrhu napada. Ostalih 28 bajtova bi trebali biti kriptografski siguran slučajan broj. Kod generiranja slučajnih brojeva u računalu, uglavnom se koristi pseudo slučajni generator brojeva. Kod njegovog ispravnog korištenja dobiva se prividni dojam da su brojevi slučajni. No to nije tako. Ti brojevi se dobivaju po unaprijed odabranim algoritmima. To je velika mana kad se radi o sigurnosti. Eventualni napadač, kad bi saznao po kojem algoritmu se dobivaju slučajni brojevi, bi mogao predvidjeti svaki budući broj. To bi mu dalo mogućnost pripreme napada na takav sustav. Kako bi se to izbjeglo, kod SSL-a se koristi drugačija tehnika generiranja slučajnih brojeva koja se temelji na kriptografskim algoritmima. Polje kriptografski paket omogućava klijentu da izlista različite kriptografske servise koje podržava, uključujući algoritme i veličine ključeva. Poslužitelj zatim donosi odluku koji će se od ponuđenih koristiti u komunikaciji. Klijent u polju kompresijske metode navodi različite metode kompresije podataka. One su važan dio SSL-a. Vrlo je važno da se kompresija podataka događa prije nego su podaci kriptirani, jer kriptiranje mijenja podatke matematičkim metodama i kompresija nakon toga bi bila skoro nemoguća, tj. da je moguća, to bi značilo propust kod enkripcije. U trenutnoj verziji SSL-a, nisi definirane metode kompresije tako da je trenutno ovo polje ograničenog korištenja. U budućnosti mogu biti definirane dodatne metode kompresija, ali ne za SSL, nego za TLS. 4

2.3.2. Pozdravna poruka poslužitelja Nakon što poslužitelj primi ClientHello poruku, odgovara sa ServerHello. ServerHello poruka je u mnogočemu jednaka ClientHello poruci, no postoje razlike. Polja koja sadrži su sljedeća: Verzija definira verziju SSL protokola koja će se koristiti u komunikaciji; Slučajni broj 32 bajtni slučajni broj koji se koristi u kriptografskim izračunima; ID sjednice identificira SSL sjednicu; Kriptografski paket kriptografski parametri koje koji će se koristiti u komunikaciji; Kompresijska metoda metoda kompresije podataka koja će se koristiti u komunikaciji. Polje verzije je prvi primjer gdje se vidi kako poslužitelj donosi konačnu odluku koja se tiče komunikacije. Kod ClientHello poruke klijent je naveo verziju koju podržava, no verzija koja će se koristiti je posljedica odluke poslužitelja i navedena je u ovom polju. Dakako, poslužitelj ne može odabrati bilo koju verziju, nego verziju jednaku ili manju verziji koju je predložio klijent. Polje slučajni broj je jednako kao i kod klijenta s razlikom da ovdje slučajnu vrijednost bira poslužitelj. Zajedno sa slučajnim brojem klijenta ovo će biti važna informacija u izračunu kriptografskih vrijednosti. Svojstva slučajnog broja poslužitelja jednaka su svojstvima koja vrijede i za klijentov slučajni broj. Polje id sjednice u ServerHello poruci može sadržavati vrijednost. U ovom slučaju vrijednost jednoznačno identificira SSL sjednicu. Koristi se da bi se nastavile prijašnje sjednice i ubrzao postupak pregovora. Ako postoji sigurnost da sjednica neće biti nastavljane u budućnosti, ovo se polje može izostaviti. Poljem kriptografski paket se javljaju klijentu točni kriptografski parametri koji će se koristiti. Razlika u odnosu na ClientHello poruke je da se ovdje javlja jedan set parametara, dok je u ClientHello poruci bilo ponuđeno više od kojih je poslužitelj izabrao jedan. Isti slučaj je sa poljem kompresijske metode, koje sadrži samo jednu metodu sažimanja podataka koja će se koristiti tijekom komunikacije. 2.3.3. Poslužiteljeva poruka razmjene ključa Nakon ServerHello poruke slijedi ServerKeyExchange poruka koja nadopunjuje kriptografske parametre iz ServerHello poruke. Dok su u ServerHello poruci bili dogovoreni algoritam, veličina ključa i još neki parametri u ServerKeyExchange poruci se prenosi javni ključ poslužitelja. Format ključa ovisi o vrsti algoritma izabranog u poruci prije. Treba primijetiti kako ServerKeyExchange poruka nije kriptirana, pa se u njoj prenosi samo javni ključ. Njega će klijent koristiti kako bi prenio ključ koji će se koristiti tijekom komunikacije za kriptiranje podataka. 5

2.3.4. Poruka kojom poslužitelj završava pozdrav Pomoću ServerHelloDone poruke poslužitelj javlja klijentu da je gotov sa inicijalnim pregovorima. Sama poruka ne sadrži nikakve informacije. Važno je da kad klijent primi ovu poruku zna da može nastaviti sa daljnjim postupkom uspostave sigurnosne komunikacije. 2.3.5. Klijentova poruka razmjene ključa Nakon što je poslužitelj javio da je završio inicijalne pregovore, klijent odgovara sa ClientKeyExchange porukom. Isto kako je poslužitelj u ServerKeyExchange poruci dao svoj javni ključ, tako i klijent u ovoj poruci šalje ključ. Razlika je u tome što klijent šalje ključ koji će se koristiti u simetričnoj enkripciji i isti ključ će koristiti i klijent i poslužitelj. Razlika u odnosu na ServerKeyExchange poruku je i ta što je ovdje poruka kriptirana i to javnim ključem koji je poslužitelj poslao. Ovime se također verificira da poslužitelj ima privatni ključ koji odgovara javnom ključu koji je klijent primio, jer u protivnom poslužitelj neće biti u mogućnosti dekriptirati poruku koju mu je klijent poslao. 2.3.6. Poruka izmjene sigurnosnih postavki Nakon što je klijent poslao ClientKeyExchange poruku, prvi dio SSL pregovora je gotov. U ovom trenutku su i klijent i poslužitelj spremni započeti komunikaciju koristeći sigurnosne servise koje su dogovorili. Kako bi to počeli, postoji posebna poruka ChangeCipherSpec kojom se kazuje da će sve poruke od sada biti poslane koristeći sigurnosne servise. Pošto je prelazak na sigurnu komunikaciju kritičan, a obadvije strane ga moraju obaviti na točno određen način, SSL specifikacija koja opisuje kako to napraviti je vrlo precizna. Definira simetrični algoritam kriptiranja, algoritam za izračunavanje integriteta poruke, i materijal za izračun ključeva za te algoritme. Zna i da će ključevi klijenta biti različiti od poslužiteljevih ključeva. Za svaki sustav, i klijentov i poslužiteljev, SSL definira stanje čitanja i stanje pisanja. Stanje čitanja definira sigurnosne informacije za podatke koje sustav prima, a stanje pisanja definira sigurnosne informacije za podatke koje sustav šalje. ChangeCipherSpec služi kao znak da sustav počne koristi sigurnosne informacije. No prije nego što pošalje poruku mora znati sve sigurnosne informacije koje će aktivirati. Nakon što klijent pošalje ChangeCipherSpec poruku aktivira svoje stanje pisanja, a kad poslužitelj primi ChangeCipherSpec poruku aktivira stanje čitanja. Slika 2.2 prikazuje stanja pisanja i čitanja poslužitelja i klijenta. SSL definira dva stanja čitanja i dva stanja pisanja. Jedno stanje je aktivno, a drugo je stanje u očekivanju. Iz toga slijedi da klijent i poslužitelj sadrže po četiri stanja. Aktivno pisanje, aktivno čitanje, u očekivanju pisanja i u očekivanju čitanja. Također su prikazani i najvažniji dijelovi stanja. To su algoritam kriptiranja, algoritam za provjeru integriteta poruke i podaci za ključ. U primjeru na slici 2.2 DES se koristi kao simetrični algoritam kriptiranja, MD5 kao algoritam za provjeru integriteta poruke. Svaki sustav počinje u aktivnom stanju bez definiranih algoritama. To se i podrazumijeva, jer dok se strane ne dogovore o sigurnosnim parametrima, ne može doći do sigurne komunikacije. Kako se razmjenjuju poruke sustavi prvo izgrađuju stanja u očekivanju. Prvo 6

se dogovaraju oko algoritama, a zatim izmjenjuju podatke za ključ. Tek tada sustav ta stanja u očekivanju aktivira sa ChangeCipherSpec porukom i ona prelaze u aktivna stanja. Kod klijenta se događaju sljedeće promjene: 1. kad klijent inicira SSL komunikaciju ClientHello porukom postavlja svoja obadva aktivna stanja na null vrijednost, označavajući time da nema sigurnosnih postavki. Stanja u čekanju su inicijalno nepoznata; 2. kad klijent primi ServerHello poruku iz nje sazna koje je algoritme poslužitelj odabrao za komunikaciju. Tada mijenja obadva stanja u čekanju i za algoritme postavlja algoritme koje je poslužitelj odabrao u ServerHello poruci. Materijal za izračun ključa je i dalje nepoznat; Slika 2.2 Proces dogovora sigurnosnih postavki 5. nakon što je klijent poslao poruku ClientKeyExchange zna koji će se ključevi koristiti u komunikaciji i ažurira stanja u čekanju; 6. kad klijent pošalje ChangeCipherSpec poruku, prebacuje iz stanja u očekivanju pisanja u aktivno stanje pisanja, a stanje u očekivanju pisanja postavlja na nepoznato. Nikakve promjene nisu napravljene na stanju čitanja. Ovo znači da će od ovog 7

trenutka sve poruke koje će klijent slati biti kodirane DES algoritmom i verificirane MD5 algoritmom; 8. kad klijent primi ChangeCipherSpec poruku od strane poslužitelja, ažurira stanje čitanja i prebacuje postavke iz stanja čekanja u aktivno stanje. Ovime mu je poslužitelj rekao da će sve poruke koje će ubuduće dobiti biti kodirane DES algoritmom i verificirane MD5 algoritmom. Kod poslužitelja se događa sljedeće: 1. kad poslužitelj primi ClientHello poruku postavlja oba svoja aktivna stanja na null, dok su stanja u čekanju nepoznata; 2. nakon što pošalje ServerHello poruku, zna koji će se algoritmi koristi za kriptiranje i provjeru integriteta poruke, te u skladu s tim ažurira stanja u čekanju; 5. nakon što je primio ClientKeyExchange poruku zna koji će se podaci koristi za ključ i u skladu s tim ažurira stanja u čekanju; 6. kad primi ChangeCipherSpec poruku, zna da će klijent od sada koristiti sigurnosne postavke i u skladu s tim postavlja u aktivno stanje čitanja postavke koje su bile u očekivanju stanja pisanja. Nikakve promjene se ne događaju u stanju pisanja; 7. slanjem vlastite ChangeCipherSpec poruke postavlja svoje aktivno stanje pisanja na postavke koje su bile pod stanjem očekivanje pisanja. Poslije ove poruke sve koje će slati koristiti će sigurnosne postavke iz aktivnog stanja pisanja. Treba primijetiti da je na slici 2.2 označeno da u trenutku kad jedna strana ažurira stanje pisanja, druga ažurira stanje čitanja. U stvarnosti to nije tako. Jedna strana će ažurirati svoje stanje kad pošalje poruku, dok će druga to učiniti tek kad primi poruku. 2.3.7. Završna poruka Odmah nakon slanja ChangeCipherSpec poruke, svaki sustav šalje i Finished poruku. Pomoću nje svaki sustav verificira da su pregovori uspješno završili i da sigurnost nije kompromitirana. Dva aspekta poruke pridonose sigurnosti. Finished je prva poruka poslana nakon što su strane odlučile prijeći na sigurnosnu komunikaciju, pa su samim time i na njoj primijenjeni dogovoreni sigurnosni mehanizmi. Ako strana koja primi poruku nije u mogućnosti dekriptirati ju i verificirati, znači da je došlo do sigurnosnog propusta. Sadržaj poruke također pridonosi sigurnosti. Finished poruka sadrži sažetak koji je izveden od svih poruka koje su sudjelovale u Handshake postupku. Ako bi napadač koji nije sudjelovao u razmjeni poruka pokušao izvesti napad, ne bi mogao jer nema sve prijašnje poruke i takav napad bi bio razotkriven. 2.4. Završetak sigurne komunikacije Iako se u praksi rijetko koristi, SSL ima definiran način završetka sigurne komunikacije. Prilikom takvog završetka klijent šalje poslužitelju poruku ClosureAlert, na što poslužitelj vraća istu takvu poruku. Ovakav način završetka sprečava napade prekidanjem. 8

2.5. Autentifikacija poslužitelja Slika 2.3 Završetak sigurne komunikacije U prethodnom poglavlju je prikazano kako se može uspostaviti sigurna komunikacija. No to nije u svim slučajevima potpuno zadovoljavajuće. Glavni razlog zašto se želi sigurno komunicirati je da treća strana ne vidi sadržaje poruka koje se razmjenjuju s onim s kim se komunicira. Napadač se može predstaviti kao osoba s kojom se želi razmjenjivati određene podatke, a ni ne sluteći da bi to mogao biti napadač započne se sigurnu komunikaciju s njim, misleći da su podaci sigurni od napadača. Kako bi se izbjegle takve situacije SSL uvodi mehanizme kojima svaka strana može autentificirati drugu stranu i tako biti sigurna da komunicira baš sa onime s kim bi htjela komunicirati, a ne sa maskiranim napadačem. Nameće se pitanje zašto se autentifikacija obadviju strana ne koristi uvijek. Autentifikacija iziskuje dodatne napore i resurse i od poslužitelja i od klijenta. Kod Internet trgovine vrlo je važno da je stranica s koje se želi kupiti nešto autentificirana. Tu je važna autentifikacija. No kada prodavač dobije broj kartice, provjeri je li važeća i naplati svoju uslugu. Pošto poslužitelju nije važna SSL autentifikacija klijenta, postoji mogućnost samo autentifikacije poslužitelja. Slika 2.4 Autentifikacija poslužitelja 9

Proces je sličan osnovnom procesu uspostave SSL komunikacije. Razlika je u dvije poruke, Certificate i ClientKeyExchange koje su na slici 2.4 prikazane tamnije od ostalih. Koraci komunikacije su sljedeći: 1. klijent šalje ClientHello poruku zahtijevajući SSL parametre; 2. poslužitelj odgovara sa ServerHello porukom; 3. poslužitelj šalje certifikat koji sadrži javni ključ; 4. poslužitelj završava svoj dio pregovora sa ServerHelloDone porukom; 5. klijent šalje podatke o ključu sjednice kriptirane javnim ključem poslužitelja; 6. sa ChangeCipherSpec porukom klijent aktivira sigurnosne postavke komunikacije; 7. klijent šalje Finished poruku da javi poslužitelju novo aktivirane postavke; 8. poslužitelj šalje ChangeCipherSpec poruku aktivirajući sigurnosne postavke; 9. sa Finished porukom javlja klijentu da provjeri novo postavljene sigurnosne postavke. 2.5.1. Poruka koja sadrži certifikat Kako bi se autentificirao, poslužitelj klijentu šalje Certificate poruku, umjesto ServerKeyExchange poruke koja je bila u prvom primjeru. Poruka sadrži certifikat koji počinje javnim ključem, a završava certifikatom certifikacijskog centra. Klijentova odgovornost je da se uvjeri u ispravnost certifikata i da može vjerovati poslužitelju. To znači da mora verificirati potpise, provjeriti ispravnost vremenskih rokova i opoziva. Također se mora uvjeriti da je certifikacijski centar vjerodostojan. Verifikacija certifikata je ključna za ostvarivanje sigurnosti. 2.5.2. Klijentova poruka razmjene ključa ClientKeyExchange poruka se u procesu sa autentifikacijom poslužitelja razlikuje od procesa bez autentifikacije iako u maloj količini. U procesu bez autentifikacije klijent je podatke u ovoj poruci kriptirao javnim ključem koji mu je poslužitelj poslao u ServerKeyExchange poruci. Ovdje se poslužitelj autentificira, pa je poslao certifikat. Sada koristi javni ključ sadržan u certifikatu i tako osigurava da jedino poslužitelj koji mu je poslao taj certifikat ima mogućnost dekriptiranja poruke. 2.6. Razdvajanje autentifikacije i enkripcije U prethodan dva slučaja poslužitelj je slao klijentu podatke o svojem javnom ključu. Taj javni ključ je korišten i za enkripciju podataka u ClientKeyExchange poruci, a ujedno i za autentifikaciju poslužitelja. Ovakva situacija nije uvijek poželjna, a postoje i slučajevi kada je nemoguće ju podržati. 10

Neki asimetrični algoritmi se koriste samo za potpisivanje poruka. Dizajnirani su tako da je njima nemoguće kriptirati podatke. Sljedeći razlog koji zahtjeva dva različita ključa za potpisivanje i kriptiranje podataka nije tehničke prirode, nego pravne. U nekim državama kontrolira se izvoz proizvoda koji koriste kriptografiju. Tako je u Sjedinjenim Američkim Državama bio slučaj da se za kriptiranje podataka mogu koristiti ključevi samo određene veličine, tj. broja bajtova. Pa se nije smjelo izvoziti algoritme koji koriste ključeve veće od zadanog maksimuma. U isto vrijeme na algoritme koji služe za potpisivanje podataka nije bilo nikakvih ograničenja. Iz tog razloga bi se za potpisivanje mogao koristiti algoritam sa ključevima koji su neograničeno veliki i tada bi imali potpise velike sigurnosti, dok bi za kriptiranje podataka koristili algoritme s manjim ključevima. SSL proces u takvim slučajevima izgleda kao na slici 2.5. Koraci u uspostavi konekcije: Slika 2.5 Razdvajanje autentifikacije i enkripcije 1. klijent šalje ClientHello poruku zahtijevajući SSL parametre; 2. poslužitelj odgovara sa ServerHello porukom; 3. poslužitelj šalje certifikat koji sadrži javni ključ; 4. poslužitelj šalje javni ključ koji bi klijent trebao koristiti za kriptiranje poruke. Ovaj ključ je potpisan privatnim ključem poslužitelja koji odgovara javnom ključu koji se nalazi u certifikatu; 5. poslužitelj završava svoj dio pregovora sa ServerHelloDone porukom; 6. klijent šalje podatke o ključu sjednice kriptirane javnim ključem poslužitelja; 11

7. sa ChangeCipherSpec porukom klijent aktivira sigurnosne postavke komunikacije; 8. klijent šalje Finished poruku javljajući poslužitelju novo aktivirane postavke; 9. poslužitelj šalje ChangeCipherSpec poruku aktivirajući sigurnosne postavke; 10. sa Finished porukom javlja klijentu da provjeri novo postavljene sigurnosne postavke. 2.6.1. Poslužiteljeva poruka razmjene ključa ServerKeyExchange poruku poslužitelj šalje nakon Certificate poruke. U ovoj poruci se nalazi javni ključ koji služi klijentu za kriptiranje poruka. ServerKeyExchange poruka sadrži iste podatke kao i poruka u osnovnom načinu uspostave SSL konekcije, ali postoji jedna bitna razlika. Ova poruka je potpisana tajnim ključem poslužitelja koji odgovara javnom ključu sadržanom u certifikatu. Možemo reći da je ova poruka digitalno potpisana od strane poslužitelja. Kada klijent primi ovu poruku, morat će uzeti javni ključ sadržan u certifikatu kojeg je dobio od poslužitelja i otključati poruku, time potvrđujući da je poruka koja je došla upravo od poslužitelja s kojim vrši komunikaciju. 2.6.2. Klijentova poruka razmjene ključa Kao i u prijašnjim slučajevima ovom porukom se završavaju pregovori oko sigurnosnih parametara. Kao i prije i sada sadrži podatke za izračun simetričnog ključa. Ovdje treba primijetiti da ključ kojim su kriptirani podaci u ovoj poruci nije ključ sadržan u certifikatu, nego ključ koji je poslan u ServerKeyExchange poruci. 2.7. Autentifikacija klijenta Pošto SSL nudi autentifikaciju poslužitelja, logično je očekivati da se i klijent može autentificirati. Način na koji se to radi je u suštini isti načinu na koji se poslužitelj autentificira. Na slici 2.6 se vidi cijeli proces. Tamno su označene poruke koje se razlikuju od dosad promatranih slučajeva. Koraci procesa: 1. klijent šalje ClientHello poruku zahtijevajući SSL parametre; 2. poslužitelj odgovara sa ServerHello porukom; 3. poslužitelj šalje certifikat koji sadrži javni ključ; 4. poslužitelj šalje CertificateRequest poruku kojom kazuje da želi autentificirati klijenta; 5. poslužitelj završava svoj dio pregovora sa ServerHelloDone porukom; 6. klijent šalje svoj certifikat koji sadrži javni ključ u Certifikate poruci; 7. klijent šalje podatke o ključu sjednice kriptirane javnim ključem poslužitelja; 12

8. klijent šalje CertificateVerify poruku u kojoj potpisuje podatke o sjednici koje će poslužitelj otključati javnim ključem klijenta i tako verificirati da ima klijentov javni ključ; 9. sa ChangeCipherSpec porukom klijent aktivira sigurnosne postavke komunikacije; 10. klijent šalje Finished poruku da javi serveru novo aktivirane postavke; 11. poslužitelj šalje ChangeCipherSpec poruku aktivirajući sigurnosne postavke; 12. sa Finished porukom javlja klijentu da provjeri novo postavljene sigurnosne postavke. Slika 2.6 Autentifikacija klijenta i poslužitelja 2.7.1. Zahtjeva za certifikatom U SSL konekciji poslužitelj je taj koji utvrđuje je li autentifikacija klijenta potrebna. Klijent ne može utjecati na to. Ako je potrebna autentifikacija, mora se autentificirati u suprotnom se nastavlja bez nje. Ako poslužitelj želi da se klijent autentificira, šalje mu CertificateRequest poruku kao dio pregovora o sigurnosnim postavkama. Sa slike 2.6. se vidi da poslužitelj zahtjev za klijentovim certifikatom šalje nakon što je poslao svoj 13

certifikat, a kad bi slao ServerKeyExchange poruku, zahtjev bi išao iza te poruke. SSL specifikacija zabranjuje poslužitelju slanje zahtjeva za certifikatom ukoliko prije toga nije poslao svoj certifikat. Ovim se osigurava da klijent zna poslužiteljev identitet prije nego otkrije vlastiti. U zahtjevu za certifikatom poslužitelj navodi listu tipova certifikata koje prihvaća. 2.7.2. Poruka koja sadrži certifikat Oblik klijentove Certificate poruke jednak je onoj koju šalje poslužitelj. Klijent ju šalje odmah nakon što je primio ServerHelloDone poruku. Ukoliko klijent nema certifikat ili ne može zadovoljiti uvjete koje mu je poslužitelj postavio u zahtjevu za certifikatom, odgovara sa NoCertificateAlert porukom. Poslužitelj tada može nastaviti sa daljnjom komunikacijom s tim da ne može autentificirati klijenta ili može prekinuti komunikaciju. U SSL specifikaciji klijentov javni ključ se koristi samo za potpisivanje, nikad za kriptiranje podataka, pa stoga nema potrebe, kao kod poslužitelja za razdvajanje autentifikacije i kriptiranja. 2.7.3. Potvrda certifikata Nakon što je klijent poslao svoj certifikat, proces autentifikacije nije gotov. Mora dokazati da posjeduje tajni ključ koji je par javnom ključu poslanom u certifikatu. Kako bi to dokazao koristi CertificateVerify poruku. Ova poruka sadrži digitalno potpisani sažetak ključa i svih prethodno razmijenjenih poruka u postupku dogovora. Na slici 2.6 se vidi da CertificateVerify poruka ne ide odmah nakon Certificate poruke. Razlog tome je sadržaj verificirajuće poruke. U njoj se nalazi sažetak ključa koji poslužitelj dobije sa ClientKeyExchange porukom, pa poslužitelj ne bi bio u mogućnosti verificirati klijenta, jer ne bi imao sve podatke potrebne za to. 2.8. Nastavak prethodne sjednice Iz prethodnih primjera se može zaključiti da uspostava SSL sjednice može bi složena, zahtijevati dosta kriptografskih izračuna i razmjene velikog broja poruka. Kako bi se to izbjeglo, SSL definira mehanizam kojim je moguće ponovo iskoristiti već dogovorene parametre iz neke prethodne konekcije. Na slici 2.7 se vidi takav slučaj: Koraci su sljedeći: 1. klijent šalje ClientHello poruku specificirajući već prije dogovorenim identifikatorom sjednice; 2. poslužitelj odgovara sa ServerHello porukom slažući se sa poslanim identifikatorom sjednice; 3. poslužitelj šalje ChangeCipherSpec poruku ponovo aktivirajući sigurnosne postavke; 4. poslužitelj šalje Finished poruku da javi poslužitelju novo aktivirane postavke; 5. sa ChangeCipherSpec porukom klijent aktivira sigurnosne postavke komunikacije; 14

6. klijent šalje Finished poruku da javi poslužitelju novo aktivirane postavke. Ključ nastavka prijašnje sjednice je u ClientHello poruci. Klijent predloži da se nastavi prijašnja sjednica tako što u svoju poruku uključi identifikator prijašnje sjednice. Ako poslužitelj želi nastaviti sjednicu, u svojoj ServerHello poruci vraća taj isti identifikator, u protivnom vraća neki novi identifikator i nastavljaju se potpuni pregovori oko sigurnosnih parametara. Slika 2.7 Nastavak prethodne sjednice Iako ovakav način omogućava bržu uspostavu veze, smanjuje se sigurnost takvih sustava i omogućuju se napadačima nove vrste napada. 15

3. Formati poruka SSL protokol se sastoji od nekoliko komponenti. Na slici 3.1 se vidi kako su organizirane. SSL poruke se dobivaju iz četiri različita izvora: protokol ChangeCipherSpec, protokol Handshake, protokol Alert i aplikacija. Sve poruke koje se dobivaju iz ova četiri dijela, prihvaća Record Layer, formatira ih, sprema u odgovarajuće okvire i dalje ih prosljeđuje protokolu na transportnom sloju kao što je TCP (engl. Transmission Control Protocol). Slika 3.1 SSL se sastoji od nekoliko protokola SSL protokol ne može egzistirati samostalno. Oslanja se na dodatne protokole na nižim slojevi koji osiguravaju razmjenu poruka. SSL zahtjeva da niži sloj bude pouzdan, tj. da osigurava da sve poruke budu isporučene ispravnim redoslijedom i bez grešaka. Iz prethodnih zahtjeva proizlazi da je idealan za to TCP. Kao i većina protokola koja koristi TCP, SSL je samoodrediv. To znači da SSL može sam, bez pomoći TCP-a, odrediti početak i kraj svojih poruka. Kako bi to znao napraviti SSL dodaje vlastiti brojač duljine poruke u TCP segment. Time se omogućava da se više SSL poruka stavi u jedan TCP segment. Na slici 3.2 se vidi da je sedam SSL poruka prebačeno sa samo tri TCP segmenta. Posljedica ovakvog načina prijenosa poruka je manje opterećenje mreže, a samim time i veća efikasnost SSL protokola. 3.1. Sloj zapisa SSL koristi protokol sloj zapisa (engl. Record Layer) za pakiranje svih poruka. Osigurava format za ChangeCipherSpec, Alert, Handshake i aplikacijske poruke. Formatiranje koje osigurava sastoji se od pet bajtova koji prethode ostalim porukama protokola i dijelom za autentifikaciju poruke, ako je uključena opcija integriteta poruke. Također je odgovoran i za enkripciju, ako je taj servis aktivan. Poredak bajtova je big endian, što znači da su značajniji bajtovi prvi u poretku. 16

Slika 3.2 SSL može kombinirati poruke sa TCP segmentima Slika 3.3 Record Layer pakira poruke svih protokola Polja koja su sadržana u Record Layer-u: Protokol (1 bajt) označava koji protokol više razine je sadržan u poruci; Verzija (2 bajta) najmanja i najveća verzija SSL-a kojoj poruka odgovara; Duljina (2 bajta) duljina poruke koja slijedi. To je poruka protokola sa višeg nivoa. Duljina se označava kao 16-bitni broj. SSL specifikacija zahtjeva da ovaj broj nije veći od 2 14 tj. 16384; 17

Poruke protokola (n bajtova) sadrži do 2 14 (16834) bajta poruke ili više poruka protokola sa višeg nivoa, uključujući i autentifikaciju poruke. Record Layer može spojiti više poruka s višeg nivoa u jednu, no sve te poruke moraju pripadati istom protokolu s više razine. Uvjet da bi ovo radilo je mogućnost svakog protokola više razine da bude samoodrediv. SSL specifikacija definira četiri protokola višeg nivoa koje Record Layer može zapakirati. Sa poljem protokol se označava koji od četiri protokola je upakiran. Tablica 3.1 Tipovi protokola Vrijednost Protokol 20 ChangeCipherSpec 21 Alert 22 Handshake 23 Application 3.2. Protokol izmjene sigurnosnih postavki Protokol ChangeCipherSpec je najjednostavniji protokol od četiri koja sadrži SSL. Sastoji se od samo jedne poruke. To je ChangeCipherSpec poruka opisana u prethodnom poglavlju. Iako je jednostavan, SSL ga koristi kao samostalni protokol. Isprva bi se moglo učiniti da je ovo pretjerivanje, i zašto ga ne bi samo uključili unutar protokola Handshake. No ako malo pažljivije pogledamo, vidjet ćemo da ChangeCipherSpec mora biti poseban protokol, inače SSL ne bi ispravno funkcionirao. Razlog je to što SSL primjenjuje sigurnosne servise kao što je enkripcija na sve Record Layer poruke odjednom. ChangeCipherSpec poruka kazuje da se od nje nadalje prelazi na sigurnosne postavke koje su dogovorne, pa ako bi ona bila sa ostalim porukama unutar jedne Record Layer poruke na ostale poruke koje ju slijede bilo bi nemoguće primijeniti sigurnosne servise. Zato je najjednostavnije rješenje ChangeCipherSpec definirati kao zaseban protokol. Sama ChangeCipherSpec poruka je vrlo jednostavna. Na slici 3.4 je prikazana poruka koja je upakirana u Record Layer poruku. Slika 3.4. ChangeCipherSpec poruka je vrlo jednostavna 18

3.3. Protokol uzbune Sustavi koriste protokol uzbune (engl. Alert) kako bi signalizirali pogrešku ili upozorenje drugoj strani tijekom komunikacije. Ova funkcija je dovoljno važna kako bi je stavili u poseban protokol. Za formatiranje Alert poruka koristi se Record Layer. Protokol Alert definira dva polja. To su nivo opasnosti (engl. severity level) i opis uzbune. 3.3.1. Nivo opasnosti Slika 3.5 Alert poruka ima samo dva polja Ovim poljem se predočava razina ozbiljnosti problema koji je uzrokovao pojavu uzbune. Uzbuna može biti upozorenje (nivo opasnosti 1) ili pogubna (nivo opasnosti 2). Pogubna uzbuna predstavlja ozbiljan problem i zahtjeva prekid sjednice od obadvije strane. Upozorenja nisu toliko opasna. Sustav koji primi upozorenje može odlučiti želi li nastaviti trenutnu sjednicu, no ta sjednica se ne može ponovo otvoriti nakon nekog vremena. 3.3.2. Opis uzbune Drugo polje Alert poruke opisuje specifičnu grešku detaljnije. To polje se sastoji od jednog bajta, a može poprimiti jednu od vrijednosti koje se nalaze u sljedećoj tablici. Tablica 3.2 Opisi Alert protokola Vrijednost Naziv Značenje 0 CloseNotify Pošiljatelj eksplicitno naznačava da zatvara konekciju 10 UnexpectedMessage Pošiljatelj javlja da je primio nepravilnu poruku; ovakvo upozorenje je uvijek pogubno 20 BadRecord MAC Pošiljatelj javlja da je primio poruku za kojoj je krivi autentifikacijski kod poruke (MAC); ovakvo upozorenje je uvijek pogubno 30 DecompresionFailure Pošiljatelj javlja da je primio poruku koju nije mogao otpakirati; ovakvo upozorenje je uvijek pogubno 40 41 HandshakeFailure NoCertificate Pošiljatelj javlja da nije mogao dovršiti postupak pregovora oko sigurnosnih postavki za sjednicu; ovakvo upozorenje je uvijek pogubno Pošiljatelj, koji je u ovom slučaju uvijek klijent, javlja da nema odgovarajući certifikat koji bi vratio kao odgovor na poslužiteljevu CertificateRequest poruku 42 BadCerificate Pošiljatelj je primio certifikat koji je kompromitiran (npr. potpis ne može biti verificiran) 43 UnsupportedCerificate Pošiljatelj je primio certifikat čiji tip ne podržava 19

44 CertificateRevoked Pošiljatelj je primi certifikat koji je certifikacijsko tijelo opozvalo 45 CertificateExpired Pošiljatelj je primio certifikat koji je istekao 46 47 CertificateUnknown IllegalParameter Pošiljatelj javlja da ima ne specificiranih problema sa certifikatom koji je primio Pošiljatelj javlja da je primio poruku tijekom dogovora oko sigurnosnih postavki koja ima parametre koji su nepravilni ili nisu konzistentni s ostalim primljenim parametrima 3.4. Protokol rukovanja Većina SSL specifikacija predstavlja protokol rukovanja (engl. Handshake) kao najvažniji u procesu pregovora oko SSL postavki. Record Layer pakira Handshake poruke u svoje okvire, a može se što je često i praksa, upakirati više Handshake poruka u jednu Record Layer poruku. Svaka Handshake poruka počinje sa bajtom kojim se definira vrsta poruke. Nakon toga slijede 3 bajta kojima se definira duljina tijela Handshake poruke. Duljina se izražava u bajtovima, i u nju nisu uračunati tip poruke i polje koje označava duljinu poruke. 3.4.1. Zahtjev za pozdravom Pomoću HelloRequest poruke poslužitelj od klijenta traži da ponovo počnu pregovore oko SSL postavki. Ova se poruka ne koristi često, no daje poslužitelju dodatne opcije. Ako se neka konekcija koristi dosta dugo da je sigurnost neprihvatljivo narušena, poslužitelj može sa HelloRequest porukom od klijenta zatražiti da dogovore nove sigurnosne postavke ili nove ključeve. Sama poruka je vrlo jednostavna, što se može vidjeti i na slici 3.6. Tip Handshake poruke je 0, a pošto je tijelo poruke prazno, ima vrijednost 0, onda je i duljina poruke 0. 3.4.2. Pozdravna poruka klijenta Slika 3.6. HelloRequest poruka Uobičajeno se ovom porukom započinje pregovor oko postavki. Na slici 3.7 je prikazan format poruke. Vrsta poruke je označena vrijednošću 1. Veličina tijela poruke je promjenjive veličine i nalazi se nakon vrste poruke. Sljedeća dva bajta definiraju verziju SSL protokola. Treba primijetiti da i unutar Record Layer poruke također imamo verziju SSL protokola i 20

da su te dvije vrijednosti uglavnom iste. Postoji mogućnost u teoriji da se protokol Record Layer i protokol Handshake razvijaju neovisno. Poslije verzije protokola umeće se 32-bajtni slučajni broj. SSL specifikacija predlaže da se koriste trenutni datum i vrijeme, do vrijednosti sekunde, na mjestu prva četiri bajta. Tako oblikovan broj smanjuje vjerojatnost pojave istih slučajnih brojeva koji bi mogli kompromitirati sigurnost. Slika 3.7 ClientHello poruka Zatim slijedi bajt koji sadrži duljinu, izraženu u bajtovima, identifikatora sjednice, a potom i identifikator sjednice. Ukoliko klijent ne želi nastaviti neku prijašnju sjednicu izostavlja identifikator, a duljina identifikatora je 0. SSL ograničava duljinu identifikatora sjednice na 32 bajta ili manje, ali ne postavlja ograničenja na sadržaj identifikatora. Pošto se identifikator sjednice prenosi u ClientHello poruci, znači prije nego je upotrijebljena ikakva enkripcija, treba se paziti da se u identifikatoru ne prenose nikakve važne informacije niti informacije koje bi mogle ugroziti sigurnost. Potom se navodi lista enkripcijskih alata koje klijent podržava. Lista počinje bajtom koji označava veličinu liste. Duljina je izražena u bajtovima. Za svaki algoritam koji je predložen u listi rezervirana su dva bajta, tako da ako je predloženo deset algoritama duljina je 20 bajtova. U tablici 3.3 prikazani su kriptografski paketi podržani u SSL-u 3.0. Tablica 3.3 SSL kriptografski paketi Vrijednost Kriptografski paket 0,0 SSL_NULL_WITH_NULL_NULL 0,1 SSL_RSA_WITH_NULL_MD5 0,2 SSL_RSA_WITH_NULL_SHA 0,3 SSL_RSA_EXPORT_WITH_RC4_40_MD5 21

0,4 SSL_RSA_WITH_RC4_128_MD5 0,5 SSL_RSA_WITH_RC4_128_SHA 0,6 SSL_RSA_EXPORT_WITH_RC3_CBC_40_MD5 0,7 SSL_RSA_WITH_IDEA_CBC_SHA 0,8 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 0,9 SSL_RSA_WITH_DES_CBC_SHA 0,10 SSL_RSA_WITH_3DES_EDE_CBC_SHA 0,11 SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA 0,12 SSL_DH_DSS_WITH_DES_CBC_SHA 0,13 SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA 0,14 SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA 0,15 SSL_DH_RSA_WITH_DES_CBC_SHA 0,16 SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA 0,17 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 0,18 SSL_DHE_DSS_WITH_DES_CBC_SHA 0,19 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0,20 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 0,21 SSL_DHE_RSA_WITH_DES_CBC_SHA 0,22 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0,23 SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 0,24 SSL_DH_anon_WITH_RC4_128_MD5 0,25 SSL_DH_annon_EXPORT_WITH_DES40_CBC_SHA 0,26 SSL_DH_anon_WITH_DES_CBC_SHA 0,27 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA 0,28 SSL_FORTEZZA_DMS_WITH_NULL_SHA 0,29 SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA 0,30 SSL_FORTEZZA_DMS_WITH_RC4_128_SHA Zadnja polja u ClientHello poruci odnose se na listu metoda za kompresiju koje predlaže klijent. I ova lista započinje bajtom koji predstavlja duljinu liste. Ovdje je, za razliku od liste enkripcijskih alata, svaka metoda predstavljena jednim bajtom, pa duljina ujedno predstavlja i broj predloženih metoda. Ako je duljina postavljena na 1, a sljedeći bajt je 0, znači da nije predložena nikakva kompresijska metoda. 22

3.4.3. Pozdravna poruka poslužitelja ServerHello poruka uvelike nalikuje ClientHello poruci. Jedine bitne razlike su vrijednost tipa poruke, koja je ovdje dva umjesto jedan što je slučaj kod ClientHello poruke, i činjenica da poslužitelj odabire samo po jedan enkripcijski algoritam i kompresijsku metodu iz cijele liste ponuđenih od strane klijenta. Slika 3.8 ServerHello poruka Poslužitelj može uključiti i identifikator sjednice u poruku. U tom slučaju, daje klijentu mogućnost da u budućnosti pokuša ponovo uspostaviti istu sjednicu. Ukoliko ne želi omogućiti klijentu takvo nešto, jednostavno izostavi polje identifikatora postavljajući duljinu identifikatora na 0. 3.4.4. Poruka koja sadrži certifikat Certificate poruka počinje poljem koje označava vrstu poruke, koja je u ovom slučaju 11. Zatim slijedi duljina tijela poruke. Tijelo poruke sadrži niz certifikata. Niz počinje sa 3 bajta koji označavaju duljinu niza certifikata. Duljina niza je uvijek za 3 manja od duljine tijela poruke. Prije svakog certifikata nalazi se 3 bajtno polje koje označava duljinu certifikata koji slijedi. SSL dopušta da niz certifikata bude hijerarhijski. Prvi u nizu uvijek mora biti pošiljateljev. Nakon njega slijedi certifikat certifikacijskog tijela koje je izdalo certifikat pošiljatelju. Zatim, ako postoji još certifikata, certifikat tijela koje je izdalo prethodni certifikat itd. Niz se nastavlja dok ne dođe do certifikata koji je izdalo root certifikacijsko tijelo. 23

Slika 3.9. Certificate poruka 3.4.5. Poslužiteljeva poruka razmjene ključa Ova poruka prenosi javni ključ poslužitelja prema klijentu. Točan format poruke ovisi o kriptografskom algoritmu koji se koristi za razmjenu. Na slikama 3.10, 3.11 i 3.12 prikazani su formati poruka koji koriste Diffie-Hellman, RSA, Fortezza algoritme za razmjenu ključeva. Neovisno o načinu razmjene, tip poruke je 12. Na slici 3.10 se vidi da u poruci nigdje nije navedeno koji se protokol koristi. Klijent to mora znati iz poruka koje su razmijenjene ranije u procesu pregovora (ServerHello poruka). Slika 3.10 ServerKeyExchange poruka sa Diffie-Hellman parametrima Na slici 3.10 je razmjena u slučaju da će se koristiti Diffie-Hellman algoritam za razmjenu ključeva. Osim tipa i duljine poruke prenose se i Diffie-Hellman parametri (p, q, y s ). Prije same vrijednosti parametra nalazi se polje koje označava duljinu parametra. 24

Slika 3.11 ServerKeyExchange poruka sa RSA parametrima Slika 3.111 prikazuje kako izgleda poruka ukoliko će se koristiti RSA razmjena ključeva. Sastoji se od RSA modula i javnog eksponenta. Svaki od tih parametara se prenosi u poruci kao duljina iza koje slijedi vrijednost parametra. Slika 3.12 ServerKeyExchange poruka sa Fortezza parametrima Kada se ključ razmjenjuje uz pomoć Fortezza/dms postupka, u poruci se prenosi Fortezza r s parametar. Pošto je r s uvijek veličine 128 bajtova, ne treba dodatni parametar za duljinu. On je uvijek postavljen na 128. Iz slika 3.10, 3.11 i 3.12 se vidi da ServerKeyExchange poruka može sadržavati i potpisane parametre. Njihov format ovisi o algoritmu za potpisivanje koji je usvojen u prijašnjim porukama. Ukoliko autentifikacija poslužitelja nije dio poruke, znači nema potpisa, pa ServerKeyExchange poruka završava Diffie-Hellman, RSA ili Fortezza parametrima. Ako poslužitelj nije anoniman, nego je poslao Certificate poruku, onda se potpis odvija prema algoritmu koji je naveden unutar poslužiteljeva certifikata. Na slikama 3.10 i 3.11 su prikazana potpisivanja sa RSA ili DSA algoritmom, a potpisuje se SHA ili MD5 sažetak. Neovisno koji se algoritam i koja funkcija za izračunavanje sažetaka koristi, poslužitelj potpisuje sažetak i tako se autentificira. Sažetak koji se potpisuje za ulaz ima slučajni broj iz ClientHello poruke, slučajnog broja iz ServerHello poruke i javnog ključa poslužitelja koji se prenosi u ServerKeyExchange poruci, kao što je prikazano na slici 3.13Slika 3.13. 25

Slika 3.13. Poslužitelj digitalno potpisuje sažetak za ServerKeyExchange poruku 3.4.6. Zahtjev za certifikatom Kako bi autentificirao klijenta, poslužitelj prvo mora zatražiti certifikat od klijenta. Zato mu šalje CertificateRequest poruku. Ovom porukom poslužitelj ne kazuje klijentu samo da mu pošalje certifikat, nego navodi i koji su certifikati prihvatljivi poslužitelju. Ova poruka je tipa 13. poslije tipa slijedi duljina poruke. Nakon toga slijedi lista prihvatljivih tipova certifikata. Lista počinje s jednim bajtom koji predstavlja duljinu liste, za kojim slijede tipovi prihvatljivih certifikata, koji su isto duljine jednog bajta. U tablici 3.4 prikazani su svi tipovi certifikata. Slika 3.14 CertificateRequest poruka Tablica 3.4 Tipovi certifikata CT vrijednost Tip certifikata 1 RSA potpis i razmjena ključeva 2 DSA potpis 3 RSA potpis sa Diffie Hellman razmjenom ključeva 4 DSA potpis sa Diffie Hellman razmjenom ključeva 5 RSA potpis sa kratkotrajnom Diffie Hellman razmjenom ključeva 6 DSA potpis sa kratkotrajnom Diffie Hellman razmjenom ključeva 26

20 Fortezza/DMS potpis i razmjena ključeva Nakon tipova certifikata slijedi lista certifikacijskih tijela koje poslužitelj smatra prihvatljivima. Lista počinje 2-bajtnim poljem duljine liste, za kojim slijede imena certifikacijskih tijela. Svako ime ima i polje koje predstavlja njegovu duljinu. 3.4.7. Poruka kojom poslužitelj završava pozdrav Ovom porukom se završava poslužiteljev dio pregovora. Ona ne prenosi nikakve dodatne informacije. Ima vrlo jednostavan oblik prikazan na slici 3.15. Tip poruke je 20, a duljina tijela poruke je 0. Slika 3.15 ServerHelloDone poruka 3.4.8. Klijentova poruka razmjene ključa Uz pomoć ClientKeyExchange poruke klijent poslužitelju šalje podatke iz kojih će se izračunati ključ koji će se koristiti u komunikaciji. Točan format poruke ovisi o algoritmu za razmjenu ključeva, a SSL specifikacija ih dopušta 3. to se RSA, Diffie-Hellman, i Fortezza/dms. U poruci se ne vidi o kojem se algoritmu radi. Klijent i poslužitelj znaju tu informaciju iz procesa dogovora oko sigurnosnih postavki. Slika 3.16 ClientKeyExchange poruka ukoliko se koristi RSA Na slici 3.16 je prikazan format poruke ukoliko se koristi RSA algoritam za razmjenu ključeva. Tip poruke je 16, a zatim slijedi polje duljine poruke. Tijelo poruke se sastoji od kriptirane premaster secret vrijednosti. Premaster secret vrijednost je kriptirana uz pomoć javnog ključa poslužitelja. Iz premaster secret vrijednosti se dobiva master secret vrijednost za trenutnu sjednicu. Premaster secret vrijednost se sastoji od dva bajta koji predstavljaju verziju SSL-a koju klijent podržava (3 i 0, ako je verzija 3.0) i 46 sigurno generiranih slučajnih bajtova. 27

Slika 3.17 ClientKeyExchange poruka ukoliko se koristi Diffie-Hellman Ako se za razmjenu ključeva koristi Diffie-Hellman algoritam, postoje dvije mogućnosti kako ClientKeyExchange poruka može izgledati. Ako je Diffie-Hellman algoritam prolazan, onda će poruka izgledati kao na slici 3.17. U poruci je sadržana klijentova y c vrijednost kojoj prethodi polje s duljinom te vrijednosti. Ukoliko je algoritam određen, onda je y c vrijednost prenesena unutar klijentova certifikata, te je u tom slučaju ClientKeyExchange poruka prazna. Slika 3.18 ClientKeyExchange poruka ukoliko se koristi Fortezza Pomoću Fortezza/dms sustava za razmjenu ključeva poruka izgleda kao na slici 3.18 i prenosi niz parametara. Parametri su navedeni u tablici 3.5. Tablica 3.5 Fortezza/DMS ClientKeyExchange parametri Veličina Y C vrijednosti Parametar Y C vrijednost(između 64 i 128 bajta) ili ništa ako je Y C unutar klijentova certifikata Klijentova R C vrijednost Javni ključ algoritma za kriptiranje ključa, potpisan klijentovim DSS privatnim ključem Klijentov ključ za pisanje, omotan tokenovim ključem za kriptiranje (engl. TEK token encription key) Klijentov ključ za čitanje omotan tokenovim ključem za kriptiranje Veličina 2 bajta 0 128 bajtova 128 bajtova 20 bajtova 12 bajtova 12 bajtova 28

Klijentov inicijalizacijski vektor Poslužiteljev inicijalizacijski vektor Inicijalizacijski vektor glavne tajne korišten za kriptiranje premaster secret vrijednosti Premaster secret vrijednost, koja je sigurno izgenerirana slučajna vrijednost kriptirana uz pomoć tokenovog ključa za kriptiranje 24 bajta 24 bajta 24 bajta 48 bajtova 3.4.9. Potvrda certifikata Ovom porukom klijent potvrđuje da ima privatni ključ koji odgovara javnom ključu sadržanom u certifikatu kojeg je poslao. Na slici 3.19 se vidi da se poruka sastoji od sažetka koji je digitalno potpisan. Točan format ovisi o algoritmu koji se koristi za potpisivanje. Ako se koristi RSA algoritam kombiniraju se dva sažetka. To su MD5 i SHA sažeci, s tim da jedan potpis sadrži obadva sažetka. U slučaju da se koristi DSA algoritam, potpisuje se samo SHA sažetak. Slika 3.19 CertificateVerify poruka U bilo kojem od prethodno navedenih slučajeva, ulaz u funkciju za računanje sažetka je isti. Ulaz se gradi u tri koraka. Prvo se izračuna posebna vrijednost koja se naziva master secret. Za izračun te vrijednosti koristi sljedeći postupak. Slika 3.20 Izračunavanje master secret vrijednosti 29

Nakon što je izračunata master secret vrijednost, kreira se sažetak svih dosada razmijenjenih poruka. Na njega se dodaje master secret vrijednost iza koje slijedi jedno bajtna vrijednost 00110110, koja se ponavlja 48 puta ukoliko se koristi MD5, a 40 puta ukoliko SHA funkcija. U trećem koraku klijent izračunava treći sažetak koristeći ista master secret vrijednost, iza koje slijedi vrijednost 01011100 ponovljena 48 puta za MD5 ili 40 puta za SHA funkciju. Iza njih se dodaje sažetak iz međukoraka. 3.4.10. Završna poruka Slika 3.21 Potpisani sažetak svih poruka Završna poruka Handshake protokola je tipa 20. Ova poruka pokazuje da je proces pregovora oko sigurnosnih postavki završen i da se sigurnosni mehanizmi mogu početi koristiti. Sama Finished poruka je kriptirana dogovorenim sigurnosnim postavkama. Na slici 3.22 je prikazan format poruke. Slika 3.22 Finished poruka 30

Tijelo poruke se sastoji od dva sažetka, jednog dobivenog MD5 algoritmom, drugog SHA algoritmom. Ulaz u obadvije funkcije je jednak. i obadva su izračunata u dva koraka. Na slici 3.23 prikazan je proces za SHA algoritam, ali je i za MD5 sličan. Slika 3.23 Finished poruka sadrži potpisani sažetak Prvo pošiljatelj izračuna sažetak svih poruka prethodno razmijenjenih, za kojim slijedi identifikator pošiljateljeve uloge, master secret vrijednost i nadopuna. Ako je pošiljatelj klijent, identifikator uloge je 434c4e54, a ukoliko je pošiljatelj poslužitelj identifikator je 53525652. Nadopuna binarno izgleda 00110110 i ponavlja se 48 puta za MD5, a 40 puta za SHA algoritam. U drugom koraku pošiljatelj stvara novi sažetak koristeći master secret vrijednost, za kojom slijedi nadopuna i prethodno dobiveni sažetak. U drugom koraku nadopuna je 01011100 i ponavlja se 48 puta za MD5, a 40 puta za SHA algoritam. 3.5. Osiguravanje poruka Finished je prva poruka koju koja koristi sigurnosne postavke koje su dogovorene tijekom procesa pregovaranja. Sve poruke koje su poslane nakon nje koriste sigurne servise. SSL osigurava enkripciju poruka i nepromjenjivost podataka, osiguravajući tajnost i besprijekornost. 3.5.1. Autentifikacija poruke SSL protokol podržava dva algoritma kojima se vrši autentifikacija tj. kojima se izračunava autentifikacijski kod poruke (engl. MAC-Message authentication code). To su Message Digest 5 (MD5) i Secure Hash Algorithm (SHA). Koji će se algoritam koristiti ovisi o dogovoru između klijenta i poslužitelja. Osim načina izračuna sažetka, razlika između ova dva algoritma je i veličina sažetka kojeg daju. MD5 algoritam proizvodi 16 bajtni sažetak, dok SHA proizvodi 20 bajtni sažetak. Sažetak poruke se dodaje na podatke aplikacije, a u Record Layer okviru u polju duljine se označava duljina poruke i sažetka skupa. Iz slika 3.24 i 3.25 se vidi da su kriptirani i podaci i sažetak. 31

Slika 3.24 MAC dobiven MD5 algoritmom Slika 3.25 MAC dobiven SHA algoritmom Za izračun MAC-a sustav koristi algoritam za izračun sažetka vrlo sličan algoritmu iz protokola Handshake. Počinje sa posebnom vrijednosti koja se zove mac write secret, iza koje slijedi nadopuna, 64 bitni slijedni broj, 16 bitna vrijednost duljine sadržaja i zatim sam sadržaj. Nadopuna je vrijednost 00110110 ponovljena 48 puta za MD5 algoritam ili 40 puta za SHA algoritam. U drugom koraku se koristi mac write secret vrijednost, nadopunu i sažetak dobiven u prethodnom koraku. Ovaj put je nadopuna 01011100 ponovljena 48 puta za MD5 i 40 puta za SHA. Krajnji rezultat je MAC vrijednost koja se pojavljuje na kraju poruke. Dvije posebne vrijednosti koje se koriste u izračunu su mac write secret i slijedni broj. Mac write secret vrijednost će biti objašnjena dalje u tekstu, dok je slijedni broj broj poruka koje su strane izmijenile. Vrijednost mu se postavlja na 0 svaki put kad je poslana ChangeCipherSpec poruka, a povećava se svaki put kad je poslana Record Layer poruka. 32

3.5.2. Kriptiranje Slika 3.26 Izračun autentifikacijskog koda poruke SSL podržava blokovsko kriptiranje i kriptiranje toka podataka. Ovisno koju vrstu kriptiranja koristimo razlikuju se formati poruka. Na slici 3.27Slika 3.27 se vidi da su kod kriptiranja toka podataka aplikacijski podaci i MAC kriptirani i da nikakvi dodatni podaci nisu potrebni. Slika 3.27 SSL može koristiti kriptiranje toka podataka za zaštitu aplikacijskih podataka Kod blokovskog kriptiranja, podaci koji će se kriptirati moraju biti višekratnik veličine bloka. Pošto veličina podataka aplikacijskog protokola rijetko kad bude višekratnik veličine bloka podataka, potrebno je nadopuniti poruku. Kako bi postojala razlika između podataka i nadopune korisnik mora znati gdje završavaju podaci, a počinje nadopuna. Zbog toga je će format poruke koja koristi blokovsko kriptiranje biti kao na slici 3.28. Zadnji bajt poruke predstavlja duljinu nadopune. Nakon dekripcije poruke pročita se zadnji bajt, i uzme onoliko zadnjih bajtova kolika je dobivena vrijednost. To što smo pročitali je nadopuna, a ostatak je poruka i MAC. 33

Slika 3.28 Blokovsko kriptiranje podataka 3.6. Kreiranje kriptografskih parametara Algoritmi kriptiranja i izračunavanja sažetaka se temelje na skupini tajnih podataka poznatih samo stranama koje komuniciraju. Razmjena tih informacija na siguran način, jedna je od tri glavne stvari za koje služi protokol Handshake. Ostale dvije su autentifikacija sudionika i razmjena sigurnosnih postavki. Početna točka za izračunavanje svih dijeljenih tajnih informacija je master secret vrijednost. Master secret vrijednost se temelji na premaster secret vrijednosti. U većini slučajeva, klijent nasumično odabere premaster secret vrijednost tako što izgenerira siguran slučajan broj. Zatim kriptira taj broj poslužiteljevim javnim ključem, i pošalje mu ga u ClientKeyExchange poruci (ako koristimo Diffie-Hellman algoritam, rezultat tog algoritma se koristi kao premaster secret vrijednost). Kad poslužitelj primi poruku, oba sudionika znaju premaster secret vrijednost. Nakon toga premaster secret vrijednost i slučajni broj iz ServerHello i ClientHello poruka su ulaz u algoritam za računanje sažetka poruke. Nakon kombiniranja sažetaka u određenom poretku, obje strane imaju izračunatu master secret vrijednost. U tablicama 3.6 i 3.7 prikazani su postupci za izračun premaster i master secret vrijednosti. Tablica 3.6 Stvaranje premaster secret vrijednosti Razmjena ključeva RSA Fortezza/DMS Diffie-Hellman Akcija Klijent generira premaster secret vrijednost kao dva bajta koja sadrže SSL verziju (binarno 3 i 0), iza kojih slijedi 46 bajtova sigurno generiranih slučajnih bajtova Klijent generira premaster secret vrijednost kao 48 sigurno generiranih slučajnih bajtova Ključ generiran Diffie-Hellman algoritmom koristi se kao premaster secret vrijednost 34

Tablica 3.7 Izračun master secret vrijednosti Korak Akcija 1 Počinje se sa 48-bajtnom premaster secret vrijednosti. Klijent stvara ovu vrijednost i šalje je poslužitelju unutar ClientKeyExchange poruke 2 Računa se SHA sažetak ASCII znaka A iza kojeg slijedi premaster secret vrijednost, klijentova slučajna vrijednost (iz ClientHello poruke) i poslužiteljeva slučajna vrijednost (iz ServerHello poruke) 3 Računa se MD5 sažetak premaster secret vrijednosti iza koje slijedi vrijednost dobivena na izlazu drugog koraka 4 Računa se SHA sažetak ascii znakova BB, premaster secret vrijednosti, klijentove slučajne vrijednosti (iz ClientHello poruke) i poslužiteljeve slučajne vrijednosti (iz ServerHello poruke) 5 Računa se MD5 sažetak premaster secret vrijednosti iza koje slijedi vrijednost dobivena na izlazu četvrtog koraka 6 Konkateniraju se rezultati petog i trećeg koraka 7 Računa se SHA sažetak ascii znakova CCC iza kojih slijedi premaster secret vrijednost, klijentova slučajna vrijednost (iz ClientHello poruke) i poslužiteljeva slučajna vrijednost (iz ServerHello poruke) 8 Računa se MD5 sažetak premaster secret vrijednosti iza koje slijedi vrijednost dobivena na izlazu sedmog koraka 9 Konkateniraju se rezultati osmog i šestog koraka Na slici 3.29 grafički je prikazan izračun master secret vrijednosti dok je na slici 3.30 to isto prikazano u obliku jednadžbe. Slika 3.29 Grafički prikaz izračuna Master secret vrijednosti 35

Slika 3.30 Izračun Master secret vrijednosti Nakon što su obje strane izračunale master secret vrijednost, spremne su za generiranje tajnih informacija koje će se koristiti u komunikaciji. Prvi korak je određivanje koliko nam informacija treba. Broj ovisi o algoritmima koji će se koristiti, ali se uglavnom koriste informacije iz tablice 3.8. Tablica 3.8 Dijeljena tajna informacija Parametar Klijentova MAC tajna Poslužiteljeva MAC tajna Klijentov ključ Poslužiteljev ključ Klijentov inicijalizacijski vektor Poslužiteljev inicijalizacijski vektor Tajna informacija Tajna vrijednost uključena u MAC za poruke generirane od strane klijenta Tajna vrijednost uključena u MAC za poruke generirane od strane poslužitelja Tajni ključ za kriptiranje poruka klijenta Tajni ključ za kriptiranje poruka poslužitelja Inicijalizacijski vektor za postupak kriptiranja klijenta Inicijalizacijski vektor za postupak kriptiranja poslužitelja Za izračun tajne informacije obje strane korite proces prikazan na slici 3.31. Prvo izračunaju SHA sažetak ascii znaka 'A', iza kojeg slijedi master secret vrijednost, slučajan poslužiteljev broj i slučajan klijentov broj. Zatim se računa MD5 sažetak master secret vrijednosti iza koje slijedi prethodno dobiveni sažetak. Ako tako dobiveni 16 bajtni sažetak nije dovoljan za ključ, postupak se ponavlja, samo se sad umjesto znaka 'A' koristi 'BB'. Ponavlja se dok se ne dobije dovoljno informacija s tim da svaki put se mijenjaju ascii znakovi (poslije 'BB' ide 'CCC', zatim 'DDDD' itd.). 36

Slikom 3.32 prikazan je prethodni postupak. Slika 3.31. Izračun podataka za ključ Slika 3.32 Jednadžba za izračun podataka za ključ Nakon što je izračunata tajna informacija iz nje se dobivaju informacije koje su navedene u tablici 3.8. na način prikazan na slici 3.33. Slika 3.33 SSL uzima tajne informacije iz podataka za ključ 37