Tag Archives: openssl

Olulised turvanõrkused 2022. aasta 43. nädalal

OpenSSL-i teegis parandatakse kriitiline haavatavus

Eelmisel nädalal teatas OpenSSLi teegi arendaja, et 1. novembril ajavahemikus 15.00–19.00 (EET) avalikustatakse teegist uus versioon 3.0.7, mis paikab kriitilise turvanõrkuse (OpenSSL, ZDNET).

Arendaja hinnangul on nõrkus kriitiline, kui see mõjutab laialt levinud konfiguratsioone ja on tõenäoliselt ka ärakasutatav[1]. Lisaks hindab arendaja nõrkuseid kriitilise tasemega siis, kui nende abil on võimalik kerge vaevaga kompromiteerida serverite privaatvõtmeid või teostada koodi kaugkäitust.

Kes ja mida peaks tegema?

Kirjutamise hetkel ei ole teada, milles turvanõrkus seisneb, kuid see mõjutab OpenSSLi versioone 3.0.0 kuni 3.0.6.

Kuna turvanõrkus võib mõjutada paljusid erinevaid IT-süsteeme, tuleb süsteemide halduritel kindlasti kontrollida, kas haavatavaid OpenSSLi teeke kasutatakse. Kui jah, tuleb 1. novembril vastav uuendus kindlasti rakendada, sest tagajärjed võivad olla üsna tõsised.

Soovitame jälgida ka seda Githubi repositooriumi.

Kontekst: OpenSSL on teek, mida kasutavad näiteks veebiserverid sageli krüpteeritud HTTPS-ühenduste loomiseks. Meiliserverid ja VPN-protokollid (nt OpenVPN) kasutavad krüpteeritud sidekanalite loomiseks samuti OpenSSL-i. Teeki võib leida ka paljudest teistest toodetest.

Viimase kümne aasta jooksul on teegis olnud kaks tõsisemat turvaviga. Esimene avastati 2016. aastal ja see võimaldas süsteeme üle võtta ning nende tööd häirida.

Teine turvanõrkus pärineb 2014. aastast (CVE-2014-0160) ja seda teatakse IT-maailmas nimetusega HeartBleed. Viga mõjutas miljoneid veebilehti ja selle abil oli võimalik ründajatel varastada tundlikke andmeid (krediitkaardinumbreid, nimesid jne).

Apple paikas nullpäeva turvanõrkuse

USA tehnoloogiahiid Apple teavitas 24. oktoobril üldsust mitmetest turvanõrkustest, mis paigati uutes iOSi ja iPad OSi operatsioonisüsteemide versioonides. Üht olulisemat parandatud turvanõrkust nimetatakse tähisega CVE-2022-42827 ja see mõjutab nii iPhone kui ka iPade. Apple sõnul on üritatud seda turvanõrkust aktiivselt ka ära kasutada, kuid täpsemaid detaile ei ole ettevõte jaganud (BPAppleRIABP).

CVE-2022-42827 turvanõrkuse abil saab häirida rakenduste tööd või käivitada pahatahtlikku koodi, et saada kasutaja seadmes kõrgemad õigused tegutsemiseks: nii saab ründaja teoreetiliselt varastada seadmesse kogutud andmeid, teha kuvatõmmiseid süsteemist jne.

Kes ja mida peaks tegema?

Konkreetne turvanõrkus, lisaks paljudele teistele haavatavustele, on parandatud uuemate seadmete jaoks iOSi versioonis 16.1 ja iPadOSi versioonis 16.

iOS 16.1 või iPadOS 16 saab paigaldada järgmistele mudelitele:
iPhone 8 ja uuemad
iPad Pro (kõik mudelid)
iPad Air 3 ja uuemad
iPad viies põlvkond ja uuemad
iPad mini 5 ja uuemad

Vanemate seadmete puhul on turvaviga parandatud iOSi versioonis 15.7.1 ja iPadOSi versioonis 15.7.1.

iOS 15.7.1 või iPadOS 15.7.1 saab paigaldada järgmistele mudelitele:
iPhone 6s või uuemad
iPad Pro (kõik mudelid)
iPad Air 2 või uuemad
iPad viies põlvkond ja uuemad
iPad mini 4 või uuemad
iPod touch (seitsmes põlvkond)

Kui sinu Apple’i telefon või tahvelarvuti on andnud märku uuendamisest, palun tee seda esimesel võimalusel!

