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

Vähem peavalu uute PHP versioonidega

PHP 8.2 nüüd ametlikult väljas

Ingmar Aasoja
PHP versioon 8.2 on nüüd ametlikult väljas. Käesolevaga keskendume sellega kaasnevatele olulisematele uuendustele.

Partner soovitab:
Veebilehe optimeerimine paneb tulud kasvama

Digielu
Tänapäevase veebilehe optimeerimine mõjutab otseselt seda, kui hästi nii otsingumootorid kui ka kasutajad sinu veebilehte tajuvad.

Teeme andmebaasiühendused turvalisemaks

Ingmar Aasoja
Teatavasti on SQL andmebaaside kasutajatel vaikeseadistustes lubatud ühenduda ainult lokaalselt, mis tagab selle, et andmed ei liigu üle võõraste võrkude....