DIPLOMSKI RAD br. 1749 - Hrvatska znanstvena bibliografija · Although it is considered that these protocols are safe, this thesis will show that this is not ... jer verzija 2.0 pruža

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.7. AUTENTIFIKACIJA KLIJENTA ............................................................................................................... 12

2.7.1. Zahtjeva za certifikatom ................................................................................................................ 13


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.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.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

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.

2

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.

3

2.3. Uspostava kriptirane komunikacije

Osnovna zadaća SSL-a je omogućavanje klijentu i poslužitelju uspostavu kanala za kriptiranu komunikaciju.

Slika 2.1 Uspostava sigurne komunikacije

Opis postupka:

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.

4

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.

5

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.

6

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

7

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

8

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.

9

Slika 2.3 Završetak sigurne komunikacije

2.5. Autentifikacija poslužitelja

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

10

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.


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.

11

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.

Slika 2.5 Razdvajanje autentifikacije i enkripcije

Koraci u uspostavi konekcije:




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;



12


8. klijent šalje Finished poruku javljajući poslužitelju novo aktivirane postavke;




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.


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:




4. poslužitelj šalje CertificateRequest poruku kojom kazuje da želi autentificirati klijenta;


6. klijent šalje svoj certifikat koji sadrži javni ključ u Certifikate poruci;


13

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č;


10. klijent šalje Finished poruku da javi serveru novo aktivirane 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

14

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.


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;


15

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.

16

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.

17

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 214 tj. 16384;

18

• Poruke protokola (n bajtova) – sadrži do 214 (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

19

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.

Slika 3.5 Alert poruka ima samo dva polja

3.3.1. Nivo opasnosti

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 HandshakeFailure Pošiljatelj javlja da nije mogao dovršiti postupak pregovora oko

sigurnosnih postavki za sjednicu; ovakvo upozorenje je uvijek pogubno

41 NoCertificate 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

20

44 CertificateRevoked Pošiljatelj je primi certifikat koji je certifikacijsko tijelo opozvalo

45 CertificateExpired Pošiljatelj je primio certifikat koji je istekao

46 CertificateUnknown Pošiljatelj javlja da ima ne specificiranih problema sa certifikatom

koji je primio

47 IllegalParameter 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.

Slika 3.6. HelloRequest poruka

3.4.2. Pozdravna poruka klijenta

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

21

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

22

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.

23

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.


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.

24

Slika 3.9. Certificate poruka


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, ys). Prije same vrijednosti parametra nalazi se polje koje označava duljinu parametra.

25

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 rs parametar. Pošto je rs 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.

26

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

27

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


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.

28

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 yc vrijednost kojoj prethodi polje s duljinom te vrijednosti. Ukoliko je algoritam određen, onda je yc 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

Parametar Veličina

Veličina YC vrijednosti 2 bajta

YC vrijednost(između 64 i 128 bajta) ili ništa ako je YC unutar klijentova certifikata

0 – 128 bajtova

Klijentova RC vrijednost 128 bajtova

Javni ključ algoritma za kriptiranje ključa, potpisan klijentovim DSS privatnim ključem

20 bajtova

Klijentov ključ za pisanje, omotan tokenovim ključem za kriptiranje (engl. TEK – token encription key)

12 bajtova

Klijentov ključ za čitanje omotan tokenovim ključem za kriptiranje

12 bajtova

29

Klijentov inicijalizacijski vektor 24 bajta

Poslužiteljev inicijalizacijski vektor 24 bajta

Inicijalizacijski vektor glavne tajne korišten za kriptiranje premaster secret vrijednosti

24 bajta

Premaster secret vrijednost, koja je sigurno izgenerirana slučajna vrijednost kriptirana uz pomoć tokenovog ključa za kriptiranje

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

30

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.

Slika 3.21 Potpisani sažetak svih poruka

3.4.10. Završna 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

31

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.

32

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.

33

Slika 3.26 Izračun autentifikacijskog koda poruke

3.5.2. Kriptiranje

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.

34

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 Akcija

RSA 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

Fortezza/DMS Klijent generira premaster secret vrijednost kao 48 sigurno generiranih slučajnih bajtova

Diffie-Hellman Ključ generiran Diffie-Hellman algoritmom koristi se kao premaster secret vrijednost

35

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

36

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 Tajna informacija

Klijentova MAC tajna Tajna vrijednost uključena u MAC za poruke generirane od strane klijenta

Poslužiteljeva MAC tajna Tajna vrijednost uključena u MAC za poruke generirane od strane poslužitelja

Klijentov ključ Tajni ključ za kriptiranje poruka klijenta

Poslužiteljev ključ Tajni ključ za kriptiranje poruka poslužitelja

Klijentov inicijalizacijski vektor Inicijalizacijski vektor za postupak kriptiranja klijenta

Poslužiteljev inicijalizacijski vektor 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.).

37

Slika 3.31. Izračun podataka za ključ

Slikom 3.32 prikazan je prethodni postupak.

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č

38

3.7. Kriptografski paketi

SSL verzija 3.0 specificira 31 različit enkripcijski paket, koji su predstavljeni različitim algoritmima i parametrima. U Tablica 3.9 3.9 su navedeni svi paketi. Prva tri stupca spojena predstavljaju službeno SSL ime paketa.

Tablica 3.9 Kriptografski paketi

Razmjena ključeva Kriptiranje Sažetak

SSL_NULL_ WITH_NULL_ NULL

SSL_RSA_ WITH_NULL_ MD5

SSL_RSA_ WITH_NULL_ SHA

SSL_RSA_ EXPORT_ WITH_RC4_40_ MD5

SSL_RSA_ WITH_RC4_128_ MD5

SSL_RSA_ WITH_RC4_128_ SHA

SSL_RSA_ EXPORT_ WITH_RC2_CBC_40_ MD5

SSL_RSA_ WITH_IDEA_CBC_ SHA

SSL_RSA_EXPORT_ WITH_DES40_CBC_ SHA

SSL_RSA_ WITH_DES_CBC SHA

SSL_RSA_ WITH_3DES_EDE_CBC_ SHA

SSL_DH_DSS_ EXPORT_ WITH_DES40_CBC_ SHA

SSL_DH_DSS_ WITH_DES_CBC SHA

SSL_DH_DSS_ WITH_3DES_EDE_CBC_ SHA

SSL_DH_RSA_ EXPORT_ WITH_DES40_CBC_ SHA

SSL_DH_RSA_ WITH_DES_CBC SHA

SSL_DH_RSA_ WITH_3DES_EDE_CBC_ SHA

SSL_DHE_DSS_EXPORT WITH_DES40_CBC_ SHA

SSL_DHE_DSS_ WITH_DES_CBC SHA

SSL_DHE_DSS_ WITH_3DES_EDE_CBC_ SHA

SSL_DHE_RSA_EXPORT WITH_DES40_CBC_ SHA

SSL_DHE_RSA_ WITH_DES_CBC SHA

SSL_DHE_RSA_ WITH_3DES_EDE_CBC_ SHA

SSL_DH_anon_EXPORT_ WITH_RC4_40_ MD5

SSL_DH_anon_ WITH_RC4_128_ MD5

SSL_DH_anon_EXPORT WITH_DES40_CBC_ SHA

SSL_DH_anon_ WITH_DES_CBC SHA

SSL_DH_anon_ WITH_3DES_EDE_CBC_ SHA

SSL_FORTEZZA_DMS_ WITH_NULL_ SHA

SSL_FORTEZZA_DMS_ WITH_FORTEZZA_CBC_ SHA

