kolmapäev, 28. oktoober 2015

Miks STARTTLS on paha?

STARTTLS on meetod kliendi ja serveri vahelise turvamata ehk vabatekstilise ühenduse üleviimiseks krüpteeritud ühendusele. Klientrakendus saadab sellisel juhul serverile käsu STARTTLS (või STLS või kuidas iganes käsu nimetus juhtub olema), server aktsepteerib seda, seejärel toimub tavapärane võtmevahetus ning edasi liiguvad kõik andmed juba krüpteeritud kujul. Kõige rohkem kasutatakse seda e-posti protokollides (SMTP, IMAP, POP3), kuid ka mujal (XMPP, LDAP jne.). Tundub nagu päris hea idee või mis? Kõik me ju armastame krüptot?

Noh, ei ole hea idee. Tegu on järjekordse sea-selga-sadul lahendusega. Kõigepealt oli meil siga ehk mingi hästi toimiv vabateksti protokoll, seejärel avastasime, et oleks vaja kuidagi kasutada ka krüpteeringut ehk sadulat, paneme nüüd kaks asja kokku ja ongi hobune. Oleks nagu seesama vana vabateksti protokoll, kõigest pisikese laienduse lisamise abil saame edaspidi andmeid edastada krüpteeritult, segamata seejuures vanade rakenduste tööd, mis krüpteeringut kasutada ei mõista.

Mida siis STARTTLS võrreldes täielikult krüpteeritud ühendusega meile praktikas annab? Ükski normaalne ("normaalne" ei ole kahjuks sama, mis "kõik") server ei luba tänapäeval kasutajal edastada paroole üle turvamata ühenduse. Selline autentimiskatse blokeeritakse mõistlikult seadistatud serveri poolt üsna kiirelt. Mida aga saab teha autentimata serveris? Tuleb välja, et ei saagi suurt midagi (välja arvatud muidugi MTA serverid, millest tuleb juttu allpool). Näiteks nii SMTP kui ka IMAP puhul on autentimata olekus lubatud vaadata vaid serveri poolt toetatud laiendusi (SMTP puhul näitab neid EHLO käsk, IMAP puhul CAPABILITY), samas IMAP serverid näitavad autentimata olekus tihti vaid neid laiendusi, mida on vaja otseselt autentimiseks, seega ei ole sellest infost suurt kasu.

Võrdleme näiteks Apple iCloud IMAP serveri CAPABILITY väljundit:

Autentimata olekus:
* NK11P00MM-ISCREAM001 14F39 XAPPLEPUSHSERVICE IMAP4 IMAP4REV1 SASL-IR AUTH=ATOKEN AUTH=PLAIN
Autenditud olekus:
* XAPPLEPUSHSERVICE IMAP4 IMAP4REV1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT SORT CATENATE URLAUTH LANGUAGE ESEARCH ESORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES CONDSTORE ENABLE CONTEXT=SEARCH CONTEXT=SORT WITHIN SASL-IR SEARCHRES XSENDER X-NETSCAPE XSERVERINFO X-SUN-SORT ANNOTATE-EXPERIMENT-1 X-UNAUTHENTICATE X-SUN-IMAP X-ANNOTATEMORE XUM1 ID IDLE
Ühesõnaga, juhul kui meil on võimalik valida algusest peale krüpteeritud ühenduse (IMAP puhul siis IMAPS pordil 993) ja algselt vabatekstilise, kuid STARTTLS abil krüpteeritud olekusse üleminekuga ühenduse vahel (IMAP puhul siis pordil 143), siis STARTTLS ei anna meile praktikas mitte mingisugust eelist, küll aga teeb lahenduse keerulisemaks. Mis viibki meid järgmise punkti juurde.

STARTTLS implementeerimine tarkvaras

Ilmneb, et vabatekstiliselt ühenduselt krüpteeritud ühendusele üleminek ei olegi nii hästi programmeerimiskeelte ja teekide poolt toetatud kui võiks arvata. Halval juhul pole seda võimalust üldse (valida on kas vabateksti või krüpteeritud ühenduse vahel, kuid mitte hilisema muutmise vahel), veidi paremal juhul on see küll võimalik, aga implementatsioon võib olla bugine (sest see on keeruline ning harva vaja minev featuur). Eriti halval võimalusel, nagu veel suhteliselt hiljuti oli Chrome brauseri laienduste jaoks mõeldud chrome.socket API puhul, on ainult vabateksti võimalus ning krüpteeritud ühenduste loomise võimalus puudub sootuks. Kui programmeerimiskeele teegid üleminekut ei võimalda, on alternatiivselt võimalik SSL/TLS kiht ise implementeerida (lõppude lõpuks käib kõik ju üle sellesama tcp ühenduse, ainult vorm muutub), aga selle tulemuseks on algselt ühe probleemi morfeerumine umbes kuueks tuhandeks veel suuremaks probleemiks ja seega on see kõige viimane tee üldse, mida mööda minna.

Turvaprobleemid

Kui algusest peale krüpteeritud ühenduse puhul on kõik selge, me kas kasutame krüpteeringut või me lõpetame töö, siis üleminekuga ühenduse korral pole kõik sugugi nii ühene. Vaatame näiteks niiöelda tavalist STARTTLS kasutusjuhtu:

Joonis 1. Klient läheb serveriga suheldes üle krüpteeritud ühendusele


Kõik on lihtne ja selge. Klient näeb võimalust STARTTLS kasutamiseks ning läheb üle krüpteeritud ühendusele. Vaatame nüüd veidi keerulisemat juhtu:

Joonis 2. Kliendi ja serveri vahel olev MITM peidab STARTTLS võimaluse ning klient jääb kasutama vabatekstiliselt ühendust

Siin on asjad juba vähem selged. Seekord ei ühendu klient mitte autentse serveriga, vaid MITM ründaja serveriga (selline olukord võib igapäevaelus tekkida näiteks siis, kui ollakse parasjagu ühendunud mõnda "tasuta" wifi võrku, mille ruuteris olev DNS server saadab kõik ühendused ründaja serverisse). MITM server muutub siinkohal passiivseks proksiks, kuid kõigepealt avab ta tegelikku serverisse turvatud ühenduse, kliendile esitab aga andmed nagu server ei toetakski üldse krüpteeringut. Klient läheb seepeale turvamata ühendusega edasi (ühtegi reeglit pole ju rikutud), server aga omakorda arvab, et ühendus on krüpteeritud ja kõik korras.

Protokollilised probleemid

Ütleme, et meil on MTA server, mis soovib edastada kirju meie jaoks tundmatusse MX serverisse A. Avame vabatekstilise ühenduse serverisse A pordil 25, saadame oma EHLO ja vastu saame info, et server toetab STARTTLS laiendust. Väga tore, algatame ülemineku. Nüüd aga tekib tõrge, serveri nimi on A, kuid sertifikaat on nimele B või on see aegunud või on see ise-allkirjastatud, ühesõnaga – sert on vigane. Mis teha?

Juhul kui me eeldaksime, et ühendus peab olema kindlasti krüpteeritud, siis tekiks siinkohal veaolukord ja kiri jääks edastamata. Kuid STARTTLS puhul ei ole asjad nii lihtsad. Liiklus pordil 25 ei ole mõeldud olema krüpteeritud, seega vabatekstiliste andmete edastamine oleks nagu OK. Vigane sert võib tähendada MITM'i ja sellise ühenduse kaudu andmete edastamine nagu ei oleks OK, vastasel korral ei oleks ju krüptost mitte mingit kasu.

RFC2595, mis käsitleb STARTTLS implementeerimist, on lahendanud asja muidugi geniaalselt:
The decision about whether acceptable authentication or privacy was achieved is made locally, is implementation-dependent, and is beyond the scope of this document.
Praktika

Teoorias tundub asi päris kole, aga kuidas on praktikas? Praktikas on veel koledam. Lisaks võimalikele küberkollidele kasutavad sarnaseid krüpto mahajooksmise võimalusi ka täiesti legaalsed ettevõtmised, näiteks suured mobiilifirmad. Tavaliselt tehakse seda nii, et filtreeritakse ridu kujul "250-STARTTLS". Selline rida jäetakse üldse välja või asendatakse see näiteks reaga "250-XXXXXXXA". Tulemuseks on see, et klient ei näe serveri pakutud võimalust krüptole üleminekuks ja jääb vabatekstilisele ühendusele. Eelkõige on see probleem pordil 25 olevate MTA serveritega, mitte niivõrd 587 MSA serveritega. Seega ei oota server ka autentimist ning muudatus ei tule kunagi välja. Võrguoperaator aga saab nii vabalt jälgida oma võrgus toimuvat meililiiklust.

Lisaks ISPidele tegelevad sama asjaga kohati ka terved riigid. Näiteks hiljutise Google'i e-posti turvalisuse teemalise uuringu järgi blokeeritakse Tuneesiast Gmaili serveritesse tehtavatel ühendustel tervelt 94% juhtudest STARTTLS kasutamine.

Mis on kogu jutu mõte?

Kõik algas sellest, et aastal 1997 registreeriti IANA port 465 protokollile SMTPS ehk krüpteeritud SMTP. Juba aasta pärast võeti see aga tagasi, sest vahepeal oli välja mõeldud STARTTLS, mis tollal tundus kõikide murede lahendaja – selmet registreerida kaks porti, üks vabateksti ja üks krüpteeritud ühenduse jaoks, võis registreerida vaid ühe ja teha mõlemat. Seega aastast 1998 ei ole enam sellist asja nagu SMTPS pordil 465. Sellel pordil asub täna hoopis protokoll nimega URL Rendesvous Directory for SSM. Elu teeb siiski omad korrektiivid ja suur osa SMTP serveritest, sh. ka oluliseimad nagu Gmail, toetavad endiselt (ehk siis juba 17 aastat peale ametliku toe lõppemist) krüpteeritud ühendust pordil 465. See on üks suuri vastuolusid reaalsuse ja paberil kirjas oleva vahel ja ilmselgelt on seal ka põhjus – nimelt STARTTLS on halb, kasutada tuleks krüpteerimist juba baidist nr 1. ning mitte oodata kuni mõni MITM meie ühenduse ära rikub.



Lisalugemist

Kommentaare ei ole: