UNIVERZITET U BAJNOJ LUCI ELEKTROTEHNIKI FAKULTET

Seminarski rad iz Kriptografije i kompjuterske zatite SSL Secure Sockets Layer

Student: Vladimir Stani Indeks: 33/04

Sadraj:
Uvod.................................................................................................................................... 2 Struktura SSL-a................................................................................................................... 4 Handshake Protocol ............................................................................................................ 5 Prva faza- Postavljanje parametara veze......................................................................... 6 Druga faza- Autentikacija servera i razmjena kljueva .................................................. 7 Trea faza- Autentikacija klijenta i razmjena kljueva................................................... 9 etvrta faza- Zavretak uspostavljanja sigurne veze .................................................... 11 Change cipher spec protocol ............................................................................................. 11 Alert Protocol.................................................................................................................... 11 Record Protocol ................................................................................................................ 13 Napadi na SSL .................................................................................................................. 15 Clear text ....................................................................................................................... 15 Replay ........................................................................................................................... 15 The Man In The Middle ................................................................................................ 15 Napadi na izbor kriptografskog paketa ......................................................................... 16 Napadi na verziju protokola.......................................................................................... 16 Napadi prilikom razmjene kljueva .............................................................................. 16 Zakljuak........................................................................................................................... 17 Literatura:.......................................................................................................................... 18

Uvod
U veini mrea na svijetu postoji vie transportnih protokola. Internet je takoe jedna od tih mrea (tanije najvea globalna mrea). Prilikom programiranja aplikacija mora se izabrati jedan od raspoloivih protokola transportnog sloja. Transportni sloj (koji je smjeten izmedu aplikativnog i mrenog sloja), predstavlja centralni dio slojevite mrene arhitekture. Najvanija uloga transpornog sloja je neposredno obezbjedivanje komunikacionih usluga, procesima aplikacija, koji se izvravaju na razliitim raunarima. Jedan od kljunih zadataka transportnog sloja je proirivanje usluge isporuke izmedu dva krajnja sistema koje se obavlja u mrenom sloju, tako da se ostvari usluga isporuke izmedu dva procesa u aplikativnom sloju, koji se izvravaju na tim krajnjim sistemima. SSL predstavlja protokol koji omoguava siguran kanal izmedu dva uredaja uz mogucnost identifikacije uredaja s kojim komunicirate (tanije omoguava sigurnu komunikaciju). SSL je takode metoda enkripcije podataka putem transportnog protokola poput TCP-a. Razvijen je od Netscape-a. Siguran kanal o kojem je ovdje rijec je transparentan. To bi u stvari znailo da podaci koji su poslati s jedne strane nepromijenjeni stiu do druge strane. Ova karakteristika omogucuje jednostavnu implementaciju SSL-a u postojece standarde. To praktino znai da bi uz malu modifikaciju svaki protokol koji radi preko TCP-a (Transmission Control Protocol) mogao raditi i preko SSL-a. Tipina situacija koja je zahtijevala primjenu sigurnog kanala bila je kupovina preko interneta u kojoj broj kreditne kartice predstavlja informaciju koju treba tititi. U tom sluaju prvi zadatak koji je SSL trebalo da ispuni je povjerljivost. Informacije koje se alju izmeu klijenta i servera trebalo bi da ostanu poznate samo njima. Sluaj kupovine preko interneta otkriva i druge zadatke koje je SSL morao ispuniti. Autentikacija korisnik je morao biti siguran da komunicira s onim serverom s kojim eli ostvariti komunikaciju, a ne nekim trecim koji bi mogao zloupotrijebiti datu informaciju, I iz toga izvui neku korist. Sljedeca bitna karakteristika je spontanost. To znaci da je korisnik mogao spontano izabrati web server s kojim eli izvriti odreenu transakciju tj. poslovati s onim s kim dosad nije imao nikakvog poslovnog iskustva. Sljedei cilj i zadatak je bio povezati SSL sa HTTP-om (Hyper Text Transfer Protocol) koji je najvie koriten na internetu. Odatle proizilazi zahtjev za transparentnou i pouzdanou tog protokola. Kasnije je SSL bio proiren na druge protokole. Novija verzija SSL-a sadravala je ranije navedene zahtjeve, no protokol je uprkos tome bio poprilino sloen. U sljedecoj verziji ispravljeni su neki sigurnosni propusti. Poboljana je sigurnosna razmjene kriptografskih algoritama, pa je proiren i broj dostupnih algoritama. Sve verzije SSL-a i TLS-a (Transport Layer Security) kao njegovog nasljednika dijele zajedniki cilj uspostave sigurnog kanala komunikacije preko kojega ce aplikacijski programi slati sigurno svoje podatke. SSL u svom radu pretpostavlja da je nii sloj pouzdan tj. da ce podaci koji su poslani preko mree sigurno stici do svog odredita u onom obliku u kojemu su i poslati. Taj zadatak preputa drugim protokolima poput TCP-a. U praksi se ne koristi UDP (User Datagram Protocol) protokol koji ne osigurava istu sigurnost kao TCP.