Google parandas uue nullpäeva turvanõrkuse Chrome’i veebilehitsejas

Google avalikustas Maci, Linuxi ja Windowsi operatsioonisüsteemidele Chrome’i uue versiooni 107.0.5304.87, milles parandati üks kõrge tasemega haavatavus (CVE-2022-3723). Nõrkus peitub Chrome’i V8 JavaScripti komponendis ja ründaja saab seda teoreetiliselt kasutada näiteks andmete lugemiseks teistest rakendustest. Google on teadlik, et nõrkusele on olemas eksploit (nõrkust ärakasutav programm) (DRCR). 

Kes ja mida peaks tegema?

Kui te kasutate Chrome’i veebilehitsejat, uuendage see esimesel võimalus. Juhised uuenduste installeerimiseks leiate siit.

Cisco hoiatab kahest turvanõrkusest, mida taas kuritarvitatakse

Cisco hoiatas oma kliente turvavigadest Cisco AnyConnect Secure Mobility Client for Windows tarkvaras. Turvanõrkused avastati juba 2020. aastal (CVE-2020-3433 ja CVE-2020-3153), kuid neid on viimasel ajal hakatud taas aktiivselt kuritarvitama. Mõlema turvanõrkuse kuritarvitamiseks peab ründajal olema süsteemile autentitud ligipääs (BP).

CVE-2020-3433 (7.8/10.0) nõrkuse põhjuseks on ressursside ebapiisav valideerimine, mida rakendus töötamise ajal laadib. Ründaja võib seda nõrkust ära kasutada, saates AnyConnecti protsessile spetsiifilise IPC (interprocess communication) sõnumi. Edukas ärakasutamine võib lubada ründajal käivitada mõjutatud masinas suvalist koodi süsteemiõigustes.

CVE-2020-3153 (6.5/10.0) haavatavus võimaldab ründajal kopeerida faile süsteemikataloogidesse. Haavatavuse põhjuseks on kataloogiteede (directory path) ebakorrektne käsitlemine.

Kes ja mida peaks tegema?

2020. aastal väljastati turvanõrkustele parandused ning kui te ei ole mõjutatud tarkvara siiani paiganud, soovitame kindlasti esimesel võimalusel tarkvara uuendada. Informatsiooni haavatavate versioonide kohta leiate ametlikelt tootja veebilehtedelt, millele on viidatud ülal.


[1] https://www.openssl.org/policies/general/security-policy.html

RIA analüüsi- ja ennetusosakond

Kroomitud teras

Autor: Anto Veldre, RIA analüütik

Selle suve lõpp saab olema äkiline – juhtub see, mida oleme juba pea kaks aastat vastutuult ennustanud: et ühel heal päeval keerabki Google sirviku Chrome kruvid koomale ega lase ID-kaardiga e-teenusesse isikuid, kelle kaardile on sattunud iluvigased sertifikaadid.

Millenniumlaste põlvkonnale, kes üle ühe nühvliekraanitäie korraga läbi lugeda ei täi, ütleme seetõttu kohe ära – eID pruukimiseks netis leidub ometi ju ka muid sirvikuid peale Chrome’i!

Kas see teema mind üldse puudutab?

Esimene ja kõige tähtsam küsimus – kas uudis puudutab kuidagi just mind? Küsimus on oluline, sest sertifikaadiuuenduse eelmine teavituslaine tõi meie telefonide otsa 70-aastased prouad, kes kartsid, et nende ID-kaart olla ehk tagaselja kehtetuks tunnistatud. Ei midagi säärast! Füüsiline ID-kaart ja elamisloakaart kehtivad isikut tõendava dokumendina kenasti edasi, mõningased seiklused puudutavad üksnes kaardi kasutamist Internetis.

Lakmusküsimus: kas Sina tarvitad oma ID-kaarti Internetis mõnesse e-teenusesse sisenemiseks? Viisil, et internetisirvik (brauser) küsib Sinu käest PIN1 või PIN2 koode? Kui JAH, vaid siis loe edasi, igal muul juhul mine ja naudi kena hilissuve, kuniks säärane veel kestab!

Aga … ma ju kasutan ID-kaarti elektrooniliselt! Pistan seda lugerisse Prismas, Apollos ja Olerexis? Tõepoolest, elektrooniliselt küll, aga PIN-koode seal üldjuhul ei nõuta ja sirvikust Chrome pole kassaterminalis lõhnagi, ehk siis – endiselt mine ja naudi vananaistesuve!