SSL_FORTEZZA_DMS_ WITH_RC4_128_ SHA

39

3.7.1. Algoritmi za razmjenu ključeva

SSL podržava 14 različitih algoritama za razmjenu ključeva uključujući i njihove varijacije. U tablici 3.10 su navedeni svi.

Tablica 3.10 Podržani algoritmi za razmjenu ključeva

Algoritam Opis Granična veličina ključa

DHE_DSS Kratkotrajni Diffie-Hellmann sa DSS potpisom

nema

DHE_DSS_EXPORT Kratkotrajni Diffie-Hellmann sa DSS potpisom

DH: 512 bitova

DHE_RSA Kratkotrajni Diffie-Hellman sa RSA potpisom

nema

DHE_RSA_EXPORT Kratkotrajni Diffie-Hellman sa RSA potpisom

DH:512 bitova

RSA: nema

DH_anon Anonimni Diffie-Hellman nema

DH_anon_EXPORT Anonimni Diffie-Hellman DH: 512 bitova

DH_DSS Diffie-Hellman sa DSS certifikatima nema

DH_DSS_EXPORT Diffie-Hellman sa DSS certifikatima DH: 512 bitova

DH_RSA Diffie-Hellman sa RSA certifikatima nema

DH_RSA_EXPORT Diffie-Hellman sa RSA certifikatima DH: 512 bitova

RSA: nema

FORTEZZA_DMS Fortezza/DMS

NULL Nema algoritma za razmjenu ključeva

RSA RSA algoritam za razmjenu ključeva Nema

RSA_EXPORT RSA algoritam za razmjenu ključeva RSA: 512 bitova

3.7.2. Kriptografski algoritmi

SSL podržava 9 različitih enkripcijskih algoritama, uključujući i varijacije. U tablici 3.11 su navedeni svi podržani.

Tablica 3.11 Podržani simetrični kriptografksi algoritmi

Algoritam Vrsta kriptiranja Veličina informacija za

stvaranje ključa

Veličina ključa Veličina IV-

a

3DES_EDE_CBC Blokovsko 24 bajta 168 bitova 8 bajtova

DES_CBC Blokovsko 8 bajtova 56 bitova 8 bajtova

40

DES40_CBC Blokovsko 5 bajtova 40 bitova 8 bajtova

FORTEZZA_CBC Blokovsko 96 bitova 20 bajtova

IDEA_CBC Blokovsko 16 bajtova 128 bitova 8 bajtova

NULL Toka podataka 0 bajtova 0 bitova

RC2_CBC_40 Blokovsko 5 bajtova 40 bitova 8 bajtova

RC4_128 Toka podataka 16 bajtova 128 bitova

RC4_40 Toka podataka 5 bajtova 40 bitova

3.7.3. Algoritmi za računanje sažetka

U tablici 3.12 su navedena tri algoritma za računanje sažetka.

Tablica 3.12 Algoritmi za računanje sažetka

Algoritam Veličina sažetka Veličina nadopune

MD5 16 bajtova 48 bajtova

NULL 0 0

SHA 20 bajtova 48 bajtova

41

4. TLS

SSL je izvorno bio proizvod tvrtke Netscape, no protokol je postao toliko značajan za funkcioniranje određenih operacija na Internetu, da je Internet Engineering Task Force (IETF), uz dopuštenje Netscape-a, preuzeo daljnji razvoj SSL standarda. IETF ga je, iz nekoliko razloga, preimenovao u TLS (engl. Transport Layer Security).

Promjene koje su se dogodile u TLS-u u odnosu na SSL 3.0 su vrlo skromne. Manje su razlike između TLS-a i SSL-a 3.0, nego između SSL-a 3.0 i 2.0. Napravljeno je par značajnih preinaka. U tablici 4.1 su navedene te promjene.

Tablica 4.1 Razlike između SSL-a i TLS-a

SSL v3.0 TLS v1.0

Verzija protokola u porukama 3.0 3.1

Tipovi poruka Alert protokola 12 23

Autentifikacija poruka Ad hoc Standard

Generacija informacija za ključ Ad hoc PRF

CertificateVerify kompleksan Jednostavan

Finished Ad hoc PRF

Osnovni kriptografski paketi Uključuje Fortezzu Nema Fortezze

4.1. TLS verzija protokola

Preimenovanjem protokola iz SSL u TLS došlo je do pojave zabune prilikom definicije verzije protokola. Trenutna verzija TLS protokola je 1.0. Ako želimo kompatibilnost sa SSL-om 3.0 onda verzija protokola u porukama mora biti veća od 3.0. Pošto TLS nije uveo neke drastične promjene u protokol, u redu je TLS označavati kao verziju 3.1. Ako će TLS dobiti neke značajnije izmjene i preći u verziju 2.0, u porukama će se to označavati kao 4.0.

4.2. Tipovi poruka protokola uzbune

TLS je u odnosu na SSL uveo znatno više poruka kojima se javljaju potencijalni i stvarni sigurnosni nedostaci. TLS definira gotovo dvostruko više različitih poruka o sigurnosnim propustima. Jedna poruka je izostavljena. To je NoCertificate poruka. Izostavljena je jer je u praksi bilo vrlo teško implementirati način kojim bi se efikasno mogla koristiti. Za takvo nešto je potreban visok stupanj sinkronizacije između Alert i Handshake protokola, koja u ostalim slučajevima nije potrebna. Ovaj nedostatak TLS nadomješta drukčijim pristupom. Ako klijent nema odgovarajući certifikat, jednostavno pošalje praznu Certificate poruku. U tablici 4.2 navedene su sve Alert poruke koje TLS podržava, a sa točkom sa strane posebno su naznačene poruke uvedene pojavom TLS-a. Precrtana je poruka koja se ne koristi u TLS-u, a koristila se kod SSL-a.

42

Tablica 4.2 Opisi TLS Alert poruka

Nove

TLS

poruke

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

● 21 DecryptionFailed Pošiljatelj javlja da nije uspjelo dekriptiranje poruke (npr. imala je neispravnu nadopunu)

● 22 RecordOverflow Pošiljatelj javlja da je nakon dekripcije ili dekompresije poruka bila veća od 214 + 2048 bajtova; ovakva poruka je uvijek pogubna

30 DecompresionFailure Pošiljatelj javlja da je primio poruku koju nije mogao otpakirati; ovakvo upozorenje je uvijek pogubno

40 HandshakeFailure Pošiljatelj javlja da nije mogao dovršiti postupak pregovora oko sigurnosnih postavki za sjednicu; ovakvo upozorenje je uvijek pogubno

41 NoCertificate 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

44 CertificateRevoked Pošiljatelj je primi certifikat koji je certifikacijsko tijelo opozvalo

45 CertificateExpired Pošiljatelj je primio certifikat koji je istekao

46 CertificateUnknown Pošiljatelj javlja da ima ne specificiranih problema sa certifikatom koji je primio

47 IllegalParameter

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

● 48 UnknownCA Pošiljatelj javlja da ne može identificirati ili da ne vjeruje certifikacijskom tijelu primljenog certifikata; ovakva poruka je uvijek pogubna

● 49 AccessDenied Pošiljatelj javlja da strana identificirana unutar

43

certifikata nema prava za nastavak pregovora; ovakva greška je uvijek pogubna

● 50 DecodeError Pošiljatelj nije mogao dekodirati poruku jer je vrijednost izvan dopuštene ili je duljina poruke neispravna; ovakva poruka je uvijek pogubna

● 51 DecryptError Pošiljatelj nije mogao obaviti dekriptiranje

● 60 ExportRestriction Pošiljatelj javlja da je opazio parametar koji nije u skladu sa američkim pravilima o izvozu kriptografskih materijala; ovakva poruka je uvijek pogubna

● 70 ProtocolVersion Pošiljatelj ne može podržati traženu verziju TLS protokola; ovakva poruka je uvijek pogubna

● 71 InsufficientSecurity Pošiljatelj, u ovom slučaju uvijek poslužitelj, zahtjeva sigurnosni paket koji je sigurniji od paketa kojeg podržava klijent; ovakva poruka je uvijek fatalna

● 80 InternalError

Pošiljatelj javlja da se javila lokalna greška na njegovom sustavu, koja je neovisna o TLS-u i onemogućava mu daljnji nastavak; ovakva poruka je uvijek pogubna. Primjer za ovakvu grešku je pogreška prilikom memorijske alokacije

● 90 UserCanceled

Pošiljatelj javlja da bi prekinuo pregovore oko sigurnosnih postavki iz razloga koji nije vezan uz zatajenje protokola; ovakva poruka je upozorenje i uobičajeno bi je trebala slijediti CloseNotify poruka

● 100 NoRenegotiation Pošiljatelj javlja da se ne može složiti sa zahtjevom za ponovne pregovore oko sigurnosnih postavki; ovakva poruka je uvijek upozorenje

4.3. Autentifikacija poruka

Ovo je još jedno područje u kojem je TLS unaprijeđen u odnosu na SSL. TLS protokol se kod autentifikacije oslanja na standard H-MAC (engl. Hashed Message Authentication Code). H-MAC je standard koji je prošao rigorozna kriptografska testiranja. Na slici 4.1 je prikazano kako H-MAC radi. Vidi se da H-MAC ne koristi niti jedan specifični algoritam za računanje sažetka, tj. može raditi sa bilo kojim kompetentnim algoritmom.

44

Slika 4.1. Hash MAC algoritam

4.4. Generiranje ključa

Zasnivajući se na H-MAC standardu, TLS definira način na koji se H-MAC koristi za generiranje pseudo slučajnog izlaza. Uzima se tajni podatak i početna inicijalna vrijednost i sigurno se generira slučajni izlaz. Na takav se način može dobiti izlaz proizvoljno velik. U tablici 4.3 su navedeni koraci postupka, a na slici 4.2 je prikazan postupak.

Tablica 4.3 Generiranje pseudo slučajnog izlaza

korak Postupak

1 Izračunati H-MAC sa ulaznim vrijednostima secret i seed

2 Izračunati H-MAC sa ulaznim vrijednostima secret i izlazom iz prethodnog koraka; rezultat je prvi dio pseudo slučajnog izlaza

3 Izračunati H-MAC sa ulaznim vrijednostima secret i izlazom iz prethodnog koraka; rezultat je sljedeći dio pseudo slučajnog izlaza

4 Ponoviti treći korak koliko god je puta potrebno kako bi dobili dovoljnu količinu podataka

45

Slika 4.2 TLS koristi H-MAC za generiranje pseudo slučajnog izlaza

TLS za generiranje ključa koristi pseudo slučajnu funkciju koja se naziva PRF. PRF kombinira dva različita algoritma za dobivanje izlaza. Jedan je MD5 drugi SHA. Oba algoritma se koriste u slučaju da se jedan pokaže kao nesiguran.

Na slici 4.3 je prikazan PRF. Proces započinje secret vrijednošću, seed vrijednošću i labelom. Zatim se secret vrijednost podijeli na dva dijela. Ukoliko se sastoji od neparnog broja bajtova, srednji bajt se pridružuje i lijevoj i desnoj strani. Generira se pseudo slučajan izlaz, koristeći prvu polovicu informacije i kombinaciju labele i seed vrijednosti, MD5 algoritmom.

Također se generira pseudo slučajna vrijednost SHA algoritmom iz drugog dijela tajne informacije i kombinacije labele i seed vrijednosti. Nakon toga se provede XOR operacija nad rezultatima prethodne dva rezultata.

Pošto MD5 daje 16 bajtova kao rezultat, a SHA 20 bajtova, broj iteracija za dobivanje sažetka MD5 i SHA algoritmom će biti različit.

46

Slika 4.3 TLS pseudo slučajna funkcija koristi i SHA i MD5

Sada se može opisati način na koji se dobiva ključ. Princip je jednak kao i kod SSL-a. Prvo se uzme premaster secret vrijednost, zatim se dobije master secret vrijednost i onda iz toga ključ. Kako bi se dobio ključ koristi se PRF. Ulaz u PRF je master secret vrijednost na mjestu secret vrijednosti, ascii niz „key expansion“ kao labela i spoj poslužiteljevog slučajnog broja sa klijentovim kao seed vrijednost.

Slika 4.4 TLS koristi PRF za dobivanje master secret vrijednosti i podataka za ključ

I master secret vrijednost se također dobiva pomoću PRF-a. U ovom slučaju ulazne informacije su premaster secret vrijednost kao secret vrijednost, labela je „master secret“, a seed vrijednost je spoj klijentovog slučajnog broja i poslužiteljevog.

47

4.5. Potvrda certifikata

Razlika između TLS-a i SSL-a se vidi i u CertificateVerify poruci. Kod SSL-a se proces potpisa sastoji od izračuna sažetka u dva koraka, a potpisuju se sve Handshake poruke, master secret vrijednost, i nadopuna. Kod TLS-a se potpisuju samo sve razmijenjene Handshake poruke.

4.6. Završna poruka

TLS malo pojednostavljuje sadržaj Finished poruke. U Finished poruci se prenosi 12 bajtova informacije stvorenih kao izlaz iz PRF-a, gdje je ulaz master secret vrijednost, labela „client finished“ za klijente ili „server finished“ za poslužitelje i MD5 i SHA sažetak svih Handshake poruka. Na slici 4.5 je prikazan postupak.

Slika 4.5 TLS koristi PRF za Finished poruke

4.7. Osnovni kriptografski paketi

U osnovi TLS podržava skoro sve iste kriptografske pakte kao i SSL, dok je podrška za Fortezza/dms pakete uklonjena. Broj različitih paketa će rasti kako će se razvijati i dodavati novi kriptografski paketi. Pošto IETF ima jasno definiran proces evaluacije prijedloga kriptografskih paketa, mnogo je lakše dodavati nove kod TLS-a nego što je to bilo kod SSL-a.

U tablici 4.4 navedeni su osnovni kriptografski paketi.

Tablica 4.4 Kriptografski paketi u TLS 1.0 verziji

Vrijednost Kriptografski paket

0,0 TLS_NULL_WITH_NULL_NULL

0,1 TLS_RSA_WITH_NULL_MD5

48

0,2 TLS_RSA_WITH_NULL_SHA

0,3 TLS_RSA_EXPORT_WITH_RC4_40_MD5

0,4 TLS_RSA_WITH_RC4_128_MD5

0,5 TLS_RSA_WITH_RC4_128_SHA

0,6 TLS_RSA_EXPORT_WITH_RC3_CBC_40_MD5

0,7 TLS_RSA_WITH_IDEA_CBC_SHA

0,8 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

0,9 TLS_RSA_WITH_DES_CBC_SHA

0,10 TLS_RSA_WITH_3DES_EDE_CBC_SHA

0,11 TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

0,12 TLS_DH_DSS_WITH_DES_CBC_SHA