Postoji nekoliko verzija ovog protokola, i ovdje emo nabrojati veinu njih: - SSL Version 1.0 nikada nije javno objavljen - SSL Version 2.0 objavljen februara 1995. godine ali je sadravao brojne propuste po pitanju sigurnosti to je dovelo do razvijanja - SSL Version 3.0 koji je objavljen 1996. godine - TLS Version 1.0 objavljen 1999. godine kao nasljednik SSL 3.0 od strane IETF-a (Internet Engineering Task Force) - TLS Version 1.1 objavljen aprila 2006. godine - TLS Version 1.2 objavljen avgusta 2008. godine U ovom seminrskom rdu bie opisn verzij 3 SSL protokol.

Struktura SSL-a

SSL protokol se sstoji iz vie nivo ko to je prikzno n slici.

Slika 1. poloaj SSL sloja SSL Record Protocol se brine o ifrovnjudeifrovnju informcij koje se prenose i tu uslugu pru viim slojevim. U prksi to je obino HTTP (Hypertext Transfer Protocol) preko kojeg Web iti i serveri rzmjenjuju podtke. Tri vi protokol: Protokol z dogovrnje-uspostvljnje veze (Handshake Protocol), protokol z promjenu klju (Change Cipher Spec Protocol), i protokol z upozorenje (Alert Protocol) slue z uspostvljnje veze, prelzk u reim ifrovnj simetrinim kljuem i ndglednje veze.

Handshake Protocol
Njsloeniji dio SSL-a je Handshake Protocol. Ovj protokol omoguv: provjeru identitet klijent i server, pregovrnje oko upotrebe lgoritm z ifrovnje i izrunvnje otisk poruke i rzmjenu kljuev. Koristi se u fzi uspostvljnj konekcije prije bilo kkve rzmjene plikcijskih podtk. Handshake Protocol se sstoji od niz poruk koje se rzmjenjuju izmeu klijent i server. Sve poruke su u formtu prikznom n slici. TYPE LENGTH CONTENT

TYPE tip poruke: veliine 1 bjt, sdri jednu od poruk prikznih u tbeli 1. LENGTH duin poruke: veliine 3 bjt, sdri duinu poruke u bjtovim CONTENT sdrj poruke: sdri prmetre pridruene tipu poruke prikzne u sljedeoj tbeli : TIP PORUKE hello_request client_hello server_hello certificate server_key_excange certificate_request serevr_done certificate_verify client_key_excange finished PARAMETRI PORUKE null version, random, session id, cipher suite, compression method version, random, session id, cipher suite, compression method chain of X.509v3 certificates parameters, signature type, authorities null signature parameters, signature hash value Tabela 1.

Uspostvljnje veze izmeu klijent i server odvij se rzmjenom poruk i moe se podijeliti u etiri fze:

Slika 2.

Prva faza- Postavljanje parametara veze