Tallinna Deed vs Chrome 61

Kord kodulinn Tallinnat pidi ringi jalutades leidsin liiklusmärgi aluse koos kivisse valatud kirjaveaga:

Pilt: http://tallinncity.postimees.ee/1262796/dalentide-linn-dallinna-deed

Raske tagantjärele oletada, kuidas säärane valuaps läbi lipsas, kuid üks on selge – liiklusmärki hoiab vigase kirjaga post püsti täpselt sama turvaliselt kui mistahes muu kirjaga post.

Oleme varem pikalt kirjeldanud (siin ja siin), kuidas nn negatiivse mooduli viga üldse tekkis, kuid üldiselt on tegemist samalaadi veaga, kui “Tallinna Deed”.

Igatahes on nüüd asjalood sedakaugel, et 5. septembrist 2017 laaditakse sirviku Chrome kasutajatele arvutisse uusversioon numbriga 61. Millega seoses, kui kasutaja isikusertifikaadid on iluvigadega nr 532048 ja/või 534766, siis paneb Chrome oma karvase käe vahele ning väljastab tehniliselt täpse, kuid sisult täiesti mõttetu veateate: „ERR_SSL_CLIENT_AUTH_CERT_NO_PRIVATE_KEY“. Enamike kasutajate jaoks on see hiina keel, sama edukalt võiks öelda: Böö!

Ah jah – keegi pole vigase sertifikaadiga karistanud just Sind isiklikult. Enne oktoobrit 2015 toodetud kaardid vastasid kenasti tollasele arusaamale kvaliteedist. Tõlgendus, nagu ka Google’i firma hinnangud, on muutunud normaalse arengu käigus. Alates oktoobrist 2015 väljastatud kaardid on igati korras ka tänase tõlgenduse kohaselt. Seejuures ei saa me välistada, et mõne aasta pärast leitakse puudujääke või arenguvõimalusi tänastelgi kaartidel…

Mis saab edasi?

Kuidas täpselt ja mis ulatuses uuendamata sertifikaatide teema Sind puudutab? Kuna Chrome’i turuosa sirvikute seas on suurusjärgus 70% ja ülalnimetatud kahest bugist jätkuvalt puudutatud kaartide kogus on umbes 270 000, siis päris paljudel inimestel tasuks siinkohal süveneda. Sest nüüd võib Sul tekkida väga konkreetne mure.

KUI Sinu isikusertifikaatides esineb mainitud viga NING Sa üritad pärast 5. septembrit 2017 Chrome’i uue sirvikuga (v61) mõnda e-teenusesse siseneda (mis nõuab PIN1), SIIS ajab uus Chrome sõrad vastu. Sa ei saa siis enam oma ID-kaardiga siseneda ei netipanka, eKooli, eesti.ee portaali ja kes kõik teab, kuhu veel. Küll aga on tehtud poliitiline otsus, et e-hääletamine sügisestel KOV valimistel on igal juhul võimalik (ja liiatigi veel turvaline ka).

Hetkel käibel olevad ID-kaardid (elamisloakaardid, digi-ID ja e-residendi kaardid) jagunevad kolme suurde kategooriasse, mis on pildil tähistatud värvidega: punane, sinine ja roheline.

Tuleb vaadata oma kaardi väljastamise kuupäeva (trükitud kaardi tagaküljele) ning selle alusel liigitada oma kaart ühte järgnevast kolmest grupist.

I – PUNANE – kaart on väljastatud enne oktoobrit 2014. Oluline on teada, milline iganes on Sinu olukord, kaardi endaga tegelemiseks on praegu juba hilja (mäletad ju, neid sai uuendada vaid 1. juulini 2017). Sinu valik – kas lähed võtad oma raha eest PPAst uue kaardi, sinna lisaks (kui veel pole) ka m-ID VÕI hakkad 5. septembrist Chrome’i asemel mingit muud sirvikut kasutama oma lemmikutesse e-teenustesse sisenemiseks. Muide, e-residentidele nii ammu veel kaarte ei väljastatud.

II – SININE – Sinu kaart on väljastatud vahemikus oktoober 2014 kuni oktoober 2015.  Erinevus PUNASE grupi sertifikaatidest – Sa saad endiselt sertifikaate uuendada. Selleks ava ID-kaardi haldusvahend ja vajuta nupule “Uuenda” (sertifikaate). Kui midagi ei juhtunud, siis kas polnudki vaja uuendada (kõik oli niigi korras või Sa läbisid uuenduse juba varem) või siis oli tegu mõne muu kaarditüübiga. Seega usalda ID-kaardi haldusvahendit – kui uuendamist oli vaja, siis see sooritatakse. Kuidas üle neti uuendamine täpselt käib, sellest loe siit (ja vaata juurde YouTube’ist õppevideot).

