Möödunud aasta mais, kirjutas Jaanus Kõiva MicroFonis SSL-kihis avastatud veast ja selle mõjust ID-kaardiga autentimisele. Paraku – nagu paljude asjadega, mis ennast otseselt ei puuduta – siis suure hooga tegelema ei tormanud. Nii sujus kõik ilusti selle hetkeni, kui möödunud aasta talve alguses avastasime üllatusega, et osa kasutajatest ei saa meie keskkondades end ID-kaardiga autentida.

Probleemi analüüsides selgus, et see ilmneb väga erinevatel brauseritel ja platvormidel ning lisaks kõigele, n.ö magustoiduks, esines muid SSL-kihist tulenevaid vigu täiesti suvalistes kohtades. Näiteks nägid väga paljud kasutajad aeg-ajalt oma ekraanidel veateateid kujul:
• ssl_error_rx_unexpected_new_session_ticket
• ssl_error_rx_unexpected_change_cipher
• handshake failure (üldine FF veateade, mille alla võib sattuda enam-vähem kõike)

Veel teravamaks tegi probleemi see, et veateated tekkisid suvalistes kohtades ning kadusid ära refreshiga. Logide järgi oleksid kasutajad nagu käepigistuse erinevatel hetkedel vastamata jätnud. Ka Google ei olnud eriti sõnarohke, sealt võis leida vaid paar sama teemaga vaevleva kolleegi postitust, mis paraku olid ka vastuseta. Seega olime olukorras, kus pidime midagi ise välja mõtlema ning oma ideid ja eksperimenteerimise tulemusi jagangi siin artiklis.

Miks üldse hakata midagi välja mõtlema?

Viidatud artiklist loeb välja nii probleemi püstituse kui ka selle lahenduse. Vastus on lihtne: kuna algse probleemi juurtest lugedes, ei taibanud ma esimese hooga ära, kuidas SSL hosti ID-kaardi jaoks eraldi tõstmine probleemi lahendab, otsustasin teema endale selgeks teha ning protsessi käigus tulin veidi teistsugusele lahendusele.

Lisaks sellele pakutakse ühe kõige levinuma lahendusvariandina SSL-sessiooni taasjätkamise (renegotiation) ärakeelamist, mis minu vaatenurgast ei ole väga korrektne, ning näiteks uusima põlvkonna Firefox 4 (hetkel beta siiski) brauseritega selline lähenemisviis ei tööta. Muidugi on esialgse artikli avaldamise ajast ka omajagu aega möödas, ning mõningad asjad on nüüdseks juba muutunud.

Aga alustan algusest – probleem (nagu me saame vastavast RFC-st välja lugeda) seisneb selles, et SSL-sessiooni taasjätkamise (renegotiation) protseduuris peitub kolmanda osapoole jaoks võimalus märkamatult süstida suvalisi andmeid.

Taasjätkamise keelamine

OK, mis siin ikka, keelame sessiooni taasjätkamise ja asi töötab? Sellise sisuga OpenSSL patch tuli välja peagi pärast esialgse probleemi avastamist ja paljud seda ka rakendasid. Iseenesest üsna loogiline, kuid sessiooni taasjätkamine (renegotiation) on oma loomult täiesti legaalne ja vajalik protsess. Iseasi, et selle implementatsioon oli veidi ebaturvaline (tunnistame ausalt, et nagu enamiku MiTM rünnakute puhul, on see pimesi mängimine ja selle vea edukas ärakasutamine reaalsetes tingimustes kuulub väga suure vedamise ja müstilise intuitsiooni rubriiki). Siiski on SSL-sessiooni taasjätkamine vajalik protsess, ja näiteks ülalpool mainitud Firefox 4 beta sertifikaadiga autentimist ilma selleta eriti teha ei taha, vähemalt mitte vaikimisi konfiguratsioonis. Diskussioon teemal kummal poolel on õigus ja kas sessiooni taasjätkamine on õige tegu, on siinkohal skoobist väljas.

Kuidas eraldi SSL hosti tõstmine probleemiga haakub?

Sama küsimus vaevas ka mind. Aluseks on võetud fakt, et SSL-sessiooni taasjätkamine toimub enamasti juhtudel, kus kasutaja liigub sertifikaadiga autentimist nõudva tsooni ja muu veebi ressursside vahel. Sellest ka loogiline järeldus: tõstame kasutaja sertifikaadiga autentimise eraldi SSL hosti ja taasjätkamist ei toimu.

Üsna loogiline lähenemine, kuid sõltuvalt serveri konfiguratsioonist võib sessiooni taasjätkamine toimuda ka real muudel juhtudel ja tingimustel, ning toimubki. Seega kogu probleemi see lähenemine ei lahenda, ning kui brauseri ja serveri vahel sessiooni taasjätkamisel tekkivad möödarääkimised – seisame taas silmitsi sama probleemiga. Nii juhtus ka meil.

Lahendus

Natuke mõeldes ja debuggeriga mängides jõudsin aga ka lahenduseni.
Me mängisime sama stsenaariumi läbi kahte tüüpi Linuxi masinates, ühe pardal jooksis värske Gentoo, ning teine jooksutas RHEL 5.0, mõlemal oli Apache HTTPd veebiserver, seepärast on ka konfiguratsiooni näited Apache HTTPd kohta.

