TLS pärandprotokollid ja TLS 1.3 mõju ID-kaardi kasutusele

Ardi Jürgens
Jaga:

Eelmises postituses kirjutasin PHP pärandvarast, täna teen juttu sarnasesse staatusesse jõudnud krüptograafilistest protokollidest. Täpsemalt tuleb jutt TLS (Transport Layer Security) protokolli versioonidest 1.0 ja 1.1, mis kinnitati standarditena vastavalt 1999. ja 2006. aastal.

Kui mäletate, siis eelmisel suvel arutasime Zone veebimajutusteenuse osas TLS versiooni 1.0 vaikimisi keelamist, kuna selle kasutamine ei vasta kehtivatele e-kaubanduse infoturbestandarditele (PCI DSS). Jätsime selle kasutamise kliendi otsustada. Järgmise sammuna lõpetame 1. aprillist 2019 oma veebimajutuses TLS versiooni 1.0 ja 1.1 vaikimisi toetamise. Lubame kliendil pärandprotokollide tuge ajutiselt ise “käsitsi” sisse lülitada.

Mõnedes ringkondades küsitakse, miks selliseid vanu krüptoprotokolle sellelgi moel veel toetada? Ka meile oleks palju lihtsam nende standardite toetamisest üldse loobuda, kuid reaalsuses sõltuvad tänagi mitmed meie kliendid seadmetest ja tarkvarast, mis valminud sajandivahetuse paiku või eelmisel aastakümnel ja nad vajavad üleminekuks aega. Samuti ei näita riskihinnangud nendes vanemates protokollides olevate nõrkuste reaalset ärakasutamist.

Globaalne progress on siiski meile ette andnud konkreetse tähtaja TLS 1.0 ja TLS 1.1 standarditest lõplikuks loobumiseks. Nimelt on suuremate veebilehitsejate arendajad teatanud, et brauseritest kaovad need versioonid lõplikult 2020. aasta märtsis. Võtame samuti selle tähtaja endale orientiiriks ja hiljemalt 2020. aasta märtsist ei saa TLS pärandversioone meie juures ka “käsitsi” sisse lülitada.

Aktuaalsete TLS versioonidena on meil täna toetatud TLS versioonid 1.2 ja osaliselt ka 1.3, mis on ametlikeks standarditeks saanud vastavalt 2008. ja 2018. aastal. Kuna viimase näol on tegemist verivärske standardiga, siis ei ole selle tugi veel kogu meie tarkvarasse jõudnud.

Mis toob mind ühe laiemalt teadvustamist vajava teema juurde. Nimelt selgus meil TLS 1.3 implementeerimise käigus huvitav asjaolu, mis võib lisaks meie klientidele mõjutada oluliselt kõiki Eesti internetikasutajaid:

TLS 1.3 standardi kasutuselevõtul lõpetab Eesti ID-kaardiga autentimine veebiserveri kataloogi tasandil töötamise!

Põhjuseks fakt, et suuremate veebilehitsejate tootjatest pole veel ükski juurutanud TLS 1.3 protokolli kätluse järgset autentimist (post-handshake authentication). Brauseritootjatel ei paista selle vastu olevat ka suuremat huvi – Chrome vastava bugiraporti leiab lehelt https://bugs.chromium.org/p/chromium/issues/detail?id=911653 ja Firefoxi oma https://bugzilla.mozilla.org/show_bug.cgi?id=1511989.

Sellest kitsaskohast saab ümber kahel moel:

• loobuda TLS 1.3 kasutamisest;
• viia ID-kaardiga autentimine kataloogi tasandilt üle veebiserveri virtuaalhosti tasandile.

Mõlemad meetodid on kirjeldatud Apache vastavas bugiraportis https://bz.apache.org/bugzilla/show_bug.cgi?id=62975.

Kuni brauseritootjad uut autentimismeetodit ei implementeeri, jääb eelpoolkirjeldatud ID-kaardi kasutusstenaarium sõltuma tänaseks kümme aastat vana TLS versiooni 1.2 edasisest püsimisest.

Omalt osalt otsustasime eeltoodu põhjal, et lubame TLS 1.3 kasutuse esialgu ainult oma uutes serverites. Nii ei tee me katki klientide olemasolevaid kasutuslugusid. Juhendame neid selle probleemiga tegelema hiljemalt siis, kui nad oma uuele serveriplatvormile üle viime.

Mis puudutab aga ID-kaarti, siis ilmselt tuleks otsustajatel Riigi Infosüsteemide Ametis (RIA) tõsiselt ja operatiivselt mõelda selle üle, kas ei oleks aeg leida veebiserveris kasutajate autentimiseks lahendusi, mis ei sõltuks ajale jalgu jäänud või tarkvaraarendajate põlualla sattunud meetoditest. Ja kui teispidi mõelda, siis oleks ju ka tore, kui meie rahvusliku PKI funktsionaalsus ei sõltuks Google Chrome arendajate suvast.

Kommentaarid

2 kommentaari
    • “Arendajate suva” on ehk natuke karmilt öeldud. TLS-ga tegelev meeskond Chrome-is ei ole suur: David [Benjamin], Nick [Harper], üks hindu, keegi oli veel. Kõik kodeerivad, administratiivtöötajaid ei paista. Paistab, et nad lihtsalt ei jõua.
      Standardikirjutajad on teine seltskond. Mulle tundub IETF kavand “Post-Handshake Authentication in TLS” loogiline. Puhtam kui senine ümberläbirääkimise (re-negotiation) mehhanism.
      Kuid paistab, et Chrome meestel on muutustest kõrini – kui David kirjutab: “Post-handshake authentication has a mess of security, semantics, and DoS issues. We have no plans to implement it at this time. I do not believe Firefox implements it either.”
      Sama lugu oli Token Binding laiendusega (vt https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/OkdLUyYmY1E).
      Asi tundub taanduma sellele, et standardite kirjutajad ei ole ise standardite rakendajad.

Kommentaarid suletud.

Populaarsed postitused

Nutikas Pilveserver: tark lahendus e-poe ja nõudlike veebiprojektide jaoks

Tanel Männik
Nutikas Pilveserver pakub nüüdisaegset ja kulutõhusat lahendust, mis ühendab endas paindlikkuse ja võimsuse, et rahuldada kõrge külastatavusega...

Hallatud või halduseta platvorm: kumb vastab paremini sinu vajadustele?

Martin Kirs
ZoneOS platvorm on meie hallatavate teenuste alustala, sisaldades endas justkui mitme IT-spetsialisti pädevusi. Kuidas see platvorm on nii "nutikas" ja...

Zone Veebiakadeemia - lihtsad tööriistad kodulehega alustamiseks

blogi
Zone Veebiakadeemia uue hooaja värskeimas osas räägib Zone arendustiimi juht Ingmar kasulikest tööriistadest, mis aitavad sul hõlpsalt ja arusaadavalt...

Partner soovitab: Kodulehe hooldus ehk kuidas kaitsta seda küberrünnakute eest

MarketingSharks
Veebiarenduse maailmas on WordPress vaieldamatult üks kõige populaarsemaid sisuhaldussüsteeme.