III – ROHELINE – Kui aga Sinu kaardil ilutseb väljastuskuupäevana oktoober 2015 või hilisem, siis on sertifikaatidega korras ning Sa ei pea mitte midagi tegema. Kui Sul sellegipoolest miski ei tööta, siis probleem võib mõnikord asuda ka ekraani ja tooli vahel, või väga harvadel juhtudel siiski ka konkreetses e-teenuses.

Allikas: http://knowyourmeme.com/memes/pebkac

Neile, kes armastavad pedantseid juhiseid, olgu siinkohal ära toodud ka otsuse tegemise voodiagramm:

Numeroloogia

Aktiivseid kaarte on eID ökosüsteemis hetkel arvel 1 294 653. Juuli lõpu seisuga leidus kaarte, mida oli viimase 12 kuu jooksul vähemalt ühel korral elektrooniliselt kasutatud, kokku 695 799.

Numbrid on esitatud seisuga 2017-07-01.

“A”-tüüpi kaarte ehk siis enne 2014-10-14 väljastatuid, jäeti kasutajate poolt lõpptähtajaks 2017-07-01 uuendamata 409 947. Selles koguses omakorda esineb Google Chrome’i v61 mõttes kriitilisi sertifikaadivigu 116 499 kaardil, millest vaid osa on kunagigi olnud elektroonilises kasutuses. Seega: reaalselt Chrome’iga kaklema hakkavate isikute arv on veel oluliselt väiksem. Oma “A”-tüüpi kaarte uuendati kokku 240 823 juhul, mistõttu saab öelda, et enamik tegelikest kasutajatest tegid ikkagi uuenduse ära. Muide: “A”-tüüpi kaardid aeguvad tempos ~20 000 kaarti igas kuus.

Edasi, “B”-tüüpi kaarte ehk siis neid, mida hakati väljastama pärast 2014-10-14, oli seisuga 2017-07-01 uuendamata jäetud 278 685, neist Google Chrome’i mõistes “iluvigadega” on 155 226, sh kaardid, mida pole eales e-kasutatud ega pigem hakatagi. “B”-tüüpi kaarte kauguuendati 54 015 juhul ning neid saab jätkuvalt uuendada.

Pisut teise nurga alt vaadates – kahe kaarditüübi peale kokku leidus (2017-07-01 seisuga) käibes 271 725 kaarti, mille üks või isegi mõlemad sertifikaadid Google Chrome’i v61-le ei meeldi (ning ilmneks see ikka vaid juhul, kui kaardiomanik tahab või tahaks selle sirviku kaudu mõnd internetiteenust pruukida).

  • Neist 116 499 juhtu jäävadki nurka konutama ja ravi puudub (kaarditüüp “A”, joonisel punased) sest kui isik enne 2017-07-01 oma sertifikaate ära ei uuendanud, siis pärast seda kuupäeva ta enam ei saagi, isegi mitte PPA teeninduspunktides. Eks need kaardid olegi varsti aegumas, nii et aitab PPAst uue kaardi tellimine ning mobiil-ID kasutuselevõtt.
  • Seevastu 155 226 kaardi puhul (kaarditüüp “B”, joonisel sinised) saab sertifikaate kenasti kauguuendada, pärast mida suudavad nad kenasti teha koostööd ka uue Chrome’iga. Lihtsalt uuendustoiming tuleb läbi teha.

Kokkuvõttes – nimetatud on MAKSIMAALSED arvud, mis ei arvesta tegelikku internetikasutust. Mingi osa inimesi pole oma ID-kaarti eales Internetis kasutanud, paraku puuduvad e-kasutuse kohta ka täpsemad andmed. Mõjutatud inimeste arv on seega oluliselt väiksem kui ülalnimetatud numbrid.

Kronoloogia

See peatükk on tehnikutele. Tavakasutajale võib nii detailirikas käsitlus jääda keeruliseks [Oluliselt täpsustatud 2017-09-01].

Praeguse Chrome’i juhtumiga on otseselt või kaudselt seotud järgmised tehnilised sündmused:

