Information Security 2018/19 spring

Turvaline veebiliiklus: HTTPS

Miks internetiliiklust saab pealt kuulata ja jälgida

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: http://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 (december 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.

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.

HTTPS pakub:

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

HTTPS 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

TLS ja SSL

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. 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.

Järgnevates materjalides kirjeldatav TLS/SSL kasutamise statistika pärineb miljoni populaarsema (Alexa) veebilehe uuringust, mis toimus 2014 aastal. Uuring oli mitteametlik ja analüüsis kuidas 451470 veebilehte kasutas SSL/TLS. Antud uuriguga saab tutvuda Julien Vehent'i blogis: SSL/TLS analysis of the Internet's top 1,000,000 websites (2014).

Uuemat infot SSL/TLS versioonide kasutuse kohta näeb SSL Pulse vahendusel.

Protokolli versioonid ja nende turvalisus:

• SSL 2.0 - protokoll sisaldab mitmeid nõrkusi ja seetõttu ei toetata seda enam uuemates brauserites. Siiski toetab uuringu järgi veel 18.9% populaarsetest veebilehtedest SSL2.0.
  
• SSL 3.0 - võtme tuletamine kasutab MD5, mis ei ole enam turvaline. Hoolimata sellest toetab uuringu järgi 99.6% populaarsetest veebilehtedest SSL3.0. Seda tehakse selleks, et toetada vanemaid operatsioonisüsteeme, näiteks Windows XP ja Internet Explorer 6 kombinatsioon suudab maksimaalselt kasutada SSL 3.0.
• 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ünnet nimetatakse: BEAST attack. Kuna antud rünne puudutas blokkš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 praegu pigem ei soovitata kasutada TLS 1.0 koos RC4. Eelpool toodud uuringu järgi toetab TLS 1.0 98.9% tuntud veebilehtedest.
• TLS 1.2 - siiani kõige turvalisem TLS protokoll. Uuringu järgi toetab TLS 1.2 33.2% tuntud veebilehtedest.
• 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 PFS kasutamist, loe täpsemalt 2017. a. Krüptograafiliste algoritmide alutsükli uuringust (pdf).

TLS 1.3 was finalised in August 2018 and mandates Perfect Forward Secrecy. Among other things, TLS 1.3 discontinues support for several ciphers and their mode of operations that have found to be weak.

Kuna SSL 3.0 on ebaturvaline, siis ei peaks brauserid seda protokolli toetama. SSL 3.0 toe lõpetamine sunniks veebilehtede haldajaid tegutsema ja seega tooks see kaasa üldise turvataseme tõusu. Selle otsuse on teinud juba Google ja Mozilla. 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).

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 terviklikkus

TLS sisaldab andmete terviklikkuse kontrolli. See tähendab seda, et ründaja ei saa andmepakette modifitseerida ilma, et osapooled sellest teada ei saa. Andmete terviklikkuse 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 terviklikkuse kontollile 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:

HTTPS ja sertifikaadid

Avaliku võtme infrastruktuur on kasutusel ka veebis, et luua turvalisi ühendusi veebiserveritega. Sellist turvalisust pakkuval veebiserveril on 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ähalt 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: Preferences -> Advanced -> Certificates -> View Certificates

Harjutus: Vaatame, kuidas tuvastada HTTPS protokolli kasutava veebilehe sertifikaadi väljaandjat ja usaldatavust. Navigeerime veebilehele, mis kasutab HTTPS protokolli, näiteks veebilehele ois.ut.ee.

Firefox

Firefoxi aadressiriba vasakusse äärde tekib tabaluku kujutis kui veebileht kasutab HTTPS protokolli. Antud tabaluku kujutise peale vajutades kuvatakse informatsiooni praeguse ühenduse kohta ning sealt 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".

Vajutades nupule “More Information” tekib võimalus kuvada detailsemat infot sertifikaadi kohta.

Vajutage nupule “View Certificate” et näha detailsemat infot (sakk General) ja antud sertifikaadi usaldusahelat juursertifitseerimiskeskuseni:

Google Chrome

Google Chrome aadressiriba vasakusse äärde tekib tabaluku kujutis kui veebileht kasutab HTTPS protokolli. Kuni versioonini 55 sai vastavale tabaluku kujutisele vajutades leida üles veebilehe sertifikaadi, aga nüüd tuleb rohkem vaeva näha. Alates versioonist 56 tuleb sertifikaadi vaatamiseks vajutada nupule F12, siis 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 joonis on veebilehe https://cs.ut.ee kohta. Pildilt näete, et cs.ut.ee tehtud ühendus kasutab protokolli TLS 1.2. Samuti on pildilt näha, et kasutatakse algoritmi ECDHE, mis eelneva info põhjal tähendab seda, et leht toetab PFS-i.

Vajutage nupule "View certificate", et vaadata sertifikaadi infot (sarnaselt Firefoxile). Näete, et sertifikaadi hierarhia sisaldab kahte eri taseme sertifitseerimiskeskust. Vajutage antud hierarhias olevate sertifitseerimiskeskuste peale, et kuvada nende kohta rohkem infot. Veebilehe https://cs.ut.ee sertifikaati uurides panete tähele, et sama sertifikaati kasutatakse mitmete erinevate domeenide jaoks ning sertifikaadis on "Common Name" väärtuseks hoopis www.reaalteadused.ut.ee. Teised domeenid ning seehulgas ka cs.ut.ee on täpsustatud "Subject Alternative Name ( 2.5.29.17 )" kategoorias.

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

Harjutus: Külastage mõne panga kodulehte ja uurige nende poolt kasutatavaid sertifikaate.

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 organistsiooni põhjalikku kontrollimist. EV tüüpi sertifikaatide väljaandmist reguleerib EV juhend. EV tüüpi sertifikaadid pakuvad kõige rohkem usaldust ning seetõttu toovad veebibrauserid niisugust tüüpi sertifikaate esile. Selleks värvitakse osa aadressiribast roheliseks ja lisatakse sinna alasse vastava organisatsiooni nimi. Näiteks:

Probleemid

1. Mis ohud kaasnevad aegnud sertifikaatidega?
2. Mis ohud kaasnevad 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überkurjategujad paar korda kasutanud.

• rroneous VeriSign-Issued Digital Certificates Pose Spoofing Hazard
• http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/
• http://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: http://heartbleed.com/.

Kasulikud lingid

• Transport Layer Protection Cheat Sheet
• Hynek Schlawack: The Sorry State of SSL
• The Security Impact of HTTPS Interception (2017)
• Brauseri turvalisuse test - kontrollib brauseri poolt toetatud SSL / TLS versioone.
  • SSL/TLS Capabilities of Your Browser
  • SSL Server Test
• Internetiliikluse jälgimine
  • Submarine Cable Map
  • GCHQ taps fibre-optic cables for secret access to world's communications
  • Sweden approves wiretapping law
  • https://en.wikipedia.org/wiki/National_Defence_Radio_Establishment#Legal_framework
  • Sweden helps the US spy on the Baltics: report (2013)
  • The Swedish Kings of Cyberwar (december 2016)
• PKI vastaste rünnete näited
  • Unauthentic "Microsoft Corporation" Certificates (2001)
  • rroneous 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)
  • Announcing the first SHA1 collision (2017)
  • SHAttered (2017)
  • Why it’s harder to forge a SHA-1 certificate than it is to find a SHA-1 collision