Uporaba kriptografije v internetu
Kazalo   
 

SSL (Secure Sockets Layer)

je protokol, ki omogoča šifrirano povezavo med strežnikom in odjemalcem. Netscape ga je predstavil leta 1994. Dve leti kasneje je bila objavljena verzija 3 kot Internet Draft.

Poleg osnovnega cilja - varnosti in zasebnosti povezave - so si pri Netscape-u pri razvoju SSL zastavili še naslednje naloge:

  • odprtost - lahko ga implemetirajo drugi proizvajalci;
  • možnost dograjevanja z novimi kriptografskimi algoritmi;
  • učinkovitost: parametri, izmenjani s pomočjo asimetričnih algoritmov, ki so dosti počasnejši od simetričnih, se nekaj časa hranijo zato, da se asimetrični algoritmi izvajajo manjkrat.

Nalogo so rešili tako uspešno, da je SSL de facto standard. Njegov naslednik TLS (Transport Layer Security) - RFC 2246, ki ga je pripravil IETF, se od SSL le malo razlikuje. Seveda pa se razvoj ni ustavil in ga dopolnjujejo. Junija 2003 je bil objavljen RFC 3546, ki dopolnjuje RFC 2246 tako, da bi bil TLS bolj učinkovit. Naslednje dopolnitve so naštete v RFC 4366, tu gre predvsem za izboljšave zaradi uporabe mobilnih telefonov oziroma manj zmogljivih klientov..

Po OSI modelu komunikacijskih protokolov je vložen med transportni in aplikacijski nivo. Preverjanje vrstnega reda ali sprememb v izmenjanih blokih prepušča niže ležečemu protokolu, zato mora biti ta zanesljiv (TCP, ne pa UDP). Omogoča zaščito za vse aplikacijske protokole nad TCP (http, smtp, news, pop3, ldap, ...). Netscape je rezerviral naslednje številke za vrata aplikacijskih protokolov nad SSL:

      443      https                   989     ftp-podatki (ftps-data)
      465      ssmtp                   990     ftp-kontrolni (ftps)
      563      nntps (news)            992     telnets
      614      SSLshell                993     imap4 (imaps)
      636      ssl-ldap                995     POP3 (POP3S)

Iz prej povedanega vemo, da samo šifriranje blokov podatkov še ne bi omogočilo varne komunikacije, prav tako pomembno je preverjanje nespremenjenosti podatkov (integrity) ter preverjanje avtentičnosti obeh strani ( authentication) in vse to vključuje SSL.

Odjemalec in strežnik vzpostavita povezavo po protokolu TCP na običajen način, SSL pa poskrbi za šifriranje izmenjanih sporočil.

SSL sestavljata dva sloja:
Opis protokolov na zgornjem sloju

Opis Record protokola


V zgornjem sloju so protokoli, ki poskrbijo za to, da se medsebojno preverita, se dogovorita za način šifriranja podatkov ter varno izmenjata simetrični ključ. Samo šifriranje podatkov pa se izvaja na spodnjem sloju po prej dogovorjenem simetričnem algoritmu (Record Protocol).

V opisu protokola algoritmi niso zafiksirani in jih določi proizvajalec posameznega programskega produkta. Za overjanje in izmenjavo ključa so v zdaj definiranih naborih našteti algoritmi RSA, Diffie-Hellman in Fortezza, od simetričnih algoritmov pa DES, RC2, RC4, IDEA, 3DES, FORTEZZA.

Protokol je od svojih začetkov doživel nekaj sprememb. Izboljšave v verziji 3 glede na verzijo 2 so naslednje:

  • Dodan je povzetek vseh izmenjanih sporočil na koncu dogovarjanja o ključih, kar otežuje "man-in-the-middle attack". Ta je med drugim omogočal, da je napadalec izsilil uporabo krajših ključev, kot je bilo prvotno dogovorjeno med klientom in strežnikom.
  • Dodana je možnost komprimiranja podatkov z algoritmi, kot je ZIP.
  • Ker je bila do nedavnega dolžina simetričnega ključa po ameriških izvoznih pravilih omejena, so za zagotavljanje celovitosti in overjanja dodali overitveno število (MAC secret), ki je dolgo 128 bitov pri MD5 in 160 bitov pri SHA. Omejitve so namreč veljale samo za šifriranje, ne pa za podpisovanje.
  • Klient in strežnik lahko med povezavo spremenita ključe - pobudnik pošlje sporočilo Hello in sproži se Handshake protokol.
  • Omogoča izmenjavo več potrdil (certifikatov), povezanih v verigo. Tako lahko strežnik pošlje klientu poleg svojega digitalnega potrdila še potrdilo (ali več potrdil) overitelja zato, da lahko klient preveri strežnikovo potrdilo, tudi če ne pozna overitelja.