U ovoj fzi se inicijlizuje vez izmeu strn u komunikciji i pregovr oko upotrebe lgoritm z ifrovnje i izrunvnje otisk poruke. Dijlog zpoinje klijentsk strn slnjem poruke client_hello s sljedeim prmetrim: -Version: Njvi verzij SSL- koju podrv klijent. -Random: Struktur veliine 32 bjt gde se u 4 bjt upisuje tekue vrijeme, u ostlih 28 bjtov slujni broj. Koristi se z izrunvnje otiska i tjnog klju. -Session ID: promjenljive veliine i predstvlj identifikcioni broj sesije. Ako je jednk nuli td inicir konekciju s novom sesijom. Ako je rzliit od nule kreir se nov konekcij u postojeoj sesiji.

-CipherSuiteCipherSuite: list podrnih kriptogrfskih lgoritm od strne klijent nbrojnih po prioritetu. Svki element liste sdri kriptogrfski lgoritm i lgoritm rzmjene klju.Podrni su sledei lgoritmi z rzmjenu kljuev: RSA: tjni klju se ifruje s jvnim RSA kljuem primoc koji se it iz sertifikt. Fixed Diffie-Hellman: Difi-Helmn metod s fiksnim kljuem, sertifikti klijent i server sdre jvne prmetre z generisnje klju to rezultuje fiksni tjni klju. Ephemeral Diffie-Hellman: Difi-Helmn metod s privremenim kljuem, u ovom sluju prmetri z generisnje klju se ifruju privtnim kljuem poiljoc koji se uzim iz sertifikt. Anonymous Diffie-Hellman: u ovom sluju prmetri z generisnje klju se rzmjenjuju bez provjere utentinosti. Fortezza: Rzmjen klju po Fortez emi. Compression Method: List metod z kompresiju koje podrv klijent. Posle slnj client_hello poruke, klijent ek server_hello odgovor od server (ako prilikom obrade client hello poruke server nije naiao na problem i odgovorio sa handshake_failure porukom) koji sdri iste prmetre ko i client_hello poruk. Polje Version sdri usglenu verziju protokol tj najviu verziju SSL protokola koju podrava server, u odnosu na ono to je ponudio klijent.. Polje Random formir se n isti nin ko i kod klijent s tim to se ovih 28 bajtova mora razlikovati od sluajnog niza koji je poslao klijent. SessionID polje je identitet sesije koji odgovara zapoetoj konekciji. Ako ovo polje u client hello poruci nije prazno, server trai konekciju sa tom identifikacijom u svojoj memoriji i, ako je nae i ako moe da je koristi, server vraa isti broj kroz ovo polje, to znai da je prihvatio zahtjev klijenta. U suprotnom, ovo polje sadri drugaiju vrijednost koja oznaava novu identifikaciju sesije. CipherSuite sdri jedn izbrni lgoritm s liste koju je dostvio klijent. Compression polje sdri izbrni metod kompresije s liste klijent.

Druga faza- Autentikacija servera i razmjena kljueva

Server zpoinje ovu fzu slnjem sertifikt, ko je utentikcij potrebn. Poruk se sstoji od jednog ili lnc X.509 sertifikt. Klijent prolazi kroz sljedee korake da bi obavio autentikaciju servera: -Da li dananji datum odgovara vremenskom periodu validnosti sertifikata? klijent provjerava period validnosti sertifikata. Ako je trenutni datum van tog perioda proces autentikacije se nee nastaviti. U suprotnom se prelazi na sljedei korak :