Teisisõnu – mida lugeda täiesti korras sertifikaadiks? Tänase tõlgenduse puhul on selleks pigem oktoobrist 2015 väljastatud sertifikaadid. Siiski ei saa päris välistada, et tulevikus tunnistatakse uuendamist vajavateks ka SHA-1 põhise vahesertifikaadiga (EstEID2011) tembeldatud isikusertifikaadid, millist teemat oleme varem käsitlenud siin. Mainitud asjaolu valguses saame öelda, et märtsist 2016 väljastatud sertifikaatidel pole teada ühtki, ka kõige pisemat teoreetilist probleemi.

Kaardipõlvkondade vahetus ei leidnud aset korraga, vaid järk-järgult. ID-kaardid läksid uuele platvormile üle esimesena – 16. oktoobril 2014. Digi-ID ja e-residendikaardid alustasid uue põlvkonnaga 01. detsembril. Ning lõpuks, 19. detsembril 2014 viidi kaardiplatvormile “B” üle ka elamisloakaardid.

 

Urinad ja jorinad

Q1 Miks minu kaarti garantiikorras välja ei vahetata?

A1 Sest tegemist pole tootmispraagiga, vaid välise olukorra muutusega. Sertifikaadid, mis varem olid täiesti asjalikud, omandasid globaalse turvaolukorra arengute ja suurfirmade valitud poliitika tõttu mõnevõrra teistsuguse turvahinnangu. OpenSSL vabavarapaketiga seonduvaid riske polnud võimalik ei ette näha ega salakavalate lepingutega katta.

Q2 Miks mulle varem teada ei antud?

A1 Tegelikkus on vastupidine – anti teada küll! Juba kaks aastat on nii siinses blogis – 1 –  2 – 3 – kui RIA kodulehe uudistes, lisaks avalikus meedias pidevalt räägitud vajadusest sertifikaate uuendada. Tegime kõik, mis meie võimuses, et inimesi uuendama suunata. Isegi YouTube’i õppevideod tellisime kolmes keeles.

Q3 No mul see ID-kaardi värk ikka ei tööta. On ikka niru tarkvara!

A3 Eesti ID-kaart ja kogu selle ökosüsteem on üks eesrindlikumaid terves maailmas! Võttes arvesse eelarve suurust ja kogu eID ökosüsteemi keerukust, on tegemist päris korraliku tootega. PEBKAC!

Kui Sinu probleem püsib, siis tuleb pöörduda IT-spetsialisti poole. Abi võib saada ka ID-kaardi tarkvara väga põhjalikest installijuhenditest siinsamas blogis – eraldi Macile, Linuxile ning loomulikult Windowsile.

Paraku pole Eesti-spetsiifilisel tarkvaral miljardeid kasutajaid nagu Gmail’il või Facebook’il, mistõttu mõni viga ehk ongi alles avastamata. Seega – palun rõõmusta meid ja ülejäänud kasutajaid ning anna oma muredest teada… näiteks abiliinil 1777.

Q4 Ma pole oma ID-kaardi tarkvara juba palju aastaid (3..4) kasutanud ja nüüd küll enam ei õnnestu tarkvara uuendada.

A4 Nii pikk paus on teadaolevalt probleemiks tõesti (Win, Linux) ja võib muuta ümberinstalli tavatult keeruliseks. Vajadusel pöördu IT-spetsialisti poole.

Probleem nr 532048

Anto Veldre, RIA analüütik

Google-Chrome-OS

Taust

Viimase viisaastaku turvaskandaalide iseloomulikuks jooneks on, et need ei määri. Kui 90ndatel tähendasid sissemurtud veebisait või äravarastatud isikuandmed ohvrile häbi ja alandust, siis täna murtakse veebisaite ja pätsatakse isikuandmeid kogustes, mis ei tekita erilisi emotsioone kelleski peale valdkonna eest vastutavate asutuste. Hane selga visatud solgiämber enam hane ei määri, sedavõrd sõltuv on meie ühiskond infotehnoloogiast 🙂

Ei sissemurd ega turvaauk tekita enam häbiseisundit – iga leitud probleem parandatakse ning seejärel läheb elu edasi nagu polekski midagi juhtunud. (Konservatiive ja puriste asjade säärane seis muidugi häirib, nende arvates tuleks iga vähegi suurem turvasündmus koos kuupäeva ja süüdlaste nimedega raiuda Maarjamäe memoriaali seinale.)

