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

CloudFest 2024: AI annab riistvarale uue hingamise

Ingmar Aasoja
Läinud nädalal istus Zone tiim lennukisse ja sööstis taaskord CloudFesti põnevasse maailma, et heita pilk veebimajutusteenuste arengusuundadele. Meie...

Zone+ WordPressi Assistent: kuidas AI abiga sekunditega veebileht luua

Jaanus Putting
See aeg on läbi, mil vajadus kodulehe järele tähendas telefoniraamatust või guuglist veebidisaineri kontaktide otsimist. Tõenäoliselt üks viimase...

Aegunud PHP on aegunud PHP

Hasso Tepper
Kui esimene tänapäevane PHP versioon 25 aastat tagasi avalikuks tehti, oli internet hoopis teistsugune. Nõudmised veebilehtedele olid tagasihoidlikud...

Zone Veebiakadeemia - kuidas end Internetis nähtavaks teha

blogi
Zone Veebiakadeemia uusima episoodiga hakkame tutvustama ägedaid Zone koostööpartnereid. Seekord on meil külas Nobel Digitali tootejuht ja partner...