-Da li je sertifikaciono tijelo (CA - Certificate Authority) tijelo od povjerenja ? svaki klijent sadri listu CA sertifikata od povjerenja. Ova lista odluuje koji serverov sertifikat e biti prihvaen. -Da li javni klju sertifikata odgovara digitalnom potpisu izdavaa? klijent koristi javni klju prethodno prihvaenog CA sertifikata da bi provjerio digitali potpis predstavljenog serverskog sertifikata. Ako se informacija u serverskom sertifikatu mijenjala nakon shto ga je CA potpisala, ili ako javni klju ne odgovara privatnom kljuu koji je CA koristila da bi potpisala sertifikat, klijent nee obaviti autentikaciju servera. -Da li ime domena u serverom sertifikatu odgovara imenu domena samog serevra ? ovim korakom se potvruje da se server stvarno nalazi na mrenoj adresi koja je specifikovana u imenu domena serverskog sertifikata. Iako ovaj korak tehniki gledano nije dio SSL protokola, omoguava jedinu vrstu odbrane od napada sigurnosti poznatog pod imenom Man In The Middle Attack. Klijent mora izvesti ovaj korak i treba da odbije autentikaciju servera ako se imena ne podudaraju. -Server je autentikovan ! ako klijent iz bilo kog razloga ne doe do ovog koraka server nee biti autentikovan i klijent biva upozoren o problemu i obavijeten da enkriptovana i autentikovana veza ne moe biti ostvarena.

Slika 3.

Autentifikcij nije potrebn jedino ko se koristi nonimn Difi-Helmn metod rzmjene kljuev. Ako se koristi Difi-Helmn metod s fiksnim kljuem td se ujedno vri i slnje jvnih podtk z generisnje tjnog klju poto su oni sdrni u sertifiktu. Ztim, ko je potrebn, lje se server_key_exchange poruk. Ov poruk nije potrebn u dv sluj: kd se rzmjen klju vri RSA metodom ili Difi-

Helmnovom metodom s fiksnim kljuem. U ostlim slujevim lju se prmetri z generisnje tjnog klju po sledeem: - z nonimnu Difi-Helmn metodu prmetri su prost broj n, genertor g, i serverski jvni Difi-Helmn klju (g^x mod n). - z Difi-Helmn metodu s privremenim kljuem prmetri su isti ko i u prethodnom sluju smo to se potpisuju privtnim kljuem server. - z RSA metodu, ukoliko se privtni klju koristi iskljuivo z potpisivnje, prmetr je potpisni privremeno generisni jvni RSA klju. Npomen o potpisivnju - potpisivnje se vri tko to se izrun otisak kombincije poruke i Random podtk klijent i server izmenjenih u prvoj fzi koji se ztim ifruje privtnim kljuem. Ako se ne koristi nonimn Difi-Helmn metod slede poruk je certificate_request kojom se od klijentske strne zhtjev dostvljnje sertifikt. N krju se dostvlj server_done poruk kojom server obvjetv klijent d je zvrio slnje i prelzi u stnje eknj odgovor.

Trea faza- Autentikacija klijenta i razmjena kljueva

-Da li klijentov javni klju odgovara njegovom digitalnom potpisu? Server provjerava da li se klijentski digitalni potpis moze provjeriti sa javnim kljuem koji se nalazi u sertifikatu. -Da li dananji datum odgovara vremenskom periodu validnosti sertifikata? server provjerava period validnosti sertifikata. Ako je trenutni datum van tog perioda proces autentikacije se nee nastaviti. U suprotnom se prelazi na sljedei korak -Da li je sertifikaciono tijelo (CA - Certificate Authority) tijelo od povjerenja ? svaki server sadri listu CA sertifikata od povjerenja. Ova lista odluuje koji klijentov sertifikat e biti prihvaen. -Da li javni klju sertifikata odgovara digitalnom potpisu izdavaa? server koristi javni klju prethodno prihvaenog CA sertifikata da bi provjerio digitali potpis predstavljenog klijentskog sertifikata. Ako se informacija u klijentskom sertifikatu mijenjala nakon shto ga je CA potpisala, ili ako javni klju ne odgovara privatnom kljuu koji je CA koristila da bi potpisala sertifikat, server nee obaviti autentikaciju klijenta. -Da li je klijentov sertifikat nalazi na listi u LDAP direktorijumu? ovaj opcioni korak omoguava sistem administartoru da opozove klijentov sertifikat ak i ako je proao testove svih prethodnih koraka. The Netscape Certificate Server moe automatski da ukloni odbijeni sertifikat od ulaska korisnika u LDAP direktorijum. Svi serveri koji su postavljeni da obavljaju ovaj korak e tada odbijati da potvrde sertifikat ili da uspostave vezu.Ako je korisnikov sertifikat u direktorijumu identian sa sertifikatom korisnika koji je predstavljen u SSL handshake-u, veza se uspostavlja. -Da li autentikovani klijent ima pravo pristupa zahtjevanim resursima ? server provjerava kojim resursima klijent ima dozvolu da pristupa na osnovu svoje kontrolne liste pristupa (ACL Acces Control List) i ostvaruje vezu sa odgovarajuim