Kuid. Kui nüüd kõik ausalt ära rääkida, siis algas asi OpenSSL “turvalisusest”. Tänapäevased sirvikud vajavad sideturvalisuse tagamiseks vähemalt üht SSL (Secure Sockets Layer) teeki paljudest ning vabavaraline OpenSSL sobis selleks aastaid suurepäraselt. Mitmeid aastaid oli OpenSSL suisa turvalisuse etalon, laiad turvaringkonnad panidki juba võrdusmärgi SSL ja OpenSSL vahele, kuni aastal 2014 saabus HeartBleed. HeartBleed’i turvanõrkus osutas, et OpenSSL tarkvaraga ega ikka olnud asjad päris nii korras nagu võinuksid olla. HeartBleedist saadik on toimunud liikumine “tagasi lätete juurde”, ehk siis küsimusi, mida vahepeal 5–8 aastat polnud sobilik esitada, esitatakse taas. Ning üks neist küsimustest on – kas OpenSSL ikka on nii standardne ja kas kõik temaga seonduvad otsused olid ikka õigesti tehtud?

Liiga tehniliseks minemata mainime, et OpenSSL oli igasuguste teostusvigade suhtes küllalt andestav. Umbes nagu mõni reliktne netisirvik, mis algaja koolipoisi vigase HTML koodi ikkagi enam-vähem vaadatavaks veebileheks kokku renderdab. Täna jutukstulev tõlgendusvaruga asjaolu lisati koodile aastal 2000. Lojaalseid kasutajaid ei tohi ju ometi kaotada, ega ju? Parem andestav vanaema kui kuri ämm!

Kuivõrd jutt juba käibki internetisirvikutest, siis küberkuritegevuse tase ja sirvikuturbe küsimused on viimasel paaril aastal sundinud tootjaid ette võtma väga raskekaalulisi samme, näiteks välja vahetama kogu pluginate ökosüsteemi. Mistap 1. septembril 2015 üllitati sirviku Chrome versiooni nr 46 beeta ja see loobus muldvanast NPAPI tehnoloogiast. Pärisversioon (relaese) 46 saabub oktoobri keskel… ning kui meil siin Eestis teenuseomanik oma veebisaiti ümber ei tee, siis selle Chrome’i versiooni ja ID-kaardiga ega ikka enam ligi ei saa küll. Pluginamuudatuste juurpõhjus: et igasugused pahavarad ei saaks plugina kuju võtta ega sirviku küüru otsas elutsedes kasutaja andmeid varastada.

Sirvikutootjad on keeranud paar kraadi kangemaks ka suhtumist turvasertifikaatidesse. Väiksemagi kahtluse korral ei käsitle sirvik sertifikaati enam tõelisena. Varasemalt puudutas see pigem veebiserverite sertifikaate, kuid nüüd jõudis karmi käe poliitika ka kasutajasertifikaatideni. Et miks just Eesti puhul? Sest teistes riikides tavakasutajatel reeglina polegi mingeid sertifikaate. Eesti on suhtkoht ainuke riik, kus tädi Maalid kiipkaartidega ringi käivad, mujal kuuluvad kiipkaardid pigem riigiametnike ja sõjaväelaste varustusse.

Juhtum

15. septembriks 2015 sai selgeks, et uue Chrome’i karm käitumine ei piirdu sugugi pluginasüsteemiga. Ilmnes, et Google on kõvasti karmimaks keeranud sertifikaatide formaalset kontrolli. Kruvid keerati sedavõrd kinni, et pihta sai umbestäpselt mitusada tuhat Eesti ID-kaarti, digitaalset isikutunnistust ja mis seal salata, e-residendi kaarti – need ei pressi enam Chrome’i rangetest kasutustingimustest läbi ning veebisaiti sisse logida ei saa.