1) Samm 1: Uuendada OpenSSL.
Enamik ülalpool loetletud veateateid SSL ühenduse ajal on tingitud OpenSSL versioonist. Versiooni uuendus kuni >=1.0-ni Gentoo peal likvideeris kõik random-sisuga SSL-sessiooni vead. Miinuseks on see, et OpenSSL >=1.0 versiooniga enamik legacy pakette nii lihtsalt ei kompileeru, millest küll teatud näpuosavusega üle saab. RHEL 5.0 peal on lahendus veidi lihtsam ning samade vigade parandused on backport’itud 0.9.8e-12.7 versiooni RedHat patchide abil. Seega enamikul MicroLinki klientidel peaksid need probleemid juba kadunud olema.

2) Samm 2: Apache konfiguratsiooni muudatused.
Esialgsest probleemi avaldamisest on omajagu aega möödas, ning versioonis 2.2.15 on Apache foundation lisanud mod_ssl paketti sessiooni taasjätkamise juhtimiseks mõeldud direktiive. Seega pidime vähemalt versioonini 2.2.15 oma Apache’i uuendama.
Gentoo puhul – portage’ist tõmbamine RHEL’iga – on asjad samuti tunduvalt lihtsamad ning vajalikud muudatused on juba backport’itud tööka RedHat tiimi poolt viimasesse RedHat repo’st saadavasse mod_ssl distributsiooni.

Konfiguratsiooni muudatused:

1) Keelame ära SSLv2 protokolli.
SSL v. 2 on oma loomult arhhailine ja vana protokoll, mille kasutamine on juba pigem iganenud. Selle asemele on ligi 10 aastat tagasi tulnud SSL v. 3 ja TLS v. 1. Kuidas teemaks olev probleem avaldub SSL v. 2 protokolli puhul ma ausalt öeldes ei uurinud – ja kuna tegemist on üsna vana, oma aja ära elanud protokolliga, ei olnud ka erilist indu seda uurima hakata. Kõige loogilisem ja lihtsam lahendus tundus see lihtsalt ära keelata.

Näiteks niimoodi:
SSLProtocol -All +TLSv1

Ja neid kasutajaid, kes siiani kasutavad SSL v. 2, saab lihtsalt ümber seadistada. Ma usun, et tänapäeval pole kliente, kes ei toeta SSL v.3 või TLS v.1.

2) Keelame ajutiste Diffie-Hellmann võtmetega sessioone.
See on üks huvitav eripära, mille avastasime teatud Mozilla Firefox versiooni brauserite puhul, kus (erinevalt konkurentidest) initsieeritakse enne kasutaja sertifikaadiga autentimise alustamist võimalusel ajutiste Diffie-Hellmann võtmete vahetus. Üldjuhul jookseb see protsess siledalt, kuid umbes kolm korda järjest edasi-tagasi ID-kaarti nõudva tsooni vahel liikumisel lendab Mozilla Firefox välja “unexpected handshake alert” veateatega. Refresh aitab, samas aga on selge see, et selline eripära ei saa kellelegi meeldida.
Lahenduseks võib välja lülitada Diffie-Hellmann ajutiste võtmete võimaluse serveri poolt välja pakutavate algoritmide hulgast, ning seega sundida Mozilla’t kasutama tavapäraseid sessiooni ülestoomise metoodikaid. Näiteks võib kasutada järgmist direktiivi:

SSLCipherSuite !DH:HIGH

3) Lubame (eba-)turvalist SSL sessiooni taasjätkamist.
Nagu eelnevalt mainitud, on Apache HTTPd ja mod_ssl, alates versioonist 2.2.15 sisse toodud direktiiv SSLInsecureRenegotiation, mis sisuliselt annab võimaluse juhtida – kas lubada või keelata – ebaturvalise sessiooni taasjätkamise võimalust.
Selle võtme väärtus on iga serveri administraatori vaba valik. Esimene, mis pähe tuleb on “off”, mis oleks tehnilisest vaatenurgast ka õigem, kuid siin tuleb meeles pidada, et paljude meie kasutajate brauserid ei ole uuendatud ning selline muudatus võib neid üsna valusalt mõjutada ja mõjutabki.
Seega konkreetne otsus võtme väärtuse osas jääb pigem iga administraatori teha, lähtuvalt tema kasutajaskonnast.

4) Vähendame sessioonide taasjätkamiste arvu.
Apache mod_ssl konfiguratsioonis, lubatud SSLOptions’ite all on olemas selline tore võti nagu OptRenegotiate. See võti üritab minimiseerida sessioonide SSL taasjätkamiste arvu. Standardkonfiguratsioonis Apache mod_ssl üritatakse sessiooni taasjätkata väga paljudel juhtudel, s.h ka siis, kui seda otseselt ei ole vaja teha, selle võtme lisamine aitab vähendada nende juhtude arvu. Tõsi on ka see, et Apache soovitab tungivalt võtit globaalses kontekstis mitte kasutada, et vältida ootamatuid tulemusi. (SSL kihiga mängimine on üldse suuresti karu sabast tirimine, seega kuulaks siinkohal targemate meeste soovitusi.) Seega hea koht lisada sellist direktiivi on nt Location, või Directory osa meie ressursil, kus nõutakse sertifikaadiga autentimist, näiteks:

<Location /eid.jsp*>
SSLOptions +OptRenegotiate
</Location>

Seejärel, taaskäivitame Apache’i, ning meie ID-kaardiga autentimine töötab kõikides brauserites ja vanu probleeme ei paista olevat. Lisa IP aadress, SSL host vms ei ole vajalikud.