pristupom.Ako server ne doe do ovog koraka iz bilo kog razloga , klijent identifikovan sertifikatom ne moze biti autentikovan i nee mu biti dozvoljen pristup resursima koje zahtjeva.

Slika 4. Ako server nije zahtijevao dostavljanje sertifikata dostavlja se alarm no_certfifcate. Sljedea poruka koja mora biti poslana je client_key_exchange iji sadraj zavisi od izabranog algoritma za razmjenu kljueva po sljedeem : - RSA: klijent generie broj veliine 48 bjtov, ifruje g s jvnim RSA kljuem iz sertifikt server ili privremenim RSA kljuem iz server_key_exchange poruke. Tj broj se naziva premaster secret i ksnije se koristi z generisnje tjnog simetrinog klju. -Fixed Diffie-Hellman: lje se poruk bez prmetr poto su prmetri z generisnje klju sdrni u sertifiktim. -Ephermal ili Anonymous Diffie-Hellman: lju se jvni Difi-Helmn prmetri. Server potom koristi svoj privatni klju da bi dekriptovao ifrovani premaster secret i izvodi seriju koraka (koje klijent takoe izvodi) i generie master secret. Klijent i server zatim koristei master secret generiu kljueve sesije koji predstavljaju simetrine kljueve koji se koriste za enkripciju i dekripciju tokom razmjene informacija u SSL sesiji. N krju 3. fze klijent moe poslti certificate_verify poruku kojom eksplicitno potvruje verifikciju sertifikt.

10

etvrta faza- Zavretak uspostavljanja sigurne veze

Ovo je zvrn fz uspostvljnj konekcije u kojoj klijent lje cipher_spec poruku ime obvjetv serversku strnu d prelzi u reim ifrovnj simetrinim kljuem. Ov poruk se lje korienjem protokola z promjenu klju (Change Cipher Spec Protocol). Nkon ove poruke klijent lje finished poruku i prelzi u stnje eknj. Serversk strn lje isti pr poruk ime se zvrv protokol z uspostvljnje sigurne veze.

Change cipher spec protocol

Ovj protokol sstoji se od jedne poruke veliine bjt i njime predjn strn obvjetv prijemnu strnu d prelzi n reim ifrovnj podtk simetrinim kljuem tj sve poruke koje slijede e biti enkriptovane. Change_cipher_spec poruka je uvijek praena finished porukom.

Alert Protocol
Svk poruk sstoji se iz dv bjt. Prvi bajt sadri nivo alert protokola a drugi bajt sadri kod upozorenja. SSLv3.0 definie 13 razliitih izvanrednih dogaaja. Prikazani su u tabeli 2. Postoje dva nivoa alert protokola. Jedan je warning koji upozorava na greku, ali ne prekida vezu, dok fatal trenutno prekida vezu. Kada je otkrivena greka, strana koja ju je otkrila alje poruku drugoj strani. U trenutku slanja i primanja takve poruke, obje strane zatvaraju sesiju (vezu). Server i klijent su u tom sluaju obavezni zaboraviti bilo kakve podatke o sesiji, identifikatore sesije, kljueve i ostale tajne koje su vezane uz sesiju.

11

BROJ 0

IME close_notify

10 20 30 40

unexpected_message bad_record_mac decompression_failure handshake_failure

41 42 43 44 45 46 47

no_certificate bad_certificate unsupported_certificate certificate_revoked certificate_expired certificate_unknown illegal_parameter

OPIS Indicira da poaljilac vie ne namjerava slati podatke. Ukoliko je ovaj opis poslan sa upozorenjem, veza moe biti obnovljena; ukoliko je pak poslan uz kritian nivo dogaaja, veza ne moe biti obnovljena. Primljena je neoekivana poruka. Ovaj opis se ne bi smio dogoditi; indicira greku u jednoj od SSL implementacija (klijentskoj ili serverskoj). Kritian ! Poaljilac je primio zapis sa neispravnim autentikacijskim kodom poruke (MAC). Kritian ! Informacija u zapisu se ne moe ispravno dekompresovati.Kritian ! Ukazuje da poaljilac nije u mogunosti prihvatiti skup sigurnosnih parametara (npr. poaljilac nije zadovoljan s primaoevim algoritmima za ifrovanje i njihovom snagom).Kritian ! Dogaa se kao odgovor na zahtjev za uvjerenjem ukoliko ne postoji odgovarajue uvjerenje. Dogaa se ukoliko je zahtjev za uvjerenjem neuspjean (uvjerenje je neispravno ili je neispravan digitalni potpis). Dogaa se ukoliko poaljilac ne podrava odreeni tip uvjerenja. Dogaa se ukoliko poaljilac primi uvjerenje koje je ve prije povueno Dogaa se ukoliko poaljilac primi uvjerenje koje je isteklo. Dogaa se ukoliko se prilikom obrade uvjerenja dogodi greka Dogaa se ukoliko poaljilac ustanovi da je neka vrijednost u protokolu za rukovanje nedozvoljene vrijednosti. Kritian ! Tabela 2.

12

Record Protocol
Ovim protokolom se na predajnoj strani svi podaci prihvaeni od aplikacijskog sloja enkapsuliraju se u tzv record, objekat koji se sastoji od zaglavlja (header) i jednog broja podataka razliitog od nule i predje TCP sloju rdi slnj. Na prijemnoj strni podci se preuzimju od TCP sloj i predaju aplikacijskom nivou. Prvi korak u prenosu podataka je njihova fragmentacija na blokove veliine ne vee od 2^14 (16384) bjtov. Opciono se sprovodi kompresija i mora biti bez gubitaka. Kompresioni algoritam pretvara SSLPlaintext u SSLCompressed strukturu. Ako se prilikom dekompresije dobije zapis ija veliina prelazi 2^14 bajtova, generie se poruka fatal greke. Da bi se osigurala autentikacija poruka, uz fragment se alje i njegov MAC (Message Authentication Code) koji se mora verifikovati na strani primaoca da bi bio primljen. MAC se dobija kao rezultat hash funkcije koja radi sa sljedeim podacima : MAC=hash function (tajni klju, podatak koji se prenosi, padding, broj sekvence) Broj sekvence je 32 bitna vrijednost koju hash funkcija posmatra kao etvorobajtnu vrijednost gdje je prvi bajt najznaniji bajt broja sekvence. Predstavlja broja koji se inkrementira i od strane poiljaoca i od strane primaoca. Za svaki smjer prenosa uva se par brojaa (jedan od poiljaoca, jedan od primaoca). Svaki put kada poiljaoc poalje poruku broja se inkrementuje. Primalac poruke koristi oekivanu vrijednost broja sekvence za izraunavanje MAC vrijednosti. Izraunata vrijednost mora biti identina primljenoj MAC vrijednosti. Treba napomenuti da prije nego to se prvi record poalje koritenjem SSL-a svi brojevi sekvenci su podeeni na nulu. Inkrementiranje se vri sa svakom poslanom porukom poev od client_hello i server_hello poruka. Sljedeim korakom se kompresovani podaci i MAC ifruju dogovorenim algoritmom za ifrovanje simetrinim kljuem. Raspoloivi algoritmi su prikazani u tabeli 3. : Blok algoritmi Algoritam Duina kljua AES 128.256 IDEA 128 RC2-40 40 DES-40 40 DES 56 3DES 168 Fortezza 80 Tabela 3. Sekvencijalni algoritmi Algoritam Duina kljua RC4-40 40 RC4-128 128

13

Poslednji kork je dodvnje zglvlj koje sdri slede polj: Content Type (8bita) tip sdrja: identifikuje protokol vieg sloj i moe imti sledee vrijednosti change_cipher_spec, alert, handshake i application_data. Major Version (8 bita) broj verzije protokol: definie verziju SSL protokol (npr. z SSLv3.0 jednk je 3 ). Minor Version (8 bita) broj podverzije-revizije: definie podverziju protokol (npr. z broj SSLv3.0 jednk je 0). Compressed Length (16 bita) duin podtk: duin kompresovnih podtk ko su kompresovni ili duin podtk ko nem kompresije.

Slika 4.

14

Napadi na SSL

Clear text
Ova vrsta napada se izvodi kada napada ima odreenu ideju o vrsti poruke koja se prenosi. Napada moe generisati bazu podataka iji kljuevi bi bili enkriptovane vrijednosti poznatog teksta a ije vrijednosti bi bili kljuevi sesija (ovo se naziva rjenikom). U ovako formiranoj bazi podataka jednostavnom funkcijom pretraivanja bi se pronaao klju sesije koji odgovara odreenoj enkriptovanoj vrijednosti. Jednom kada nam je poznat klju sesije cijeli niz poruke se moe dekriptovati. Zbog same prirode SSL-a ova vrsta napada je mogua. Na primjer, najei bajt koji se alje http-om klijentskom aplikacijom ka http serveru je get. SSL se brani na sljedei nain prvo, klijent generie klju koji je dui od dozvoljenog i jedan dio alje otvorenim putem. Taj dio kljua povezan sa tajnim dijelom ga ini veoma dugakim (konkertno za RC4 iznosi 128 bita). Nain na koji ovo pobjeuje napad jeste da potrebe za hardverom uini strano velikim. Svaki bit koji se doda na klju sesije udvostruuje veliinu rjenika.

Replay
Replay napad je jednostavan. Napada snimi komunikaciju izmeu klijenta i servera. Kasnije se povee se serverom i ponavlja prethodno snimljene poruke. SSL se brani od ovog napada koritenjem ID-a konekcije koji je jedinstven za svaku konekciju. Teorijski, napada ne moe predvidjeti ID konekcije u naprijed jer je on temeljen na nekim sluajnim dogaajima koji su van njegove kontrole. Tako da napada nije u mogunosti da propisno odgovara na serverove zahtjeve. Napada sa dobrim izvorima moe snimiti veliki broj sesija izmeu klijenta i servera i pokuati da odabere pravu sesiju baziranu na ID-u konekcije koji server inicijano alje u svom server_hello. ID-ovi konekcije su najmanje 128 bita dugaki tako da bi napada morao da posjeduje priblino 2^64 ID-ova da imao makar 50% anse da odabere pravu sesiju.

The Man In The Middle

Ova vrsta napada podrazumijeva troje uesnika u komunikaciji : klijenta, servera i napadaa. Napada se nalazi izmeu klijenta i servera i presree saobraaj koji klijent alje serveru i obratno saobraaj koji server alje klijentu. Napad se ogleda u tome da se napada predstavlja klijentu kao pravi server. Na primjer, napada moe da dogovori/uspostavi kljueve za ifrovanje izmeu klijenta i serevra. Oni tada alju ifrovane podatke napadau koji moe deifrovati podatke. Sa SSL-om ovaj napad je nemogu zbog koritenja serverovih sertifikata. Tokom hanshake-a od servera se zahtjeva da dostavi sertifikat potpisan od strane CA. Klijent provjerava serverov sertifikat na nain na koji je to ve opisano. Uz to, server mora enkriptovati neto sa privatnim kljuem koji

15

odgovara javnom kljuu koji se pominje u sertifikatu. Ovaj korak je esencijalan samo server koji posjeduje i sertifikat i privatni klju moe odgovoriti na ovaj izazov. Ako napada posjeduje lani sertifikat nee proi na provjeri potpisa. Ako pak posjeduje legitiman sertifikat provjera potpisa e proci ali e zato provjera imena biti neuspjena. Konano, ako napada posjeduje serverov pravi sertifikat proi se i provjeru potpisa i provjeru imena ali kako nema serverov privatni klju ne moe propisno obaviti kodovanje i napad e biti bezuspjean.

Napadi na izbor kriptografskog paketa

Veoma zanimljiva slabost SSL 2.0 protokola je omoguila ovu vrstu napada koji je pogaao samo Amerikance: napada je mogao, editovanjem liste podranih kriptografskih paketa, da neopaeno isforsira korienje slabijih algoritama koji se isporuuju uz verzije protokola namijenjene izvozu. Verzija 3.0 ispravlja ovu slabost tako to zahtijeva autentifikaciju svih poruka u SSL Handshake protokolu.

Napadi na verziju protokola

Ve je reeno da je u verziji 2.0 bilo dosta slabosti koje su ispravljene verzijom 3.0. Kako verzija 3.0 potuje vertikalnu kompatibilnost, tj. moe da radi sa aplikacijama koje koriste verziju 2.0, jednostavna podloga za dalje napade se stvara tako to se drugi uesnik u komunikaciji ubijedi da komunicira sa verzijom 2.0. Napadau je dovoljno da kreira client_hello poruku na taj nain da izgleda kao poruka iz verzije 2.0 i da pone da koristi sve slabosti stare verzije.

Napadi prilikom razmjene kljueva

Prilikom razmene kljueva kod SSL 3.0 postoje odreene slabosti koje mogu biti iskoriene za preduzimanje napada. Na primer, server moe poslati, u okviru server key exchange poruke, parametre javnih kljueva, potpisane sertifikatom servera. Meutim, ovaj potpis ne titi polje koje odreuje koji algoritam za razmenu kljueva e biti korien. Modifikacijom ovog polja, klijent moe biti naveden da umesto seta DiffieHellman parametara prihvati informaciju da je server potpisao set kratkotrajnih RSA parametara. Praenjem dalje komunikacije izmeu servera i klijenta, napada matematiki moe izraunati pre master secret, a sa tim i sve ostale kljueve i doi do sadraja poruke. Jo jedna slabost prilikom razmene kljueva kod SSL 3.0 primeena je kod anonimnih konekcija. Ako server bude doveden u situaciju da prihvati anonimnu razmenu kljueva, onda server ne trai signaturu kriptografskih parametara, to onom ko je takvu sesiju inicirao moe omoguiti praenje svih poslednjih anonimnih razmena kljueva.

16

Zakljuak
SSL je stvoren prvenstveno kao odgovor na sverastue potrebe za zatienim prenosom podataka putem interneta. SSL je gotovo neophodan za sigurnost etrgovine. Uprkos postojanju i drugih rjeenja sigurnosti na Internetu kao to su: Secure-MIME protokol, Secure HTTP, Secure Shell, Private Enhanced Mail, MIME Object Security Services, Private Communication Technology, SSL se pokazao najboljim rjeenjem za osiguravanje elektronskih transakcija. Dalji uspjeh e-poslovanja uveliko zavisi od potroaevog povjerenja u funkcionisanju SSLa. No, kao i svi ostali sistemi, sigurnost SSLa zavisi od svih karika u lancu koji ga ine: klijenta, servera, pa i izdavatelja potvrda. Svi ovi uesnici trebaju brinuti o sigurnosti i redovno odravati svoje sisteme kako bi se ostavila to manja mogunost ometanja komunikacije i krae, kako informacija tako i novca. Zbog injenice da su izvozne verzije potokola kriptoloki dosta osiromaene u odnosu na amerike, treba imati rezervu prema neogranienom korienju ovog protokola za prenos osjetljivih podataka. U budunosti, SSL e moi obavljati mnogo vie transakcija u kraem vremenu. Duina kljueva e rasti, algoritmi e biti uspjeniji, sve u cilju razvoja sigurnosti informacija na internetu.

17

Literatura:
http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html http://www.windowsecurity.com/articles/Secure_Socket_Layer.html http://www.scribd.com/doc/24344342/SSL-PROTOKOL-TRANSPORTNI-SLOJ-finalniA http://docs.sun.com/source/816-6156-10/contents.htm

18