Zato ne bi smeli več uporabljati verzije 2.

V brskalniku jo izklopimo takole:

MS Explorer: Orodja->Internetne možnosti->Napredno

Netscape: Edit->Preferences->Privacy&Security->SSL

Opera: File->Preferences->Security

Tudi na strežnikih blokirajmo uporabo SSLv2. Septembra 2002 se je pojavil črv Slapper, ki izkorišča luknjo v implementaciji SSLv2 v OpenSSL v verzijah, starejših od 0.9.6g.


Brskalniki in SSL

Vsi najbolj razširjeni brskalniki podpirajo SSL oziroma TLS. Nastavitve si ogledamo oziroma jih spremenimo takole:

Netscape 6.x, 7.x; Mozilla 1.x: Edit->Preferences->Privacy&Security: SSL, Certificates, Validation
Opera 6.x: File->Preferences->Security
MS Internet Explorer 6.x: Orodja->Internetne možnosti->Napredno->Varnost in Orodja->Internetne možnosti->Vsebina->Certifikati
Ko se z brskalnikom odpravimo nakupovat ali v banko, običajno najprej vzpostavimo nezašifrirano povezavo (n.pr. http://www.amazon.com). Ikona v desnem spodnjem kotu na ekranu kaže odprto ključavnico .

Ko začnemo pošiljati svoje podatke, se povezava spremeni v šifrirano: v naslovu se protokol spremeni v https, spremeni se številka vrat, ikona kaže zaklenjeno ključavnico . Podatke o povezavi in o digitalnem potrdilu strežnika preverimo takole:

Netscape 6.x, 7.x; Mozilla 1.x: Kliknemo na desni gumb na miški in izberemo View Page Info -> Security ter View Certificate
MS Internet Explorer 6.x: Kliknemo na desni gumb na miški in izberemo Properties -> Certificates
Opera 6.x: Z miško se postavimo na ikonico ključavnice in pokažejo se nam podatki o povezavi.
Če strežnik nima digitalnega potrdila, ki ga je izdala uveljavljena ustanova, prekinimo povezavo. Pri preverjanju imen se ni težko zmotiti, saj ima celo Bela hiša dvojnici- (1), (2). Dodeljevanje domen namreč za domene org, com, net in nekatere države ni tako kontrolirano, kot je pri nas za vrhovno domeno si, kjer skrbi za to Arnes.

Nekatere aplikacije (n.pr. bančne) so pripravljene tako, da se overja tudi odjemalca - bodisi tako, da je treba vtipkati enkratno geslo, ki ga generira kartica, ki je sinhronizirana z njihovim strežnikom, bodisi tako, da mora brskalnik poslati strežniku svoje digitalno potrdilo (tako se overja komitente v aplikaciji Klik pri NLB).

Kako dobimo digitalno potrdilo za brskalnik?
To je seveda odvisno od tega, za kaj ga potrebujemo. Skrbnik aplikacije mora poskrbeti za navodila, pri kateri ustanovi in kako zahtevamo potrdilo, saj je odvisno od nastavitev na strežniku, s katerimi potrdili dovoljuje povezave.


Kaj pa zaščita podatkov med mobilniki in strežniki?

Temu je namenjen WTLS (TLS, prirejen za brezžične komunikacije), ki je sestavni del WAP.


Protokol SSL oziroma TLS je sicer dobro zasnovan, v vsakdanji uporabi pa je še precej problemov:
  • luknje v implementacijah
    Znana je zgodba iz leta 1996 o slabo implementiranem psevdogeneratorju naključnih števil v prvi verziji Netscape Navigatorja. V novih verzijah softvera se pojavljajo nove varnostne luknje, zato je treba spremljati obvestila o tem in ustrezno dograjevati programe, ki jih uporabljamo - tako na uporabniških delovnih postajah kot na strežnikih.
    Nekaj primerov:
    Netscape 4.72 in nižje verzije - maj 2000;
    MS Internet Explorer - avgust 2002;
    OpenSSL - julij 2002.
    Google Desktop Search poindeksira datoteke iz brskalnikovega predpomnilnika - november 2004. Brskalniki ne bi smeli hraniti strani, ki so dostopne prek SSL.
    Daniel Bleichenbacher na konferenci Crypto 2006 opozori na luknje v kriptografskih knjižnicah, ki jih uporabljajo nekateri brskalniki, in ki omogočijo napadalcu, da ponaredi digitalno potrdilo, če se za podpisovanje uporabi potrdilo z RSA javnim eksponentom 3. MSIE nima te napake, za Mozillo, Firefox in OpenSSL so na voljo popravki.

  • prešibki ključi v ameriških produktih zaradi ameriških izvoznih omejitev
    Do januarja 2000 je veljalo naslednje:
    Samo finančne in zdravstvene institucije, ki jim je potrdilo izdal ameriški overitelj Verisign, lahko uporabljajo neokrnjene verzije kriptografskih modulov. Od konca leta 1999 taka potrdila izdaja tudi Thawte. Za druge pa so bili simetrični ključi do nedavnega omejeni na 40 bitov, asimetrični pa na 512 bitov. Od 1998 je dovoljena tudi uporaba DES-a (56 bitov) - kar pomeni, da za NSA in podobne ustanove DES ne predstavlja zadostne zaščite..
    Zdaj so te omejitve delno odpravljene, vendar je dobro preveriti, kakšne ključe podpira softver, ki ga nameravamo uporabljati.
    -->Nekaj več o dolžini ključev

  • občutek lažne varnosti
    SSL zaščiti zgolj povezavo med dvema postajama, podatki na njima pa so nezašifrirani. Za njuno varnost pred vdori in za zaščito datotek na postajah mora biti dodatno poskrbljeno - tako na strežnikih kot pri uporabnikih. Izjave v smislu "uporabljamo nezlomljivo tehnologijo za zaščito podatkov..." so take, kot da bi se hvalili, da smo na leseno barako namestili železna vrata z močno ključavnico. Tatovi se res ne bodo trudili z vrati, če z lahkoto odrinejo nekaj lesenih desk. Če na našem računalniku gostimo trojanskega konja (n.pr. Back Orifice), nam SSL prav nič ne pomaga.
    Kar naprej beremo o vdorih na slabo zaščitene strežnike, ko crackerji pridejo do podatkov o kupcih in kreditnih karticah. Delno je to rezultat tega, da postaja programska oprema neobvladljiva : operacijski sistem linux ima okrog 4 milijone vrstic kode, Windows NT štirikrat več, Windows 2000 pa ocenjujejo na 36 do 60 milijonov vrstic kode.
    Za varnost na strežnikih se da še nekako poskrbeti z usposobljenimi skrbniki, na uporabniških delovnih postajah pa veliko teže.
    Dostop do uporabnikovega zasebnega ključa bi moral biti vedno zaščiten z geslom. Na žalost se moramo zato v Windowsih posebej potruditi (uporabiti visok nivo varnosti in ne izbrati opcije, da si operacijski sistem zapomni geslo).
    Uporabnik bi si moral namestiti in redno vzdrževati protivirusno zaščito in požarni zid. Izključiti bi moral vse opcije, ki omogočajo poseganje na njegov računalnik brez njegovega dovoljenja in nalaganje sumljivih datotek. Na žalost pa potem veliko spletnih strani ne bo mogel odpreti, ker uporabljajo ActiveX oziroma JavaScript.

    Primer: Septembra 2002 smo brali o trojanskem konju Roberta Škulja, ki naj bi izkoriščal varnostno luknjo v MS IE (Enable third party browser extensions) za dostope do aplikacije Klik NLB. Na uporabnikovem računalniku naj bi čakal, da se uporabnik priključi na Klik NLB in izvede fazo overjanja. Po tem pa trojanec izvede nakazilo zneska na vnaprej sprogramiran račun. Tu je vseeno, kako je izvedeno overjanje uporabnika - z digitalnim potrdilom na disku ali kartici, lahko pa bi bilo tudi z vnosom enkratnega gesla, saj trojanec lepo počaka, da uporabnik naredi vse potrebne korake. Ker se ta trojanec ne povezuje z nobenim drugim računalnikom, ga tudi požarni zid ne more odkriti.

    NIST je junija 2004 objavil Priporočilo za uporabo TLS .

  • lažno predstavljanje, lažna digitalna potrdila (certifikati)
    Ko kupujemo prek interneta, imamo na začetku povezave s trgovčevim strežnikom možnost preveriti njegovo digitalno potrdilo. Kdo mu ga je podelil? Kaj, če je bilo vmes preklicano? Ali gre za goljufa? Uporabniki se bomo morali navaditi, da preverimo digitalno potrdilo strežnika. Pri tem je zelo slabo, da so v naše brskalnike že vnaprej vključeni nekateri overitelji - brskalnik jim avtomatično zaupa, to pa bi morala biti uporabnikova zavestna odločitev. Zato je pametno vse neznane overitelje zbrisati iz brskalnikovega seznama (Mozilla: Edit -> Preferences -> Privacy&Security -> Certificates -> Manage Certificates -> Authorities; MS IE: Orodja -> Internetne možnosti -> Vsebina -> Certifikati -> Zaupanja vredni overitelji).
    Po raziskavi, ki jo je sredi leta 2000 naredil Eric Murray, je od 8081 strežnikov kar 32 % imelo pomanjkljivosti (uporaba prekratkih ključev, SSLv2, že pretekla veljavnost digitalnega potrdila).

    Z izrazom phishing označujemo lažno predstavljanje, ki naj bi navedlo kupca, da pošlje prevarantom podatke o svojem bančnem računu, gesla, uporabniška imena in druge osebne podatke. Uporabniki eBay so leta 2003 dobili elektronsko pošto, v kateri naj bi jih eBay prosil, da ažurirajo podatke o svojem računu tako, da kliknejo na posredovani link. Pošiljatelj seveda ni bil eBay, goljufi so s pomočjo lažne spletne strani polovili precej podatkov. Kako enostavno je preslepiti internetnega uporabnika, kažeta naslednja primera:
    (1) (opis je prikazan kot slika, ker so sicer nekateri antivirusni programi opozorili, da gre v datoteki za lažen naslov - "URL spoof")

    (2) Zaradi premalo stestirane uporabe IDN (International Domain Names), ki jo propagira Verisign in so jo implementirali v brskalnikih Mozilla, Firefox, Opera in drugi (v MSIE še ne), uporabnik v URL ne more razlikovati nekaterih črk. V članku iz leta 2002 so to imenovali "homograph attack"in kot primer je navedena registracija domene microsoft.com z ruskima črkama c in o. Novejši je opis podobne sleparije za paypal.com. Firefox 1.0.1, ki je na voljo od 24. februarja 2005, ima že vključen popravek za prikazovanje IDN.

    Zaradi teh problemov je nastalo združenje CA/Browser Forum, ki združuje nekatere overitelje digitalnih potrdil (Certificate Authorities) in proizvajalce brskalnikov, ki poskušajo skupaj najti rešitve, kako bi uporabniku olajšali prepoznavanje lažnih ali ponarejenih digitalnih potrdil.Njihova ideja so EV certificates, kje EV pomeni Extended Validation. Ko se uporabnik priključi na strežnik, ki ima potrdilo, ki je bilo izdano na način, ki ga priporoča ta organizacija v svojih navodilih, izdanih junija 2007, se mu pokaže kot zeleno obarvana vrstica.

    Eden od primerov, kako pomagati uporabnikom, da ne zaidejo na lažne strani, je tudi način, ki ga propagira Ljubljanska banka - uporabnik si sam izbere tekst, ki se mu pokaže ob prijavi na pravo spletno stran. Ljubljanska banka omogoča tudi uporabo dodatnih gesel za transakcije, ki jih nimamo v naboru "hitrih plačil" - po običajni pošti nam pošljejo nam niz znakov, od katerih moramo ob transakciji vtipkati dva.

  • preverjanje, ali je bilo digitalno potrdilo (certifikat) preklicano, bi moralo biti obvezno
    Novejše verzije brskalnikov sicer omogočajo preverjanje, ali je potrdilo na seznamu preklicanih potrdil (CRL, Certificate Revocation List), vendar kaže, da bo to res v uporabi šele, ko bo omogočeno sprotno preverjanje statusa potrdila po protokolu OSCP (Online Certificate Status Protocol - RFC 2560). Za zgoraj omenjena EV digitalna potrdila bo uporaba OCSP obvezna od začetka leta 2011.

April 1997, zadnjič ažurirano februarja 2008