4. novembril aadressil http://extendedsubset.com/ publitseeritud info SSL protokolli nõrkuse (“SSL Authentication Gapâ€) kohta on leidnud elavat vastukaja, Internet kubiseb blogijate postitustest ning on olemas ka kodumaine näide.
Ette rutates võib öelda, et soovitus ID-kaardid sahtlisse panna on enneaegne. Kliendituvastusega (client authentication) SSL/TLS protokolli kasutamine on ja jääb alati turvalisemaks kui ilma selleta. Paneme tähele, et kõik teised autentimisvahendid (paroolikaart, PIN-kalkulaator, Mobiil-ID) ei kasuta kliendituvastusega SSL protokolli ning on seetõttu olulisel määral rohkem altid vahemehe (Man-in-The-Middle) rünnakutele, kus ohver juhatatakse võltslehele ning vahendatakse sobivalt tema suhtlust „pärislehega“.
Milles siis jutu all olev nõrkus seisneb?  Olukorra lihtsustamiseks vaatleme näidet, kus SSL veebiserver on konfigureeritud aktsepteerima ID-kaarti, kuid see ei ole „kohustuslik“, s.t. eksisteerib serveri alamosa, mida saab kasutada siis, kui ID-kaardiga ei ole autenditud või autentimine ebaõnnestus. Nii on meil konfigureeritud enamus veebiservereid, kuna kasutajasõbralikkuse huvides on ID-kaardiga autentimise ebaõnnestumise korral ilus näidata browser error’i asemel mingit ilusamini kujundatud pilti.
Nende kahe SSL oleku (on klient autenditud või ei) vahetamist nimetatakse SSL renegotiation’iks ehk siis maakeeli „ümberleppimiseks“. Häda on nüüd selles, et enamus SSL realisatsioone ei pea järge selle üle, kas ümberleppimise-eelne sessioon oli sama mis ümberleppimis-järgne.
Kujutame nüüd ette olukorda, kus ohver alustab serveriga sessiooni nii, et kliendituvastust veel ei nõuta. Kommunikatsioonikanalil asuv ründaja aga varastab selle sessiooni ning asub suhtlema ohvri eest. Peale SSL ühenduse saavutamist teeb ründaja päringu, mille täitmiseks server nõuab kliendituvastust. Hakkab toimuma ümberleppimine, ründaja annab nüüd „otsad ära“, vahendades pakette edasi-tagasi, ja laseb ohvril sooritada kliendi autentimise. Peale edukat autentimist on aga serveril kohustus täita esitatud päring (mida ründaja tegi). Päringu tulemused kuvatakse muidugi ohvrile, ründaja neid enam ei näe.
Tüüpiliselt kasutatud näide on see, kui ohver on näljane ning teeb päringu:
GET /pizza?täidis=kana?aadress=Kana8 HTTP/1.1
Cookie: minuküpsis
Singilembeline ründaja aga topib selle päringu ette paar rida (ilma reavahetuseta lõpus) ja tulemus on:
GET /pizza?täidis=sink;aadress=Kurja3 HTTP/1.1
X-Ignore-This: GET /pizza?täidis=kana?aadress=Kana8 HTTP/1.1
Cookie: minuküpsis
Tulemuseks saab ohver jahmatava kinnitusteate väärastunud soovi kohta, kurjam aga võib palvetada (kuna ta serveri vastust ei näe), et kunagi tasuta pizza tuleb. Rohkem ründaja selles seansis osaleda ei saa.
Paneme tähele, et sellise ründe edukus sõltub mitmest asjaolust:
- Ründaja peab asuma ohvri ja serveri-vahelise kommuikatsioonikanali vahel, s.t. ründajal peab olema kontroll mõne marsruuteri või tulemüüri üle ning olema võimeline manipuleerima seal infovooge. Lihtsalt ohvriga samas kohtvõrgus viibides võiks see ka teoreetiliselt võimalik olla kuid praktikas on rünne kohtvõrgust väga väikese õnnestumise tõenäosusega.
- Server aktsepteerib GET-päringuid, mille esmakordse töötlemise tulemuseks on kohe reaalne tegevus (s.t. pizza pannakse teele).
- Server peab olema konfigureeritud nii, et ta suhtleks nii ID-kaardiga autendituna kui ka ilma ning seetõttu SSL ümberleppimine on võimalik.
Kokkuvõtteks võib öelda, et ajalugu on näinud palju hullemaid SSL turvaauke, kummatigi pole maailm veel kokku vajunud ning tundlikud e-teenused eksisteerivad edasi. Eriti paranoilistele e-teenuste pidajatele võiks aga soovitada seda, et ID-kaardi autentimist kasutav e-teenus asuks eraldi IP-aadressil ning kliendituvastus oleks konfigureeritud kohustuslikuks. Võib-olla kaalub 100% turvalisus (antud puuduse mõttes) üles kasutaja frustratsiooni, kes autentimise ebaõnnestumise korral browser error’i saab.
Teeks ühe asja veel selgeks: tegemist on HTTP taseme veaga, mitte SSL’i veaga. SSL/TLS ei tea sellest midagi, mida HTTP serveri implementatsioon teeb või ei tee.
TLS — transport layer security
HTTP — application layer stuff.
SSL’i kasutatakse oluliselt laiemalt, kui HTTP turvamiseks ehk HTTPS’i jaoks.
Või kuidas?
Selle jutu oleks võinud keegi teine, sõltumatu osapool kirjutada. Antud kontekstis kõlab see kui müügiosakonna või PR osakonna meeleheitlik appikarje, et ärge muretsege, meie toote, ID kaardiga, on veel kõik korras.
Mispoolest sõltumatus SSL-turvaaugu olemust paremini seletada aitaks? Kui kanalisatsioonikaev geisrina purskama hakkab, küsitakse ikka Tallinna Vee käest, mis jama on.
https on siis tavaliselt pordi 443 või 4430 peal ja http 80 või 8080-
kui arvuti laseb end serverile tuvastada id ja https ning hiljem jääb ainult pordi 80/http peale, siis mängivad ainsat rolli küpsised arvutis.
Kurjam peab saama audenditud küpsise ja sessioonil on oma kindel ajaline pikkus.
kui https-i peale jäädakse kogu kasutamise ajani (nt. pangad, jt.), siis on põhirõhk ssl sessiooni võtmete kindlusel. Küpsis ei oma nii suurt rolli.
Mida suurem krüpteerimine (nt. comodo 2048 bitine), seda raskem on sidet lahti võtta..
Ja muidugi head tulemüürid ei lase küpsist varastada http ja https puhul.
Aga kindlasti on libaruuter võimeline ssl algvõtmeid varastama ja id kaardi abil tehtud pangakontosi tühjendama..
Tavaliselt on aga need andekad mehed kõik vahele jäänud.
iga server ja automaat jätab mõne hea logini panka.
Kuidas see libaruuteris ssl võtmete varastamine siis käib?
Ma paneks kohe kogu tallinna kesklinna tasuta wifit täis ja asuks neid varastama ja pangakontosid tühjendama.
Ning milleks mulle üldse midagi pealt kuulata kui id kaardi puhul kasutatav RSA 1024bit on selline korra köhida ja lahti asi ning comodo 2048bit vaid pisut raskusi valmistab. Parem siis arvutan kohe ESTEID-SK 2007 salajase võtme välja ja annan ise selliseid idkaarte välja mida hing ihaldab. Võtan äripäeva rikaste nimekirja ette ja hakkan andma.
Õnn kaasa siis. Mis sa selle äripäeva rikaste rahaga peale hakkad? Kui palju sa välja võtma hakkad?
Kas võtad 1000, 10000, 100 000 või miljard?
Ilmselt oma kontole sa ülekannet teha ei saa.. võtad pangaautomaadist välja x kordades. Limiidid on peal.
Mis sa peale hakkad siis esimese miljoniga näiteks? Ostad maja ja ilusa auto või?
Kutsud sõbrad külla ja mis sa neile ütled ning kas ka alkoholi võtate? Ütled, et võitsid bingoga?
Pärast ütled, et aktsiate tehingutega?
Ilmselt käid mitme naisega ja ostad neile kalleid kleitesi.
Kergelt tuleb, kergelt läheb!
Varsti on hea onu sul ukse taga.
Sinu suhtumisest järeldan..
Milleks diskuteerida laiasõnaliselt raha kulutamise võimaluste üle, kui see on veel kätte saamata.
Samas alles väitsid siin, et see on köki-möki. Nüüd ei kirjutanud sa selles teemas enam hiire piuksugi. Parem tunnista ülesse, et sa krüptograafiast suurt midagi ei tea ja lihtsalt ajad jama.
Selliseid mehi kes on tippspetsialistid günekoloogiast kvantfüüsikani on terve internet täis. Tehke inimkonnale teene ja ärge levitage oma sõnumit rohkem.
Mul pole vaja midagi tõestada ega ka alluda provokatsioonile. Kõik mida ütlen, võidakse kohtus tunnistada minu vastu.
Samas, igasugune süüdistamine enne kohut ja peale kohut on seadustega ja juriidiliselt selekteeritav.
Vajaduse korral saan miljonäriks juba ” minu laimamise” eest.
“kasutaja frustratsiooni, kes autentimise ebaõnnestumise korral browser error’i saab”
Samas rõõmustavad need kasutajad, kellel on Firefox ja kes vahel ikka unustavad ID-kaardi enne “login” nupu litsumist sisse pista.
See jutt, et sert ei tohi olla seadetes kohustuslik on Eestis kõik mitte-IE brauserid lootusetult katki teinud, aga herr Martens kuulutab ikka oma mantrat, kuna tema jaoks on maailmas ainult
Internet Explorer ja selle pooletoobised kasutajad, kes ei tule selle
peale, et kui kaardiga on mingi erros, siis võiks esimese asjana vaadata kas kaart on lugejas.