Turvaline veebiliiklus: TLS

Miks saab monitoorida internetiliiklust?

Maailmas on väike arv väga suuri side sõlmpunkte (näiteks merekaablite otspunktid). Riigid, kus asuvad mitmed merekaablite otspunktid saavad seetõttu jälgida ka välisriikide andmesidet, sest suur osa riiki sisenenud andmesidest liigub edasi. Merekaablite asukohti on võimalik näha järnevalt veebilehelt: https://www.submarinecablemap.com/. Antud kaardilt on näha, et Suurbritannia on transatlantilise ühenduse vahelüliks. Näiteks 2013. aastal avalikustati, et Suurbritannia jälgib Euroopa ja USA vahel toimuvat Interneti liiklust: GCHQ taps fibre-optic cables for secret access to world's communications

Internet on üles ehitatud nii, et ei ole võimalik ette määrata kuidas mingi pakett sihtkohta jõuab. Pakett liigub kõige optimaalsemat teed kasutades sihtpunkti. Seetõttu ei saa Internetis vältida paketi liikumist läbi riikide, mis jälgivad ja salvestavad Internetis toimuvat liiklust. Näiteks ei saa me vältida andmeside edastamist läbi Rootsi, sest tänu kiiretele ühendustele liigub suur osa meie riigist väljuvast andmesidest läbi Rootsi. Seda on kirjeldatud järgnevates artiklites: Sweden helps the US spy on the Baltics: report (2013) ja The Swedish Kings of Cyberwar (detsember 2016).

Riigid või asutused, kes jälgivad Internetis toimuvat liiklust saavad analüüsida kõiki krüpteerimata pakette ehk suurt osa veebiliiklusest. Juhul kui paketi sisu on krüpteeritud, siis saab jälgija teada kelle poolt pakett saadeti, kunas see saadeti ja mis on selle sihtpunkt.

Veebilehed, mis pakuvad krüpteeritud ühendust või lubavad andmete krüpteerimist on sõltuvad vastava veebilehe omaniku riigis kehtivatest seadustest. Kui riik nõuab seadustele tuginedes teenusepakkujalt krüpteerimiseks kasutatud võtmeid, siis üldjuhul ei saa teenusepakkuja sellest keelduda. Samuti võib riik seaduslikult nõuda firmadelt nende klientide ja nende teenuste kasutajate kohta käivat infot. Niisugust juriidilist tegevust kirjeldatakse järgnevas Guardiani artiklis: Secrets, lies and Snowden's email: why I was forced to shut down Lavabit (2014).

Snowdeni lekete tagajärjel said ettevõtted aru, et nende ründamine on liiga lihtne ning seetõttu hakati eelkõige ühenduste turvamist tõsisemalt võtma. Kõige selgemini nähtavaks tulemiks on HTTPS laialdane levik, mistõttu on praegu juba raske leida veebilehte, mis ei kasutaks HTTPS-i. Samas enne 2014. aastat oli HTTPS kasutusel vähem kui 30% veebilehtedest. Snowdeni lekete mõju üldisele turvalisusele ja krütograafiale on arutlusel järgnevalt viidatud blogipostituses: Looking back at the Snowden revelations (2019).

HTTPS poolt pakutav turvalisus

Aga kuidas aitab HTTPS protokolli kasutamine (tavalise HTTP protokolli asemel) veebilehtede külastamist turvalisemaks muuta?

HTTPS töötab mitmel erineval moel. Esiteks võimaldab korraliku sertifitseerimiskeskuse poolt allkirjastatud sertifikaadi olemasolu kasutajale kinnitada, et tegemist on õige serveriga. See aitab rünnete vastu, kus pahalane teeb sarnase kujundusega veebilehe ja üritab näiteks kasutajate paroole nii endale saada.

Teiseks, kasutades veebiserveri võtmepaari (ja tegelikult ka sümmeetrilist krüpteerimist) krüpteeritakse kogu brauseri ja veebiserveri vaheline andmeside. See hoiab ära veebiliikluse pealtkuulamise, näiteks avalikus WiFi võrgus.

Kolmandaks, tegelikult võib lisaks veebiserverile ka kasutajal olla oma võtmepaar, millega ta ennast veebiserverile tuvastab (nn kahepoolne autentimine). See on oluliselt turvalisem kui parooliga sisselogimine ja lisaks ei ole vaja eraldi kasutajanime ja parooli meeles pidada. Seda kasutatakse näiteks ID-kaardiga internetipanka sisselogimiseks. Sel juhul on kasutaja privaatvõti ID-kaardi kiibil, aga välismaiste veebiserverite puhul võib privaatvõtme näiteks brauserisse salvestada ja parooliga kaitsta.

TLS

Tegelikult ei ole HTTPS eraldi protokoll, vaid tavaline HTTP protokoll, mis on "mässitud" krüpteeringu sisse. HTTP ümber oleva krüpteeritud kihi moodustab Transport Layer Security (TLS) (või selle eelkäija Secure Socket Layer (SSL)) protokoll.

TLS pakub:

• andmete konfidentsiaalsust
• serveri autentimist sertifikaadi abil
• andmete terviklust ja andmete autentimist
• (kliendi autentimist)
• (Perfect Forward Secrecy ehk PFS)

TLS tehnilised omadused:

• klient näeb aadressiribal https://
• kasutab (tavaliselt) porti 443
• server peab omama võtmepaari
• server peab omama sertifikaati
• protokolliks on kas SSL või TLS

Kuigi paralleelselt on kasutusel mitmeid erinevaid TLS versioone (täpsem info allpool), tuleks turvalisuse huvides eelistada enda veebilehel kõige uuemat versiooni. Paraku jääb tihti tugi vanematele ja ebaturvalistele protokollidele alles, et võimaldada vananenud tarkvaraga arvutitel veebilehti külastada. Kui teid huvitab SSL/TLS ajalugu, siis saate hea ülevaate siit: SSL/TLS and PKI History. Värsket infot SSL/TLS versioonide kasutuse kohta näeb SSL Pulse vahendusel.

TLS versioonid ja nende turvalisus:

• SSL 2.0 - protokoll sisaldab mitmeid nõrkusi ja seetõttu ei toetata seda enam uuemates brauserites.
  
• SSL 3.0 - võtme tuletamine kasutab MD5, mis ei ole enam turvaline. Hoolimata sellest toetavad siiani mõned üksikud veebilehed SSL 3.0. Seda tehakse selleks, et toetada vanemaid operatsioonisüsteeme, näiteks Windows XP ja Internet Explorer 6 kombinatsioon suudab maksimaalselt kasutada SSL 3.0. Google Chrome alates versioonist 40 ei toeta enam SSL 3.0 (Google to kill off SSL 3.0 in Chrome 40). Samuti ei toeta SSL 3.0 Firefox alates versioonist 34 (The POODLE Attack and the End of SSL 3.0). Sama kehtib ka teiste läänemaailmas levinumate brauserite kohta. Seega SSL 3.0 pole enam tavakasutajate jaoks probleemiks.
• TLS 1.0 - sisaldab võimalust minna üle protokollile SSL 3.0, mis vähendab turvalisust. 2011. aastal avastati, et TLS 1.0 saab rünnata, seda ründe nimeks sai: BEAST attack. Kuna antud rünne puudutas plokkšiffri CBC töörežiimi, siis soovitati lahendusena kasutada jadašiffrit RC4. 2013. aastal avastati, et RC4 sisaldab statistilist nõrkust, mis võimaldab taastada osa algtekstist (andmetest, mida krüpteeriti): RC4 attack. Seetõttu ei soovitatud kasutada TLS 1.0 koos RC4-ga. Suuremad brauserid plaanisid lõpetada 2020. aasta alguses TLS 1.0 ja TLS 1.1 toetamise. Pärast seda ei oleks nende brauseritega enam olnud võimalik külastada veebilehti, mis toetavad ainult TLS 1.2-st varasemaid TLS versioone. Maailmat tabanud pandeemia tõttu lükkasid brauseritootjad vastava plaani ajutiselt edasi, et ei tekiks probleeme riiklike veebilehtede külastamisega, mis toetasid vaid TLS 1.0 või TLS 1.1. 2021. aastal lõpuks polnud TLS 1.0 ega TLS 1.1 enam Firefoxi ega Google Chrome poolt vaikimis toetatud.
• TLS 1.2 - oli 2018. aastani kõige turvalisem TLS protokoll (kuna siis häid alternatiive polnud). Hetkel on see kõige levinum, kuigi TLS 1.3 muutub järjest populaarsemaks. Praegu sobivad turvalisuse poolest kasutamiseks nii TLS 1.2 kui TLS 1.3.
• TLS 1.3 - sai valmis 2018. aasta augustikuus. Muuhulgas loobub TLS 1.3 mitmetest nüüdseks nõrgaks muutunud šifritest ja töörežiimidest ning nõuab tulevikusalastuse kasutamist, loe täpsemalt 2023. a. Krüptograafiliste algoritmide elutsükli uuringust (pdf).

Enda brauseri turvalisust saab testida järgmisel veebilehel, mis kontrollib brauseri poolt toetatud SSL / TLS versioone: SSL/TLS Capabilities of Your Browser. Serveri TLS seadistust saab kontrollida järgneva testi abil: SSL Server Test.

Perfect forward secrecy ehk PFS

Selleks, et vältida serveri salajase võtme lekkimisest tulenevaid probleeme saab kasutada sessioonivõtme kokkuleppimiseks ühekordselt kasutatavat võtmepaari. Seega ei ole ründajal kasu andmete salvestamisest lootuses, et tulevikus on võimalik serveri salajast võtit kasutada, et andmeid dekrüpteerida. Selleks, et kindlaks teha kas veebileht kasutab PFS tuleb vaadata, mis algoritmi kasutatakse sessioonivõtme kokkuleppimiseks. PFS on kasutusel juhul kui kasutatakse algoritme Diffie-Hellman Ephemeral (DHE) või Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). Täpsemalt soovitame PFS kohta lugeda siit: Perfect Forward Secrecy - An Introduction.

Võtmevahetuseks kasutatakse tihti Diffie-Hellman võtmevahetuse protokolli. Sellest, kuidas Diffie-Hellman toimib saate ülevaate järgneva video abil.

Harjutus: Leidke veebileht, mis kasutab PFS-i.

Andmete terviklus

TLS sisaldab andmete tervikluse kontrolli. See tähendab seda, et ründaja ei saa andmepakette modifitseerida ilma, et osapooled sellest teada ei saa. Andmete tervikluse tagamiseks kasutatakse sõnumiautentimiskoodi ehk MAC-koodi (Message Authentication Code). MAC algoritm saab sisendiks võtme ja andmed ja annab väljundiks lühikese sõnumiautentimiskoodi. Sõnumiautentimiskoodi loomiseks ja verifitseerimiseks kasutatakse sama võtit ja seega peavad osapooled selle omavahel varem kokku leppima. Seetõttu pakub MAC lisaks tervikluse kontrollile ka autentsuse kontrolli. Sõnumiautentimiskoodi loomiskes kasutatakse järgmisi algorime: HMAC-MD5, HMAC-SHA1, HMAC-SHA256/384, AEAD. HMAC-MD5 on toetatud protokollide SSL 2.0, SSL 3.0, TLS 1.0 ja TLS 1.2 poolt. HMAC-SHA1 on toetatud SSL 3.0, TLS 1.0 ja TLS 1.2 poolt ja ülejäänud kaks algoritmi on toetatud ainult TLS 1.2 poolt.

Sessiooni kokkuleppimine

Täpsemalt saab TLS ühenduse loomise kohta lugeda siit. Detaile saab näha siit: https://tls.ulfheim.net/. Sellest kuidas TLS puhul krüpteeritud kanal moodustatakse, annab abstraktse ülevaate järgmine joonis:

TLS sertifikaadid

Avaliku võtme infrastruktuur on kasutusel ka veebis, et luua turvalisi ühendusi veebiserveritega. Tavakasutaja jaoks on kõige nähtavamaks brauseri ja veebiserveri vahel loodav TLS ühendus, mida visuaalselt nähakse aadressiribal oleva HTTPS kaudu. Selleks, et te saaksite veebilehe külastamiseks kasutada HTTPS-i peab veebiserver olema seadistatud TLS kasutama.

TLS toetaval veebiserveril peab olema võtmepaar ning sertifikaat, mis seob avaliku võtme veebiserveri nimega (aadressiga). Veebiserveri sertifikaat on allkirjastatud mõne sertifitseerimiskeskuse poolt. Tuntumate veebilehtede sertifikaadid on allkirjastatud mõne üldtunnustatud sertifitseerimiskeskuse poolt, kelle enda sertifikaat on brauseris juba vaikimisi usaldatud. Brauserid või operatsioonisüsteemid omavad vaikimisi vähemalt 50 suure sertifitseerimiskeskuse juursertifikaati, mida siis vastavalt kas brauser või operatsioonisüsteem usaldab. Nende usaldatud sertifitseerimiskeskuste poolt välja antud sertifikaate usaldab brauser vaikimisi.

Harjutus: Millised juursertifikaadid on sinu brauseris vaikimisi usaldatud?

• Firefox: Settings -> Privacy & Security -> Certificates -> View Certificates ...

Harjutus: Vaatame, kuidas tuvastada HTTPS protokolli kasutava veebilehe sertifikaadi väljaandjat ja usaldatavust. Uurimiseks saate kasutada suvalist HTTPS kasutavat veebilehte.

Firefox

Firefoxi aadressiriba vasakusse äärde tekib tabaluku kujutis kui veebileht kasutab HTTPS protokolli. Tabaluku kujutise peale vajutades kuvatakse informatsiooni praeguse ühenduse kohta ning selle vaate kaudu saab leida ka infot antud lehe sertifikaadi ja sertifitseerimiskeskuse kohta.

Kui nüüd vajutada pildi parempoolses osas olevale noolele, siis avaneb järgnev vaade, kus on olemas nupp "More Information". Sellele nupule vajutades avaneb teile järgnev vaade.

Harjutus: Vajutage nupule “View Certificate” ning uurige sertifikaati ning veebilehe sertifikaadi ja juursertifitseerimiskeskuse sertifikaadi vahelist usaldusseost.

Google Chrome

Google Chrome aadressiriba vasakusse äärde tekib tabaluku kujutis kui veebileht kasutab HTTPS protokolli. Kui vajutada tabaluku kujutisele, siis pakutakse sertifikaadi kuvamise võimalust. Alates versioonist 56 saab veebilehe sertifikaati vaadata ka kui vajutada nupule F12, otsida üles kategooria "Security" ning seal vajutada nupule "View certificate". Mac kasutajad saavad F12 asemel kasutada klahvikombinatsiooni ⌘ + Option + i. Juhul kui teie arvutis kumbki variant ei toimi, siis saate sertifikaadi info üles otsida nii: vajutage ekraani ülemises parempoolses servas kolme täpiga nupu peale -> valige "More Tools" -> "Developer Tools" -> "Security" -> "View certificate".

"View certificate" nupu peale vajutades kuvatakse informatsiooni vastava sertifikaadi ja sertifitseerimiskeskuse kohta. Järgnev info on veebilehe https://ut.ee kohta. Selgub, et sertifikaadi hierarhia sisaldab kahte eri taseme sertifitseerimiskeskust. Vajutage antud hierarhias olevate sertifitseerimiskeskuste peale, et kuvada nende kohta rohkem infot.

Ülevalpool olevalt ekraanitõmmistelt on näha, et ut.ee lehele tehtud ühendus kasutab protokolli TLS 1.2. Samuti näeme, et kasutati algoritmi ECDHE, mis eelneva info põhjal tähendab seda, et leht toetab PFS-i. Lisaks on pildilt näha, et kasutusel on elliptkõver P-256 ning sessiooni vältel edastavad andmed krüpteeritakse 256 bitise AES võtmega. Veel näeme, et AES töötab GCM režiimis, mis tagab autenditud krüpteerimise.

Võimalik on leida ka sertifikaate kus on pikem hierarhia. Näiteks m.ut.ee sertifikaadi hierarhias oli varasemalt kolm eri taseme sertifitseerimiskeskust.

Sertifikaatide usaldustasemed

Sertifitseerimiskeskus saab välja anda kolme usaldustasemega sertifikaate.

Domain validation (DV) tüüpi sertifikaatide väljaandmiseks kontrollitakse kas päringu teinud isik reaalselt omab kontrolli vastava domeeni üle, mille jaoks sertifikaati soovitakse. Selleks on enamasti kaks meetodit:

1. domeeni omanik peab veebiserverisse laadima kindlat tüüpi dokumendi
2. domeeni omanik peab saama kätte valideerimiskoodi, mis on saadetud domeeniga seotud emaili aadressile

Antud protsessi on võimalik automatiseerida ning seetõttu pakuvad osad sertifitseerimiskeskused tasuta DV tüüpi sertifikaate. Seda teeb näiteks Let's Encrypt.

Organization Validation (OV) tüüpi sertifikaate antakse välja pärast vastava organisatsiooni olemasolu ja volituse kontrollimist. Lisaks kontrollitakse ka domeeni kuuluvust nagu seda tehti DV korral.

Extended Validation (EV) tüüpi sertifikaate antakse välja pärast vastava organisatsiooni põhjalikumat kontrollimist. EV tüüpi sertifikaatide väljaandmist reguleerib EV juhend. EV tüüpi sertifikaadid peaksid pakkuma kõige rohkem usaldust ning seetõttu tõid veebibrauserid varasemalt EV tüüpi sertifikaate esile värvides osa aadressiribast roheliseks ja lisades sinna alasse vastava organisatsiooni nime. Alates 2019. aastast seda enam ei teha, kuna tuvastati mitmeid meetodeid kuidas ründajad saavad seda funktsionaalsust pahatahtlikult ära kasutada. Näiteks oli võimalik registreerida sarnase nimega ettevõte mõnes teises riigis ning niimoodi saada usaldusväärsena näiv sertifikaat ja aadressiriba. Niisugust võimalust kirjeldati näiteks 2017. aastal: Nope, this isn’t the HTTPS-validated Stripe website you think it is.

Probleemid

1. Mis ohud kaasnevad aegunud sertifikaatidega?
2. Mis ohud kaasnevad nn. self-signed sertifikaatidega?

Nagu näha, siis aegunud või ise signeeritud sertifikaadi tuvastamisel hoiatab veebilehitseja, et antud veebilehe autentsuses ei saa kindel olla. Seda hoiatust tasub võtta täie tõsidusega, aga juhul kui olete teadlik, et antud veebilehel peabki olema näiteks ise signeeritud sertifikaat (sest tegemist on näiteks teie enda serveriga), siis võib seda veebilehte edasi kasutada. Loomulikult peaks enne avaliku võtme räsi kontrollima. Ka sel juhul on teie veebilehitseja ja serveri vaheline liiklus krüpteeritud.

Brauser võib sertifikaadi vigade tõttu kuvada mitmeid erinevaid veateateid. Neid veateateid ja hoiatusi saab vaadata järgnevalt veebilehelt: https://badssl.com/.

Ründed

Kuidas saaks teoreetiliselt PKI arhitektuuri rünnata? Üheks võimaluseks on rünnata sertifitseerimiskeskust.

Niisugust rünnakut on küberkurjategijad paar korda kasutanud.

• https://www.cert.org/advisories/CA-2001-04.html
• Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard
• https://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/
• https://arstechnica.com/security/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack/

Heartbleed turvaauk

2014. aasta aprillis avastati populaarsest OpenSSL krüptograafia teegist turvaauk, mis võimaldas veebiserveri mälu lugeda. Antud turvaauk võimaldas lugeda veebiserveri mälu ilma, et server oleks rünnet tuvastanud. Vastav rünne on hästi illustreeritud XKCD koomiksis: Heartbleed Explanation.

Siiski, miks oli see turvaauk nii oluline? Oluliseks muutis selle OpenSSL, sest OpenSSL on kõige levinum krüpto teek, mis tähendab seda, et suurem osa HTTPS lehti kasutas OpenSSL. Seega mõjutas antud turvaauk väga suurt osa veebilehtedest.

Heartbleed võimaldas lugeda väikest osa veebiserveri mälust, aga veebiserveri mällu on laetud salajane võti ja muu konfidentsiaalne info, mis ei tohiks kolmandate isikute kätte sattuda. Seega võis ründaja teha tuhandeid päringuid, et saada juurdepääsu suuremale osale serveri mälust. Seetõttu pidid OpenSSL kasutavad veebilehed looma uue võtmepaari ja sertifikaadi, sest varasemalt kasutatud salajane võti võis olla lekkinud.

Juhul kui vastava turvaprobleemiga server kasutas HTTPS ühenduste loomiseks PFS-i, siis serveri salajase võtme lekkimisel ei lekkinud varasemalt serverisse saadetud sõnumid. Seega näitas Heartbleed nime kandev turvaauk, et PFS kasutamine on oluline. Lisaks turvaprobleemidele võib serveri võti lekkida ka seoses küberrünnakuga ning sellega kaasnevat kahju saab osaliselt vähendada PFS-i abil.

Rohem infot leiab Heartbleedi tutvustavalt lehtelt: https://heartbleed.com/.

Kasulikud lingid

• TLS seadistamise juhendid
  • Transport Layer Protection Cheat Sheet
  • OpenSSL Cookbook
  • Let's Encrypt: Getting Started
• TLS kohta käiv info:
  • HTTPS Certificate Revocation is broken, and it’s time for some new tools (2017)
  • Top 1 Million Analysis - September 2019 (2019)
• Brauseri turvalisuse test - kontrollib brauseri poolt toetatud SSL / TLS versioone.
  • SSL/TLS Capabilities of Your Browser
  • SSL Server Test
• Internetiliikluse jälgimine
  • Map of submarine cables
  • Sweden approves wiretapping law (2008)
  • https://en.wikipedia.org/wiki/National_Defence_Radio_Establishment#Legal_framework
  • Sweden helps the US spy on the Baltics: report (2013)
  • GCHQ taps fibre-optic cables for secret access to world's communications (2013)
  • The Swedish Kings of Cyberwar (december 2016)
  • The Security Impact of HTTPS Interception (2017)
  • Looking back at the Snowden revelations (2019)
• PKI vastaste rünnete näited
  • Unauthentic "Microsoft Corporation" Certificates (2001)
  • Erroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard (2003)
  • Inside 'Operation Black Tulip': DigiNotar hack analysed (2011)
  • Independent Iranian hacker claims responsibility for Comodo hack (2011)
  • French agency caught minting SSL certificates impersonating Google (2013)
  • Google Chrome will banish Chinese certificate authority for breach of trust (2015)
• SHA-1 ja MD5 seonduvad probleemid ja ründed
  • Finding Collisions in the Full SHA-1 (2005)
  • MD5 considered harmful today (2008)
  • Gradually sunsetting SHA-1 (2014)
  • The SHAppening: freestart collisions for SHA-1 (2015)
  • Why it’s harder to forge a SHA-1 certificate than it is to find a SHA-1 collision (2015)
  • Announcing the first SHA1 collision (2017)
  • SHAttered (2017)