Et mis neil Eesti Vabariigi ID-kaardi peal paiknevatel sertifikaatidel siis nüüd viga on? Teadlased ütlevad, et moodul olla negatiivne … midaiganes see siis äraseletatult tähendab. Infoturbe teoreetikud räägivad midagi “võtme parsimisest ASN.1 kohaselt” ning et selles standardis olla kunagi ammu kokku lepitud, et moodul peaks olema positiivne. (Pisiasi, kuid tänast teemat mõjutab veel teinegi Google’i ticket – #534766.)

Tahaksin üles soojendada ühe toreda nõukaaegse sõna – formalism. Formalism on see, kui mingit nõuet täht-tähelt järgides kellelegi seadusetähega ära tehakse, samas kui tegelik probleem polegi teab kui suur. On mingi hulk standardeid, mis nõuavad, et … kuidas seda lihtinimesele selgitadagi, et sertifikaat algaks teatud kokkuleppeliste bittidega. Nii näiteks ITU standardid X.509, X.690 ning interneti standardid RFC 3280 ja RFC 5280 nõuavad, et teatudbitid kodaniku avalikus võtmes ja järelikult seda sisaldavas sertifikaadiski oleksid just “niipidi” ja mitte teistpidi – teisisõnu, moodul (modulus) peaks olema positiivne. Siinkohal olgu esitatud üks allikas, mis va “negatiivse mooduli” teemat pisut valgustab.

Mingit otsest turvaohtu neist miinusbittidest ei tulene. Bitte äraspidi sättides ei lange otseselt kellegi privaatsus ega konfidentsiaalsus ega leki kusagilt mingeid andmeid. Lihtsalt pole ilus standardit eirata. Esteetika ennekõike!

Olukord oleks umbes sarnane, kui Viru Valge pudelile trükitaks Eesti lipuvärvid tagurpidi – valge, must ja sinine. Ebameeldiv muidugi on, jututeemat jagub, kuid viina tegelikud omadused on ju sama head kui ennegi?!

Kes on süüdi?

Klassikud ütleksid – keskpärane uudis. Kuigi miski on väga valesti, siis tegelikus elus sellest suurt ei olene.

Formalistlikult arutledes on kõiges muidugi süüdi meie hea partner SK. On ju bittide säärane “valetõlgendus” vastuolus isegi nende enda majasisese standardiga – sertifitseerimispoliitikaga.

Seega vastus klassikalisele küsimusele – кто виноват? – on selle juhtumi puhul ette määratud. Iseasi, kui suur on see “süü” reaalses maailmas. Minul eraisikuna on SKst selle juhtumiga seoses suisa kahju – no oli seda mõttetut äpardust siis nüüd vaja?!

Samas, tähtsat tööd tegeva – usaldust müüva – ettevõtte puhul on formalism siiski õigustatud ning et asjad ikka tegelikult ka korras püsiksid, on ette nähtud mõned kontrollimehhanismid, näiteks regulaarne audit. Kuid oh õudust, selgub, et isegi korraline audit ei leidnud valepidi bitte sertifikaadist üles. Seega on tegu justkui suuremat sorti skandaaliga. Või otse vastupidi, just see tõestabki, et kui läheneda mitteformalistlikult, polegi nagu eriti midagi juhtunud – isegi audiitor ei märganud. Kas üldse keegi märkaski, enne kui Google oma sirviku Chrome kasutusnõuded pingule kruvis?

Kui analüüsida, et kuidas on säärane kisendav jõledus üldse võimalikuks saanud, siis otse loomulikult tänu OpenSSL “mõningasele tõlgendusvarule” – sest OpenSSL ju ei pidanud “teistpidi” bittidega sertifikaate vigaseks. Arvatavasti läksid selle populaaarse tarkvara õnge nii SK ise kui tema kõrgesti austatud audiitorid.

Kuidas üldse talitada olukorras, kus üks (lahedam) tarkvara väidab sertifikaadi olevat igati korrektse, teine (pidurim) tarkvara aga leiab üles standardi eiramise – sertifikaat viitab negatiivse mooduliga avalikule võtmele? Meenutan, et sertifikaadi tegelik turvatase ega ka ID-kaardi enda turvatase ei olene sellest tõlgendusest kuidagimoodi. Kontrollküsimus: kas inetu kirjaviga sel kivikamakal halvendab kuidagi kivi omadusi?

Formalistlikult lähenedes tuleks muidugi SK nii ränkraske rikkumise eest sundlõpetada ja ühtlasi ka ID-kaart kinni panna. 😉 Unistada ju võib … juhtumisi aga on meil siin reaalne e-riik ja formalismi hiilgeajad on jäänud N-Liidu ajastusse. Verd ja leiba sooviti näha juba vanas Roomas, kuid samas ID-kaardi ökosüsteem võiks ka mõnusasti edasi töötada … ma tõesti ei viitsi kaks tundi tööajast pangasabas või PPA teenindusbüroos elavas järjekorras seista. Kas Sina viitsid?

Lahendus

Kuupäev, kustmaalt jama algas, jääb 2014. aastasse. Vahepeal jõuti välja anda mitusada tuhat “sabaga” (miinusmooduliga) sertifikaati. Kui me just ei looda ülemaailmseid avalikke standardeid ringi teha, tuleb mainitud kogus sabaga sertifikaate nüüd uute (formaalselt õigemate) vastu välja vahetada. Selles tegutsemisviisis kahtlemine poleks vist mõistlik. Küsimus on, kuidas olukorrast välja tulla viisil, et kõigil oleks võimalikult vähem valus.

Esmane naiivne mõte oleks käsutada kõik pihtasaanud kodanikud ja mittekodanikud PPA teenindusbüroosse omi kaarte “värskendama”. Siis aga suureneks PPA büroode ühe aasta töökoormus kahekordseks. Eraldi pompöösne feil leiaks aset e-residentidega – meie riigi au ja uhkusega. Nemad peaksid uuendamiseks füüsiliselt Eestisse ilmuma … üksnes selleks, et kaardi peal paiknevaid sertifikaate uuendada … ning seda hetkel, mil me otse vastupidi, üritame e-residentide näonäitamise nõuet seadusest välja kirjutada.

Selgub, et massirändest palju parem tehniline lahendus juba sisaldub ID-kaardi spetsifikatsioonis – ka PPA teeninduspunktis oma ID-kaarti uuendades ei tehta ju tegelikult midagi muud kui pistetakse see pilusse, esitakse mõningaid võlusõnu ning – voilaa! – kaart saabki uuendatud. Täiesti ilmsetel põhjustel pole neid uuendusmehhanisme seni üldrahvalikult käsitletud, kuigi nende abil on teenindusbüroos ID-kaartidel sisu vahetatud küll ja küll. Ketserlik küsimus: kas ei saaks sama tegevust igaüks sooritada omaenda kodust? Aus vastus on, et no ikka saab, kui sedasi kokku leppida.

Kõigepealt olgu selge, et kõik toimuv on krüptograafiliselt tagatud ja turvaline. Lääne krüptograafiavastaste poliitikute ning e-riigi kriitikute märga unistust – universaalset tagaust stiilis “Seesam, avane!” Eesti ID-kaartidel kindlasti pole. Kuid teatud tingimuste täitmisel on siiski võimalik kaardi sees sertifikaate jms uuendada – muidu ei saaks ju kaarti uuendada isegi mitte PPA teenindusbüroos.

Seoses ilmse vajadusega veerand miljonit sertifikaati ära uuendada, ilmselt tehaksegi nüüd taas see kena kompromiss teoreetilise turbe ja kasutusmugavuse teljel – lubatakse isikul endal oma kaardi sertifikaate üle Interneti uuendada. Neile, kes ei mäleta – sertifikaadiuuenduse nupp oli varemalt tarkvaras olemas, vajadus nupu järele kadus siis, kui kaardi ja sertifikaadi kehtivus muutusid ühepikkuseks. “Üle interneti” tähendab siin aga seda, et ID-kaart astub turvakanali vahendusel ühendusse mõne spetsiaalselt selleks otstarbeks ette nähtud serveriga.

“Traatipidi” uuendamise võimalust on varem kaalutud korduvalt – siis, kui paljudel inimestel hakkas sertifikaatide tähtaeg korraga läbi saama ning ka siis, kui turvaelemendi vea tõttu kutsuti tagasi suur kogus ID-kaarte. Võimalik, et baastarkvara (ehk ID-kaardi utiliitide) järgmine versioon toetab “traatipidi” (online) uuendamise võimalust taas.

Kas säärane lahendus on turvaline? See on küsimus, mida on probleemi nr 532048 ilmnemisest saadik vaaginud mitmed tipptaseme turvaeksperdid. Sertifikaatide uuendamine toimub viisil, kus arvutit kasutatakse vaid sideliinina – ID-kaardi kiip suhtleb uuendusserveriga otse, läbi turvatud sidekanali. See aga tähendab, et isegi kui arvutis on kurivara, siis uuendatav krüptomaterjal ei ole ohus – kurivara ei suuda bitte vahelt haarata ega pealt kuulata (uuendamist takistada suudab küll, kuid siis on valikuks toimingu kordamine puhtas arvutis).

Last but not least – sama tehnotrikiga, mis sertifikaadid “traatipidi” ära vahetab, EI SAA päris kõike ID-kaardis sisalduvat siiski ära vahetada. Ammugi ei saa tehnotrikkidega muuta võõrast ID-kaarti enda omaks jne.