0,13 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

0,14 TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

0,15 TLS_DH_RSA_WITH_DES_CBC_SHA

0,16 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

0,17 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

0,18 TLS_DHE_DSS_WITH_DES_CBC_SHA

0,19 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

0,20 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

0,21 TLS_DHE_RSA_WITH_DES_CBC_SHA

0,22 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

0,23 TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

0,24 TLS_DH_anon_WITH_RC4_128_MD5

0,25 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

0,26 TLS_DH_anon_WITH_DES_CBC_SHA

0,27 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

49

5. Napadi s čovjekom u sredini

Iako se najveći dio trgovanja putem Interneta obavlja putem SSL/TLS tehnologije, ta tehnologija nije u potpunosti sigurna. Veliki dio korisnika pretpostavlja da je sigurna. no većina Interneta aplikacija temeljenih na SSL/TLS tehnologiji koja koristi autentifikaciju na aplikacijskom sloju je ranjiva na nekoliko vrsta napada. Među njima je i napad sa čovjekom u sredini.

5.1. Napad s čovjekom u sredini

Napad s čovjekom u sredini je oblik narušavanja sigurnosti u kojem se napadač smjesti između dvije strane koje komuniciraju presreće ili ponovo odašilje podatke koji se razmjenjuju. Prema RFC-u 2828 napad čovjekom u sredini je napad gdje napadač presreće podatke i selektivno modificira iste, pretvarajući se da je jedna od strana koje sudjeluju u komunikaciji.

Postoje dvije vrste napada. Jedna su pasivni napadi. Takva vrsta napada se naziva prisluškivanje (engl. eavesdropping). Ovakav napad nije osobito opasan, jer kod njega može doći jedino do curenja podataka, koje nakon toga napadač, u slučaju da su zaštićeni kriptiranjem, mora dekriptirati kako bi imao koristi od njih.

Drugi oblik napada je aktivni. Takva vrsta napada je puno opasnija. Napadač se smjesti u komunikacijskom kanala između dvije strane koje komuniciraju, presreće podatke te ih mijenja.

Pretpostavimo da Ana i Branko komuniciraju. Između njih se smjesti napadač. U trenutku kada Ana šalje Branku svoj javni ključ napadač presreće poruku, a Branku dalje pošalje svoj javni ključ. Branko ne sluteći da se odvija napad uzima dobiveni ključ, za koji misli da je Anin javni ključ, te natrag šalje svoj javni ključ. Napadač opet presreće poruku, te svoj javni ključ proslijedi Ani. Ana za dobiveni ključ pretpostavlja da je Brankov i počinje komunikaciju koristeći taj ključ, ne znajući da nije Brankov. Sve daljnje poruke napadač presreće, dekriptira i po želji mijenja, a da Ana i Branko toga nisu svjesni.

Slika 5.1 MITM napad

50

U slučaju SSL/TLS-a postoje mnoge mogućnosti za izvesti napad čovjekom u sredini. Korisnik može biti preusmjeren čovjeku u sredini standardnim phishing tehnikama. Zatim se može izvršiti napad na privremeni spremnik protokola za razrješenje adresa (ARP), zavaravanje DNS-a i mnogi drugi.

U napadu čovjekom u sredini ne mora sudjelovati samo jedan napadač, nego može biti više entiteta koji sudjeluju u napadu. Jedan napadač se može nalaziti između klijenta i poslužitelja, dok drugi mogu biti locirani negdje drugdje.

Napadi čovjekom u sredini mogu imati katastrofalne posljedice. Ako tijekom autentifikacije napadač presretne autentifikacijske podatke može ih iskoristiti kako bi zavarao korisnika.

Dva glavna razloga zbog kojih su mogući napadi čovjekom u sredini u SSL/TLS okolini su naivnost krajnjih korisnika, koji slabo ili uopće ne obavljaju autentifikaciju poslužitelja i činjenica što programeri odvajaju uspostavu SSL/TLS konekcije od korisničke autentifikacije. U prvom slučaju posljedica može biti da će korisnici komunicirati sa čovjekom u sredini i tako mu otkriti svoje tajne podatke, dok će u drugom slučaju napadač imati mogućnost ponovo koristiti podatke korisnika koje je preoteo u nekom od prijašnjih napada.

Eliminiranjem bilo kojih od ova dva problema, mogli bi se riješiti problemi napada čovjekom u sredini. Za rješenje prvog problema trebalo bi se prikupiti i pohraniti certifikate poslužitelja ili napraviti klijentsku aplikaciju koja ne bi dozvoljavala klijentima letimičnu autentifikaciju poslužitelja. U drugom slučaju treba se malo modificirati autentifikacijski protokoli korišteni kod SSL/TLS-a. Pošto prvi slučaj iziskuje veće promjene, savjesnost korisnika i teže ga je za ostvariti na Internetu, promatrat će se drugi slučaj kao pokušaj rješenja napada čovjekom u sredini u SSL/TLS okružju.

5.2. Prijedlozi rješenja

Iako su napadi čovjekom u sredini potencijalno velika prijetnja sigurnosti trgovine putem Interneta temeljene na SSL/TLS tehnologiji, do sada je objavljeno jako malo radova i prijedloga rješenja nedostataka SSL/TLS-a s obzirom na te napade. Razlog tomu je ili ne shvaćanje moguće opasnosti ili krivo shvaćanje situacije. Sigurnosni analitičari često tvrde da jaka, a po mogućnosti dvo-razinska autentifikacija korisnika može riješiti problem napada čovjekom u sredini. No takav zaključak je pogrešan, posebno zato što napadi čovjekom u sredini nisu posljedica loše autentifikacije korisnika, nego su problem autentifikacije poslužitelja, tj. takvi napadi uglavnom uspijevaju jer korisnici ne provode autentifikaciju poslužitelja.

Napadač može na mnogo načina zavarati korisnika da misli kako komunicira s poslužiteljem. U najekstremnijim slučajevima napadači lažiraju cijelo grafičko sučelje klijenta. Također mogu koristiti valjane certifikate za stranice koje imaju slična imena (npr. certifikat stranice www.abc.org za stranicu www.abce.net).

Tijekom vremena osmišljavane su neke kriptografske metode kojima bi se zaštitili od napada čovjekom u sredini. Navedene su kronološki:

• Ron Rivest i Adi Shamir su predložili protokol Interlock, no on se ubrzo pokazao ranjiv kada se je koristio za autentifikaciju. Kako bi se to ispravilo trebalo je načiniti promjene koje bi jednostavan protokol pretvorile u složen protokol [8].

51

• Markus Jakobsson i Steve Myers predložili su tehniku koja se naziva zakašnjelo otkrivanje lozinke (engl. delayed password disclosure). Ova tehnika se može koristiti kao komplement autentifikaciji temeljenoj na lozinkama i protokolu za razmjenu ključeva kako bi se zaštitili od napada čovjekom u sredini [9].

• Burt Kalinski i Magnus Nystrom su predložili modul za zaštitu lozinki (engl.

password protection module – PPM) za zaštitu od napada čovjekom u sredini. To je program koji koristi sažimanje lozinke za generiranje druge lozinke koja će biti jedinstvena za dotičnog korisnika i aplikaciju [10].

Umjesto kriptografskih metoda i protokola, neki su znanstvenici predlagali korištenje više različitih komunikacijskih kanala, kao sredstvo izbjegavanja napada čovjekom u sredini. Kao posljedica toga povećan je broj aplikacija za trgovinu preko Interneta koje koriste SMS poruke kao dodatno osiguranje i pomoću njih prenose autentifikacijske kodove transakcije (engl. TAN-transaction authentication code), te zahtijevajući od korisnika da dobiveni TAN upiše u trenutku kada se logira u sustav. Ovo je primjer sustava koji koristi GSM mrežu kao drugi komunikacijski kanal. Iako bi se moglo zaključiti da smo se na ovaj način zaštitili od napada čovjekom u sredini to nije slučaj. Napadač se nalazi između klijenta i poslužitelja na jednom komunikacijskom kanalu. Kako bi poslužitelj izbjegao da napadač presretne poruku u kojoj se prenosi TAN, on koristi drugi komunikacijski kanal, koji je u ovom slučaju GSM mreža. Klijent prima SMS poruku u kojoj se nalazi TAN. Kako bi zavarao korisnika napadač će samo proslijediti TAN koji korisnik koristi u SSL/TLS sjednici.

Kako bi tehnika korištenja SMS poruka za dobivanje TAN-ova bila otporna na napade čovjekom u sredini, trebali bi uvesti TAN-ove koji su ovisni o transakcijama (engl.

transaction signing). Znači da bi za svaku poruku koju korisnik pošalje, poslužitelj vraćao SMS poruku koja sadrži TAN, ali i kratak sažetak transakcija. Zatim bi korisnik slao TAN samo u slučaju kada bi sažetak transakcija bio točan. Nedostatak ovakvoga pristupa je činjenica da je ovakav način relativno skup, ne štiti se korisnikova privatnost na prvom komunikacijskom kanalu i nije u potpunosti sigurno.

Pošto do sad navedeni predlošci rješenja nisu doveli do uspješnog suzbijanja napada čovjekom u sredini primjenjivog na SSL/TLS okružje, slijedi način koji su predložili Ralf Oppliger, Ralf Hauser i David Basin [2].

5.3. Autentifikacija ovisna o sjednici

Kako bi se osiguralo od napada čovjekom u sredini na raspolaganju su dvije opcije. Ispravno autentificirati poslužitelj ili ispreplesti korisničku autentifikaciju sa uspostavom SSL/TLS konekcije. Za prvi slučaj je zaključeno da nije pogodan, jer bi korisnik postao previše uključen u sam postupak (npr. provjera ispravnosti certifikata), a korisnici uglavnom potvrdno klikću na bilo kakve dijaloške prozore koji im se pojave, bez da pročitaju o čemu se radi. Znači da ostaje drugi slučaj. Pokušaj rješenja drugog slučaja će biti koncept nazvan korisnička autentifikacija ovisna o sjednici (engl. TLS-SA - session-aware user authentication).

Osnovna značajka TLS-SA koncepta je da autentifikacija korisnika ne ovisi samo o njegovim tajnim informacijama (lozinka, pin i sl.), nego i o podacima SSL/TLS konekcije u kojoj se te informacije prenose poslužitelju. Nit vodilja je da poslužitelj može utvrditi odgovara li SSL/TLS sjednica u kojoj poslužitelj prima podatke sjednici u kojoj je klijent poslao te podatke. Ako ti podaci odgovaraju vrlo je mala vjerojatnost da se dogodio napad čovjekom u

52

sredini. No ako se sjednice razlikuju događa se nešto neuobičajeno, a vrlo vjerojatno napad čovjekom u sredini.

Koristeći TLS-SA koncept, korisnik se autentificira koristeći autentifikacijski kod korisnika (engl. UAC - user authentication code), koji ne ovisi samo o korisnikovim tajnim informacijama, nego i o stanju SSL/TLS sjednice. UAC je kriptografski napravljen tako da ga je teško modificirati, a napadač koji ga se domogne, ne može izvršiti napad na način da ga samo ponovo pošalje. Glavna odlika UAC-a je da vrijedi za točno jednu sjednicu, te njegovo odašiljanje u bilo kojoj drugoj sjednici će jasno poslužitelju pokazati da je došlo do napada. Na slici 5.2 vidimo kako presretanje UAC-a napadaču ne pomaže jer se UAC koristi u drugoj SSL/TLS sjednici.

Slika 5.2 Korištenje UAC-a za sprečavanje MITM napada

5.4. Implementacija TLS-SA

TLS-SA nije korisnički autentifikacijski mehanizam, ali se može integrirati na mnogo različitih načina. Koristeći tehnološki pristup, određeni se autentifikacijski mehanizmi mogu učiniti ovisni o sjednici, a samim time i otporni na napade čovjekom u sredini. Na koji način će se ovisnost o sjednici implementirati ovisi o samom mehanizmu autentifikacije koji se koristi. Bit će prikazana sklopovska i programska izvedba. U sklopovskoj inačici se koriste fizički tokeni. Oni mogu imati opciju fizičkog spajanja s računalom ili ne. Pod spajanjem se misli na žičano ili bežično spajanje kao što je spajanje preko infracrvenog porta ili bluetootha. U programskoj inačici se misli na aplikaciju koja simulira rad tokena. Neovisno je li token sklopovski ili programski, može biti jedinstven korisniku (engl. Personal token) ili ne (engl.

impersonal token). Ako je token jedinstven jednom korisniku tada sadrži ključ tog korisnika i taj ključ može biti korišten za autentifikaciju korisnika. U ovom slučaju se nalazimo u području PKI (engl. public key infrastructure) sustava. Ako se radi o tokenima koji nisu jedinstveni korisniku, tada token također sadrži ključ, ali u ovom slučaju taj ključ nije korisnikov i on ne autentificira pojedinog korisnika. Korisnik se mora autentificirati na neki drugi način. Ovakvi tokeni su komercijalno zanimljiviji većinom zato što su jeftiniji i jer ne iziskuju proces registracije korisnika.

U bilo kojem slučaju privatni ključ tokena mora imati sposobnost digitalnog potpisa, pošto će se koristiti za potpisivanje klijentove CertificateVerify poruke u procesu SSL/TLS pregovora. Token može biti dosljedan kriptografskom standardu za sučelja tokena, kao što su PKCS #11 ili Microsoftovo sučelje za programiranje kriptografskih aplikacija (engl. CAPI –

53

Microsoft's Cryptographic API). Pretpostavka je da CAPI standard dolazi instaliran na svim novijim verzijama Windows operacijskih sustava i da ga može koristiti Microsoft Internet Explorer kako bi komunicirao sa tokenom. Na svim ostalim platformama se koristi neki od PKCS #11 programa za komunikaciju s tokenom.

S teorijskog gledišta preporuča se korištenje sklopovske verzije tokena, većinom zato jer su programske izvedbe podložnije napadima i manipulacijama.

5.4.1. Osnovno rješenje

U osnovnom slučaju će se sustav koji se temelji na PIN-u pokušati napraviti da bude ovisan o sjednici. Korisniku (U) ima autentifikacijski token (T) koji je opremljen malim ekranom. Korisnik će koristiti preglednik (C) za pristupanje poslužiteljskoj aplikaciji koja se temelji na SSL/TLS-u. Korisnik je identificiran pomoću identifikatora IDU i ima PINU, koji dijeli sa poslužiteljem. T je identificiran serijskim brojem (SNT), koji se može otisnuti na poleđini tokena. T također sadrži i par javni-privatni ključ (k, k-1), i tajni ključ tokena (KT) kojeg i poslužitelj zna. Ključevi k i k-1 su jednaki za sve tokene, te iz toga slijedi da tokeni nisu jedinstveni korisniku, dok je KT jedinstven za svaki token. Valja napomenuti da KT nije specifičan korisniku, pa se token ne može poistovjetiti s korisnikom, što je glavna prednost ovakvih tokena. KT se može generirati slučajnim odabirom ili se može generirati iz glavnog ključa (engl. MK - master key), koji je sadržan kod poslužitelja, po formuli:

)( TMKT SNEK = (5.1)

U slučaju kada je KT generiran slučajnim odabirom, sustav mora sve ključeve pohraniti na poslužitelju. U drugom slučaju pohrana svih ključeva nije potrebna, jer se KT računa iz SNT, pa sustav može dinamički generirati KT iz SNT i MK. Kako bi pristupio poslužitelju korisnik koristi preglednik C. C pokušava uspostaviti SSL/TLS konekciju sa poslužiteljem. Poslužitelj je podešen tako da uvijek zahtjeva autentifikaciju od klijenta slanjem CertificateRequest poruke. Na to klijent odgovara sa Certificate porukom i CertificateVerify porukom koja između ostalog sadrži i sažetak prethodno razmijenjenih poruka prilikom pregovora o SSL/TLS sigurnosnim postavkama. T generira digitalni potpis koristeći privatni ključ k-1. Pošto je token nejedinstven korisniku, a ključevi k i k-1 su jednaki kod svih tokena, CertificateVerify poruka ne autentificira ni korisnika ni token. Ovime se samo osigurava činjenica da se token koristi za uspostavu SSL/TLS sjednice sa poslužiteljem i da token ima pristup sažetku poruke. Osim što služi za osiguravanje pravilno potpisane CertificateVerify poruke, token služi i za stvaranje skraćene verzije sažetka poruke:

)(HashfNT = (5.2)

koja se prikazuje na ekranu tokena, a funkcija f može biti npr. uzimanje određenih bitova, ali takva skraćivanja sažetka znatno narušavaju sigurnost. NT bi mogao predstavljati MAC izračunat jednosmjernom funkcijom za računanje sažetka npr. H-MAC:

54

)(HashHMACNTKT =

(5.3)

U bilo kojem od ova dva slučaja NT se može skratiti na dužinu PINU-a. Ova će se vrijednost kombinirati sa PINU-om kako bi se dobio UAC koji je valjan samo za dotičnu SSL/TLS sjednicu.

),( UT PINNgUAC = (5.4)

Za funkciju g može se koristiti mnogo različitih funkcija kao što je zbrajanje modulo 10, koja je dovoljno jednostavna da je korisnik može i ručno računati. Još jedna opcija je da se znamenke PINU-a koriste za odabir pojedinih znamenaka broja NT. U slučaju da token sadrži tipkovnicu preko koje korisnik može unijeti PINU, možemo i token koristiti za računanje funkcije g koja bi u tom slučaju mogla biti znatno složenija.

Nakon što je sustav uspješno uspostavio SSL/TLS konekciju u kojoj se poslužitelj autentificirao, poslužitelj može autentificirati korisnika tražeći od njega IDU, SNT i valjani UAC za trenutnu SSL/TLS sjednicu. Korisnik ne treba uključiti SNT ukoliko tokenov certifikat za ključ k-1 sadrži ovu vrijednost. U tom slučaju S može dobiti tu vrijednost iz certifikata, ali u tom slučaju certifikat postaje jedinstven tokenu, a samim time S može dohvatiti i IDU. Poslužitelj može verificirati UAC, jer zna funkciju g i PINU, a NT može rekonstruirati jer zna sve do sad razmijenjene poruke iz kojih računa sažetak, a zna MK iz kojeg će izračunati KT. U teoriji, token može prenijeti UAC kao dio CertificateVerify poruke, te u tom slučaju token preuzima na sebe kompletnu autentifikaciju korisnika i time otklanjajući potrebu za bilo kakvi unosom podataka u web formu.

5.4.2. Sustavi zasnovani na pobudi i odzivu

Takvi sustavi autentificiraju korisnika kada prime pobudu na koju moraju poslužitelju dati odgovarajući odgovor. Sustavi zasnovani na pobudi i odzivu (engl. challenge-respone - C/R) sustavi su uglavnom implementirani sklopovski, a klijent može spojiti odgovarajući token na sustav preko kriptografski standarda PKCS #11 ili CAPI. Kako bi C/R sustavi postali ovisni o sjednici, možemo koristiti jednostavan koncept. Umjesto da poslužitelj mora klijentu poslati pobudu, i klijent i poslužitelj će slati pobudu koja će biti vrijednost izvedena iz SSL/TLS sjednice. U ovisnosti je li token spojen na sustav razlikuju se dva slučaja.

Ako je token spojen, sustav pošalje sažetak do sad razmijenjenih poruka tokenu, i onda token izračuna NT prema formulama navedenim u prijedlogu osnovnog rješenja. Nakon toga NT može biti prikazan na tokenu, pa da korisnik sam računa UAC ili može zahtijevati unos PINU-a pa da token računa UAC, što je ujedno i preporučen način. Zatim korisnik unosi UAC u web formu.

Drugi slučaj je kada token nije spojen sa sustavom i tada je situacija malo zamršenija. Pošto token nije povezan sa sustavom, mora se pronaći neki drugi način kojim bi se stanje SSL/TLS konekcije prenijelo do tokena. Najjednostavnije bi bilo kada bi prilikom pritiska na ikonu u

55

pregledniku koja prikazuje poslužiteljev certifikat, odmah bilo prikazano i stanje SSL/TLS sjednice u obliku koji bi korisnik lako kopirao.

Glavna prednost prvog slučaja je ta što osigurava jednostavnu interaktivnost korisnika i sustava i omogućava korištenje NT-a i UAC-a u punoj duljini, tako osiguravajući veću sigurnost. Nedostaci su što mora postojati sloboda priključak za token i potreba za instalacijom programa koji će komunicirati s tokenom, u slučaju da nije automatski instalirano s operacijskim sustavom.

Najveća prednost drugog slučaja je ta što ne iziskuje potrebu za spajanjem tokena, te time izbjegavajući potrebu za slobodnim priključkom i instalacijom programa, ali je mana što trebamo osigurati neki drugi način dopremanja SSL/TLS informacija od preglednika do tokena. Jedna je mogućnost da preglednik prikazuje sažetak, koji korisnik zatim unosi u token. Nedostatak ove opcije je taj što zahtjeva od korisnika da unosi veliku količinu informacije. Alternativa tome je sažimanje ili rezanje sažetka na svega nekoliko bitova. No prilikom tog postupka treba biti oprezan. Rad sa deterministički odrezanim ili smanjenim sažetkom ostavlja sustav ranjiv na sljedeće oblike napada čovjekom u sredini. Napadač čeka da klijent uspostavi prvu SSL/TLS sjednicu, zatim započinje drugu SSL/TLS sjednicu prema poslužitelju i modificira ServerHello poruku na način da su sažeci poruka prve i druge sjednice jednaki. Iz ovog razloga prilikom sažimanja ili rezanja sažetka se mora biti oprezan. Npr. umjesto rada sa cijelom vrijednošću, preglednik može pseudo slučajnim odabirom odabrati pojedine podskupove bitova kako bi formirao pobudu. Ili može izabrati određene pozicije i od tamo uzeti podskupove bitova i spojit ih kako bi oformio pobudu. Preglednik može prikazati pobudu koju korisnik unese u token, a token izgenerira odgovor. Ukoliko token koristi blokovsko kriptiranje, može koristiti svoj ključ KT kako bi kriptirao pobudu. To se odvija prema sljedećoj formuli:

),( TKNadopunaPobudaEOdziv = (5.5)

Pošto je pobuda u većini slučajeva kraća od bloka podataka koji se kriptiraju algoritmom koji koristi blokovsko kriptiranje, moramo koristiti nadopunu. Veličina bloka je važna jer se kod projektiranja sustava mora paziti na veličinu izlaza iz algoritma, pošto će taj izlaz korisnik ručno unositi u web formu. Ukoliko kao algoritam koristimo DES ili 3DES izlaz će biti veličine 64 bita. Pretpostavimo i base-32 kodiranje, gdje će svaki znak biti kodiran sa 5 bitova, trebat ćemo 13 znakova za predstavljanje izlaza. To možemo smanjiti ako ćemo koristiti base-64 kodiranje, gdje svaki znak predstavljamo sa 6 bitova, te ćemo u tom slučaju imati 11 znakova kao izlaz.

5.4.3. Sustavi zasnovani na jednokratnoj bilježnici

Za razliku od sustava zasnovanih na pobudi i odzivu, sustavi zasnovani na jednokratnoj bilježnici (engl. one time pad - OTP) ne rade s pobudama. Entitet koji se želi autentificirati daje entitetu koji autentificira OTP. Uobičajeno je da se ne odvija nikakva interakcija između klijenta i poslužitelja. Postoje tri razreda OTP sustava:

• Fizičke OTP liste koje uključuju pristupne kartice, liste TAN-ova ili liste indeksiranih TAN-ova (iTAN)

56

• Programski temeljene OTP sustavi. Primjer ovakvih lista je S/Key sustav u kojem se korisnikova lozinka kombinira sa skupom znakova i dekrementirajućim brojačem kako bi se stvorile lozinke koje se koriste samo jednom. Pošto se skup znakova ne mijenja dok brojač ne dosegne 0, postoji mogućnost pravljenja liste lozinki u naprijed.

• Sklopovski OTP sustavi. Primjer za ovakve sustave su SecurID i SecOVID. SecurID je sustav koji se sastoji od tokena kojim se vrši dvofaktorska autentifikacija korisnika na mrežni izvor. SecOVID je također sustav za autentifikaciju koji koristi jednokratne lozinke, samo što on koristi smart kartice i čitač ili token za računanje tih lozinki.

Većina OTP sustava nisu spojeni na sustav klijenta. Prednost toga je laka prenosivost tokena s jednog sustava na drugi, a druga prednost je otpornost na različite prijetnje koje bi se pojavile ukoliko bi tokeni bili spojeni na klijentov sustav. Neosobni autentifikacijski tokeni se mogu koristiti kao dopuna sklopovski temeljenim OTP sustavima u cilju dobivanja autentifikacijskog sustava koji bi bio ovisan o SSL/TLS sjednici. Ovo se temelji na činjenici da korisnik koristi OTP kao parametar funkcije h u jednadžbi:

),( OTPNhUAC T= (5.6)

Svi ostali koraci su jednaki kao u prethodno opisanim slučajevima. Glavna mana ovakvog rješenja je potreba da korisnik ima dva tokena. Jedan je OTP token, a drugi neosobni autentifikacijski token ili obadva tokena moraju biti integrirana u jedan. Prvi slučaj će teško biti komercijalno rješiv zbog potrebe za nošenjem dva tokena, dok bi drugi mogao biti rješenje, ali je problem što trenutno takvih tokena još nema na tržištu.

5.4.4. Proširenja i poboljšanja

Osnovni koncept implementacije može biti proširen na različite načine[7]. Kao primjer može se navesti korištenje Finished poruke, umjesto CertificateVerify poruke, kako bi autentifikacija korisnika bila ovisna o SSL/TLS sjednici. U tom slučaju Finished poruka bi sadržavala sažetak prethodno razmijenjenih poruka. Također umjesto simetričnog generiranja NT-a na klijentskoj i poslužiteljskoj strani, NT se može prenijeti kao dio CertificateVerify poruke. U ovom slučaju NT mora biti kriptiran javnim ključem poslužitelja, tako da je poslužitelj jedini koji može pročitati tu poruku. Prednost ovoga je da token ne mora spremati tajni ključ tokena KT, nego samo javni ključ poslužitelja. Daljnjom analizom možemo zaključiti da bi u CertificateVerify poruku mogli uključiti i UAC, kao dodatak digitalno potpisanom sažetku i kriptiranoj NT vrijednosti. U ovom slučaju autentifikacija korisnika je u potpunosti obavljena od strane tokena i korisnik ne mora ništa unositi u web formu.

Ukratko ćemo navesti moguća poboljšanja i proširenja:

• Obostrana autentifikacija

Token se može proširiti tako da podržava i poslužiteljsku autentifikaciju. U ovom slučaju token bi morao imati mogućnost prikazivanja i NT vrijednosti i autentifikacijskog koda

57

)),(( TT KHashfEA = (5.7)

gdje je f funkcija za očuvanje duljine, koja je svima poznata. NT i AT mogu biti prikazani skupa ili prvo jedna pa druga vrijednost.

• Automatsko računanje funkcije g

Prije je navedeno da funkcija g može biti relativno jednostavna, kako bi je korisnik mogao računati na pamet, no u tom slučaju je i sigurnost znatno oslabljena. Kako bi povećali sigurnost trebamo uvesti složeniju funkciju g , no u tom slučaju korisnik nije više u mogućnosti prevesti proračun. U ovom slučaju token bi trebao imati mogućnost unosa lozinke i mogao bi implementirati pseudo slučajnu funkciju PRF te generirati UAC na sljedeći način:

),( UT PINNPRFUAC = (5.8)

Glavna prednost ovakvog načina što više korisnik sam ne računa funkciju.

• Korištenje biometrije

U zadnje vrijeme vrlo popularna metoda, iako uglavnom nepotrebna, je korištenje biometrije u sustavima za autentifikaciju. Već postoje autentifikacijski tokeni koji rade na otisak prsta.

58

6. Opis praktičnog rada

U okviru praktičnog rada napravljene su animacije kojima se prikazuje rad SSL/TLS protokola i opisanih rješenja obrane od napada čovjekom u sredini. Animacije su napravljene u programskom paketu Flash CS3 i za njihovo pregledavanje je potrebno u Internet pregledniku imati instaliran Flash preglednik (engl. plug-in) ili ukoliko se animacije žele gledati na računalu, potrebno je imati samostalni Flash preglednik (engl. Flash player).

Slika 6.1 Animacija poruke

Animacije su podijeljene u nekoliko skupina. U jednoj skupini su sve poruke koje se nalaze unutar SSL/TLS protokola, te je pokazan način na koji se formiraju te poruke. Slika 6.1 prikazuje animaciju poruke ClientHello. Sastoji se od tablice koja prikazuje veličinu poruke. Svaki redak tablice je velik 32 bita, tj. podijeljen je u četiri bajta. Animacija se može gledati kao film ili skokovito (engl. Step by step). U dnu svake animacije nalazi se 5 gumbova kojima se upravlja animacijom. Slika 6.2 prikazuje primjer takvih gumbova. Zeleni gumb predstavlja reprodukciju i pokreće slijedno izvođenje animacije. Pritiskom na crveni stop gumb, animacija se zaustavlja i vraća se na početak. Narančasti gumb služi za pauziranje izvođenja animacije. Da bi se izvođenje nastavilo, potreban je klik na zeleni gumb za reprodukciju. Dva plava gumba služe za izvođenje animacije korak po korak. Jedan gumb služi za skok na slijedeći korak to drugi služi za povratak na prethodni korak.

Slika 6.2 Gumbi za upravljanje animacijom

59

Nakon što animacija dođe do kraja imena polja pretvaraju se u gumbe. Animacija je došla do kraja ukoliko sama stane kod slijednog izvođenja ili ukoliko se klikom na gumb za slijedeći korak ne mijenja ništa kod izvođenja korak po korak. Klikom na gumbe polja pokraj tablice se pojavljuje objašnjenje polja. Objašnjenja su navedena samo za polja čije značenje nije jasno iz animacije. Slika 6.3 prikazuje slučaj u kojem je kliknut gumb „Duljina krip.paketa“ i nakon toga se pojavila poruka koja objašnjava to polje poruke.

Slika 6.3 Objašnjenje polja poruke

Druga skupina se sastoji od animacija koje opisuju rad SSL/TLS protokola u različitim načinima. Ove animacije su kompliciranije od animacija poruka. Animacije protokola se sastoje od više scena. U određenim dijelovima animacije moguće je klikom na gumb prijeći u drugu animaciju. Također postoji opcija slijednog izvođenja i izvođenja korak po korak. Kod izvođenja korak po korak animacija prikazuje u svakom koraku poruku koja ide od jedne strane komunikacije do druge, strelicu koja označava smjer komunikacije. Ispod strelice se nalazi naziv poruke koja se trenutno koristi. Taj naziv je ujedno i gumb, kojim se odlazi na animaciju same poruke. Animacije poruke u ovom slučaju je jednak kao i samostalna animacija poruke, s razlikom da je ovdje dodan gumb „Nazad“ kojim se vraća na korak animacije protokola u kojem smo stisnuli gumb za animaciju poruke. Slika 6.4 prikazuje takav slučaj

60

Slika 6.4 Animacija poruke pozvana iz animacije protokola

Slika 6.5 prikazuje animaciju protokola autentifikacije poslužitelja i to korak u kojem klijent šalje poruku Finished poslužitelju. U ovom trenutku animacije donji Finished naziv je ujedno i gumb na poruku Finished.

Slika 6.5 Animacija protokola

Prilikom razmjene ClientKeyExchange i ServerKeyExchange poruka pritiskom na gumb za animaciju poruke pojavit će se izbornik na kojem se odabire koju vrstu ClientKeyExchange ili ServerKeyExchange poruke se želi prikazati. Na raspolaganju su tri vrste poruke. To su

61

poruke koje sadrže jedan os sljedećih parametara: Diffie-Hellman, Fortezza ili RSA. Slika 6.6 prikazuje takav izbornik. Nakon što se odabere jedna od vrsta poruke, klikom na gumb „Nazad“ vraća se na animaciju protokola, a ne na izbornik poruke.

Slika 6.6 Izbor ClientKeyExchange i ServerKeyExchange poruke

Na kraju svake animacije protokola prikazane su sve razmijenjene poruke i redoslijed kojim su slane. Slika 6.7 prikazuje takav slučaj.

Slika 6.7 Kraj animacije protokola

Treća vrsta animacije prikazuje predložemo rješenje borbe protiv napada čovjekom u sredini. U toj animaciji je prikazano rješenje koje koristi neosobni token. Prikazani su svi koraci osim izračuna funkcija koje su samo označene. Ova animacija isto ima mogućnost slijednog prikazivanja kao i prikazivanja korak po korak. Slika 6.8 prikazuje korak animacije predloženog rješenja.

62

Slika 6.8 Animacija predloženog rješenja

63

7. Zaključak

Sa rastućom prisutnošću Interneta u svakodnevnom životu, naglo je počela rasti i Internet trgovina, a samim time i potrebe za sigurnošću prijenosa sredstava plaćanja. SSL/TLS pružaju mogućnost uspostave sigurne komunikacije i plaćanja, no nepažnja korisnika ostavlja mjesta za razne napade, koji bi savjesnom upotrebom protokola bili značajno smanjeni. Budući je nemoguće očekivati od korisnika da se promijene i više pažnje posvete sigurnosti, na programerima je zadatak da povećaju sigurnost protokola.

Vidjeli smo da su SSL/TLS protokoli vrlo ranjivi na napade čovjekom u sredini. No iz predloženih rješenja se vidi i da postoje načini kako se uspješno braniti od njih. Također se vidi i da uvođenje takvih rješenja nije nimalo jednostavno. Potreba za dodatnim uređajima, kao što su tokeni, nadogradnja SSL/TLS protokola, postavlja pitanje ekonomske isplativosti takvih promjena. SSL/TLS protokoli u velikoj mjeri koriste za Internet bankarstvo i trgovinu preko Interneta, a banke i trgovine koje ih koriste su vođeni profitom koji ostvaruju. Iz tog razloga se može pretpostaviti da dok gubici koji su posljedica napada čovjekom u sredini, neće premašiti troškove koji su potrebne za uvođenje spomenutih rješenja, ovakva i slična rješenja borbe protiv napada čovjekom u sredini neće biti uvedena.

64

8. Literatura

[1] Stephen A. Thomas: SSL & TLS Essentials, Securing the Web, Wiley Computer Publishing, 2000.

[2] Rolf Oppliger, Ralf Hauser, David Basin: SSL/TLS Session-Aware User

Authentication, Computer, ožujak 2008., pp. 59-65.

[3] Rolf Oppliger, Ralf Hauser, David Basin, Aldo Rodenhaeuser, Bruno Kaiser: A Proof of

Concept Implementation of SSL/TLS Session-Aware User Authentication (TLS-SA), dostupno na adresi: http://www.inf.ethz.ch/personal/basin/pubs/kivs06.pdf (12.11.2008).

[4] RFC 2246, dostupno na adresi: http://www.ietf.org/rfc/rfc2246.txt (12.11.2008).

[5] Rolf Oppliger, Ralf Hauser, David Basin: SSL/TLS Session-Aware User

Authentication: A Lightweight Alternative to Client-Side Certificates, dostupno na adresi: http://people.inf.ethz.ch/basin/pubs/ssl-ieee07.pdf/ (12.11.2008).

[6] Rolf Oppliger, Ralf Hauser, David Basin: SSL/TL Session-aware user authentication

Or how to effectively thwart the man-in-the-middle, Computer Communication 29 (2006), pp. 2238-2246

[7] Rolf Oppliger, Ralf Hauser, David Basin: Browser Enhancements to Support SSL/TLS

Session-Aware User Authentication, dostupno na adresi: http://www.w3.org/2005/Security/usability-ws/papers/08-esecurity-browser-enhancements/ (12.11.2008).

[8] R.L. Rivest, A. Shamir: How to Expose an Eavesdroper, Comm.ACm, vol.27, no.4, 1984, pp. 393 – 395.

[9] Markus Jakobsson, Steve Myers: Stealth Attacks and Delayed Password Disclosure,

dostupno na adresi: http://www.informatics.indiana.edu/markus/stealth-attacks.htm (4.12.2008).

[10] RSA Security Technology Backgrounder, Enhancing One-Time Passwords for

Protection Against Real-time Phishing Attacks, dostupno na adresi: www.rsa.com/rsalabs/technotes/One-TimePWWP.pdf (4.12.2008).

Documents

DIPLOMSKI RAD br. 1749 - Hrvatska znanstvena bibliografija · Although it is considered that these protocols are safe, this thesis will show that this is not ... jer verzija 2.0 pruža