Napadi na HTTPS

Moderni principi komunikacije računala i digitalizacije ljudskih procesa značajnim se dijelom temelje na protokolu HTTP. Njegova sveprisutnost čini ga primamljivom metom napada, odnosno, tehnologijom čiju je sigurnost potrebno osigurati pod svaku cijenu. Upravo je zato HTTP nadograđen dodatnim sigurnosnim slojem, protokolom TLS [1], čime je nastao Hypertext Transfer Protocol Secure (HTTPS). Kao što mu ime sugerira, protokol HTTPS trebao bi biti siguran. Razlike između protokola HTTP i HTTPS, sigurnosni zahtjevi protokola HTTPS i njihova implementacija objašnjeni su poglavljem 2. Poglavlje 3 sagledava moguće pristupe napadanju protokola. U poglavlju 4 konačno se navodi i analizira nekoliko konkretnih napada na protokol. Za svaki će spomenuti napad biti predložena i prikladna strategija obrane ili smanjenja rizika, ako ona postoji. Rad govori isključivo o napadima koji se tiču sigurnosti komunikacije, odnosno, istražuje napade kojima je cilj neutraliziranje nadogradnji koje HTTPS pruža HTTP-u. Sigurnost protokola HTTP neće se obrađivati.

Ključne riječi: HTTP, HTTPS, TLS, SSL, certifikat, MITM, kriptografija, SSL Strip, Heartbleed

Pri razvoju Interneta, sigurnost i zaštita korisnika nisu bili u prvom planu. Primarni cilj projekta bio je omogućiti udaljenim računalima da međusobno komuniciraju, odnosno, rad znanstvenika najvećim je dijelom bio usmjeren na pronalazak brzog i pouzdanog načina prijenosa informacija. Istraživači su bili svjesni postojanja zlonamjernih aktera. Predvidjeli su potrebu za zaštitom od mogućih uljeza i vojnih prijetnji, ali nisu predvidjeli da bi korisnici Interneta mogli koristiti mrežu kako bi napadali jedni druge. David D. Clark, jedan od pionira interneta,jednom je prilikom izjavio [3]:

It’s not that we didn’t think about security. We knew that there were untrustworthy people out there, and we thought we could exclude them.

Iz citata je jasno kako su tvorci Interneta očekivali zajednicu od nekoliko desetaka znanstvenika. Nastanak potpuno otvorene mreže koja je dostupna milijardama nepoznatih korisnika tada nije bio izgledan ishod projekta. Čak i da se uspjeh i raspon Interneta tada mogao adekvatno predvidjeti, bilo bi naivno očekivati da sigurnosne izazove koji ni danas nisu u potpunosti razriješeni predvidi i riješi malena skupina ljudi prije 40 godina.

Kao posljedica navedenog, temeljni protokoli na kojima radi internet fundamentalno su nesigurni, odnosno, rade na pretpostavci da se svi korisnici ponašaju “pristojno”. Jednom kada su sigurnosne implikacije potpuno otvorene mreže postale jasne, protokoli na kojima ona radi bili su već čvrsto utemeljeni. Jedina mogućnost bila je dodavanje dodatnih slojeva i nadogradnji koje bi pružile sigurnosni omotač oko postojećih protokola. Jedna je od takvih nadogradnji, ako ne i najvažnija, protokol Secure Sockets Layer (SSL) [4] koji je kasnije zamijenio Transport Layer Security (TLS) [1]. Uz brojne ostale primjene, TLS čini razliku između protokola HTTP i HTTPS.

Izvorno zamišljen kako bi olakšao pisanje, čitanje, i međusobno povezivanje akademskih radova [5], Hyper text transfer protocol (HTTP) od tada se razvio u nešto mnogo značajnije. Osim za svoju izvornu namjenu (čitanje i pisanje međusobno povezanih statičnih dokumenata), protokol se danas koristi kao glavno sredstvo komunikacije na internetu. Koristi se pri komunikaciji krajnjih korisnika s poslužiteljima, ali i u međusobnoj komunikaciji raznih programa i uređaja spojenih na Internet. Sve korisničke aplikacije koje rade preko mreže koriste upravo HTTP.

Naravno, najveći dio moderne komunikacije obavlja se preko sigurnog protokola HTTPS koji je zapravo samo protokol HTTP “omotan” protokolom TLS. Izvorno ime protokola HTTPS bilo je HTTP over TLS [6]. Drugim riječima, sigurnost protokola HTTPS oslanja se na sigurnost protokola TLS. Što sve taj dodani sigurnosni sloj pruža korisnicima objašnjeno je sljedećim poglavljem.

Ideja HTTPS-a razvila se iz potrebe za nekoliko osnovnih sigurnosnih svojstava:

1. Autentifikacija stranica kojima korisnik pristupa
2. Privatnost komunikacije
3. Osiguranje integriteta poruka

Ispunjavanje navedenih zahtjeva sprječava lažno predstavljanje i man-in-the-middle napade. Pri korištenju nezaštićenog HTTP-a, napadač se jednostavno može pozicionirati negdje na putu između klijenta i poslužitelja, te klijentu umjesto legitimnih stranica posluživati bilo što. HTTP ne sadrži mehanizam koji bi uspješno detektirao ili spriječio opisani napad.

S druge strane, koristi li klijent HTTPS, od svakog se poslužitelja zahtjeva autentifikacija. Preko mreže se, nakon uspostave sigurne veze, šalju enkriptirane poruke koje pročitati mogu samo klijent i autentificirani poslužitelj. Želi li se netko lažno predstaviti u svrhu izmjene ili čitanja privatnih poruka, mora se uspješno autentificirati kao poslužitelj. Uz pretpostavku tajnosti ključa poslužitelja i sigurnosti korištenih kriptografskih algoritama, lažna je autentifikacija praktično neizvediva. Napadi na sigurnost HTTPS-a fokusiraju se upravo na otklanjanje navedenih pretpostavki.

TLS (a time i HTTPS) sprječava i napade ponavljanjem poruka (eng. replay attack). Navedeno je svojstvo osigurano prisutnošću slijednih brojeva u enkriptiranim porukama.

Kao što je već spomenuto, protokol HTTPS ostvaren je dodavanjem sigurnog sloja komunikacije između transportnog protokola (TCP) i aplikacijskog protokola (HTTP). Obična HTTP veza ostvaruje se na sljedeći način:

1. Klijent uspostavlja TCP vezu s poslužiteljem koristeći trostruko rukovanje [7]
2. Koristeći uspostavljenu TCP vezu, klijent poslužitelju šalje zahtjeve i poslužitelj na njih odgovara

Računala komuniciraju izravno protokolom TCP, odnosno, sve se poruke prenose u čistom tekstu. Slika 1 prikazuje kako navedena procedura izgleda na mreži.

Slika 1. Uspostava veze kod pristupanja stranici http://www.fer.unizg.hr. Na slici je označen HTTP zahtjev koji se šalje nakon uspostave TCP veze. Zahtjev je poslan u čistom tekstu i bilo tko na mreži može čitati i mijenjati njegov sadržaj.

Sigurna HTTPS veza ostvaruje se slično kao i nezaštićena HTTP veza, uz nekoliko važnih dodatnih koraka [8]:

1. Klijent uspostavlja TCP vezu s poslužiteljem koristeći trostruko rukovanje
2. Koristeći uspostavljenu TCP vezu, putem TLS-a obavlja se:
   1. Dogovor o kriptografskim protokolima koji će se koristiti u daljnjoj komunikaciji
   2. Autentifikacija poslužitelja (postoji i mogućnost autentifikacije klijenta, ali ne koristi se često)
   3. Uspostavljanje sjedničkog ključa za enkriptiranu komunikaciju
   4. Suglasnost za početak enkriptirane komunikacije
3. Koristeći uspostavljenu TLS vezu, klijent poslužitelju šalje zahtjeve i poslužitelj na njih odgovara.

Računala i dalje komuniciraju koristeći protokol TCP. Razlika je u tome što podaci koje TCP prenosi pripadaju TLS-u, a ne izravno HTTP-u. Podaci protokola TLS sadrže isti onaj zahtjev koji bi se poslao da se koristio samo HTTP, ali enkriptiran sjedničkim ključem dogovorenim u koraku 2.III. Isto vrijedi za svu daljnju komunikaciju. Slika 2 prikazuje kako navedena procedura izgleda na mreži.

Slika 2. Uspostava veze kod pristupanja stranici https://www.fer.unizg.hr. Vidljivo je nekoliko važnih paketa. Poruka Client Hello početak je uspostave TLS veze. Između ostalog, klijent poslužitelju nudi popis kriptografskih algoritama koje je spreman koristiti za komunikaciju (korak 2.I). Odgovor poslužitelja dolazi porukom Server Hello koja sadrži odabrani kriptografski algoritam s popisa (korak 2.I). Sljedeća važna poruka, Certificate, služi za autentifikaciju poslužitelja (korak 2.II). Porukama Server Key Exchange i Client Key Exchange dogovara se sjednički ključ (korak 2.III). Poslužitelj signalizira završteak rukovanja porukom Server Hello Done. Konačno, porukama Encrypted Handshake Message započinje enkriptirana komunikacija. Na slici je označen HTTP zahtjev koji se šalje nakon uspostave enkriptirane TLS veze. Unutar TLS paketa nalazi se isti HTTP zahtjev kao i na slici 1. Međutim, sadržaj je paketa enkriptiran, a njegov je integritet osiguran autentifikacijskim kodom poruke (HMAC). Nitko na mreži ne može čitati ili mijenjati njegov sadržaj [8].

Autentifikacija poslužitelja i sigurnost cijelog protokola počivaju na implicitnom povjerenju u autoritete za izdavanje certifikata (CA). Naime, HTTPS je siguran samo uz garanciju da je treća strana, koja potpisuje autentičnost vlasnika certifikata, vjerodostojna i nekompromitirana.

Otklanjanju dodatnih sigurnosnih svojstava koje pruža HTTPs moguće je pristupiti iz nekoliko različitih kuteva. HTTPS se može napasti:

1. Pronalaskom sigurnosnih nedostataka samog protokola
2. Pronalaskom sigurnosnih nedostataka određenih kriptografskih algoritama koje protokol koristi
3. Iskorištavanjem tehničkih pogrešaka u implementaciji protokola ili korištenih teorijski sigurnih kriptografskih algoritama (eng. side-channel attacks)
4. Pronalaskom načina da se HTTPS uopće ne koristi (engl. downgrade attacks)
5. Saznavanjem tajnih ključevima na koje se protokol oslanja te njihovom manipulacijom
6. Napadom ili utjecajem na autoritete koji izdaju i potpisuju certifikate

Pristupi 1 i 2 u praksi su rijetko korisni. Kriptografski protokoli i algoritmi prolaze kroz rigorozan proces dizajna i analize sigurnosti. Protokol HTTPS uspješno se koristi već 20 godina i do sad nije zabilježen niti jedan napad koji iskorištava njegove teorijske nedostatke. Slična je situacija i s većinom kriptografskih algoritama koje on interno može koristiti. Pojedini algoritmi s vremenom jesu zastarjeli i svakako ih je moguće uspješno napasti. Kako je fokus ovog rada sam protokol HTTPS, takvi se napadi neće detaljno razmatrati.

Pristup 3 vrlo je čest problem u praksi. Nekoliko je napada koji ga koriste detaljnije opisano u sljedećem poglavlju.

Pristupi 4, 5, i 6 ne napadaju sigurnost samog protokola, već njegove pretpostavke. Preciznije, pristup 4 nastoji otkloniti pretpostavku da obje strane koriste protokol. Pristup 5 fokusiran je na eliminaciju pretpostavke o tajnosti ključeva, dok pristup 6 iskorištava nužnost postajanja vjerodostojne treće strane koji nastoji učiniti manje vjerodostojnim. U sljedećem je poglavlju opisano i nekoliko napada iz ovih kategorija.

Heartbleed je ime za ranjivost nastalu pogreškom u implementaciji paketa OpenSSL koja je otkrivena 2014. godine [10]. Greška nije bila u specifikaciji i dizajnu protokola, već u njegovoj najpopularnijoj implementaciji.

Heartbleed svakom korisniku Interneta pruža mogućnost čitanja spremnika radne memorije na bilo kojem sustavu koji koristi ranjivu verziju paketa. Drugim riječima, ova ranjivost otvara mogućnost kompromitiranja privatnih ključeva poslužitelja na kojima počiva sigurnost svih protokola koji koriste TLS, pa tako i sigurnost HTTPS-a. Sve je to moguće bez ostavljanja ikakvih tragova.

Iako je greška u paketu otklonjena vrlo brzo, Heartbleed i dalje predstavlja prijetnju svim poslužiteljima koji nisu instalirali navedeno ažuriranje. Ozbiljne implikacije dolaze i od činjenice da je ranjivost otkrivena tek dvije godine nakon nastanka [11].

S tehničke strane, ranjivost je nastala zbog nedostatka provjere duljine međuspremnika (eng. buffer underflow) pri odgovaranju na zahtjeve klijenta za provjeru stanja veze (eng. SSL Heartbeat).

Za uspješnu obranu dovoljno je ažurirati OpenSSL.

BEAST je kratica za Browser Exploit Against SSL/TLS. Riječ je man-in-the-middle downgrade napadu u kojem se napadač pozicionira između klijenata i poslužitelja te presretanjem poruka nastoji spustiti verziju TLS-a na 1.0 (ili bilo koju verziju SSL-a ¹⁾). Navedena verzija pati od kriptografskog nedostatka koji napadaču pruža mogućnost prisluškivanja enkriptirane komunikacije [2].

Od napada se najbolje obraniti konfiguriranjem poslužitelja da ne podržava TLS 1.0 ili bilo koju verziju SSL-a. Dok god su navedene verzije protokola podržane, poslužitelj je ranjiv.

SSL Strip vrsta je man-in-the-middle downgrade napada i izvodi se na sljedeći način [16]:

1. Napadač se pozicionira između klijenta i poslužitelja. Mogući načini uključuju lažne priključne točke za Wi-Fi, krivotvorene ARP poruke (engl. ARP spoofing), i kompromitiranje drugih računala na mreži.
2. Klijent uspostavlja vezu s poslužiteljem (npr. www.fer.unizg.hr) najčešće uz preusmjeravanje s HTTP-a na HTTPS
3. Napadače presreće poslužiteljev odgovor s uputom za preusmjeravanje
4. Napadač otvara HTTPS vezu s poslužiteljem u koju “pakira” klijentske zahtjeve
5. Odgovore koji pristižu s poslužitelja napadač vraća klijentu putem HTTP-a, odnosno, bez dodatne enkripcije
6. Napadač može nesmetano čitati i mijenjati poruke, čak i kad poslužitelj dopušta isključivo sigurne veze (jer je iz perspektive poslužitelja uspostavljena sigurna veza)

SSL Strip napada sigurnost HTTPS tako da ga na dijelu komunikacijskog kanala uopće ne koristi. Uobičajeni tijek komunikacije prikazan je slikom 3. Slika 4 prikazuje uspješno provođenje napada.

Slika 3. Uobičajen tijek komunikacije između klijenta i poslužitelja konfiguriranog da prihvaća samo sigurne veze. Klijenti resursima često inicijalno pristupaju preko protokola HTTP, a poslužitelj ih preusmjerava na HTTPS.

Slika 4. Prikaz napada SSL Strip. Napadač se postavlja između klijenta i poslužitelja. U trenutku kada bi klijent bio preusmjeren na HTTPS, napadač uspostavlja HTTPS vezu s poslužiteljem, a s klijentom komunicira nezaštićenom vezom.

Zahvaljujući zaglavlju Strict-Transport-Security [9], SSL Strip danas je opasan u puno manjoj mjeri. Određeni web preglednici pri svakom pokušaju uspostavljanja HTTP veze nastoje prijeći na HTTPS (prije ikakve komunikacije s poslužiteljem).

Konačno, Google pruža uslugu HSTS preload. Vlasnici web stranica imaju mogućnost dodati svoju domenu na popis i time osigurati da se na nju preglednici nikad ne pokušavaju spojiti nesigurnom vezom. Iako je riječ o Googleovoj usluzi, svi su proizvođači preglednika obećali podržati uslugu u budućnosti [9].

Uspije li napadač na bilo koji način doći do tajnih ključeva koje poslužitelji koriste pri autentifikaciji, sigurnosne garancije protokola prestaju vrijediti.

Naime, dođe li u posjed tajnih ključeva (ili certifikata), napadač može nesmetano izvoditi man-in-the-middle napade, bilo u svrhu lažnog predstavljanja, prisluškivanja ili manipulacije poruka. Napad je iznimno teško otkriti. Iz perspektive klijenta, zbog povjerenja u tajnost ključa, poslužitelj se čini legitimnim. Iz perspektive poslužitelja, napadač izgleda kao samo još jedan klijent.

Napadač do tajnih certifikata može doći raznim metodama, često potpuno nepovezanim sa samom komunikacijom preko HTTPS-a.

Kao što je već spomenuto u ranijim poglavljima, sigurnost cijelog sustava počiva na implicitnom povjerenju u skupinu autoriteta koji stoje iza izdanih certifikata (CA). Uspije li netko napasti ili na drugi način utjecati na odluke tih tvrtki, implikacije na sigurnost protokola prilično su ozbiljne. Kompromitiranje certifikata ovih autoriteta sličan je problem kompromitiranju certifikata jednog poslužitelja (opisan u poglavlju 4.2.2), ali uz značajno veći opseg jer ugroženima postaju i identiteti svih poslužitelja kojima je kompromitirani autoritet izdao certifikat.

Upravo su zato autoriteti za izdavanje certifikata najprimamljivija meta kriminalcima (ali i svjetskim vladama) te danas predstavljaju najslabiju točku sustava. Kako popularnost i reputacija određenog autoriteta raste, napad na njega postaje sve isplativijim i opasnijim. Kroz povijest je zabilježeno nekoliko ovakvih scenarija. Na sreću, svi su brzo otkriveni i utjecaj koji su imali nije bio značajan. Ipak, poslužili su za skretanje pažnje na trenutno najveću slabost sustava koja još uvijek nije adekvatno riješena.

Autoritet za izdavanje certifikata VeriSign izdao je 2001. godine dva certifikata osobi koja je tvrdila da predstavlja Microsoft. Certifikati su nosili ime Microsoft Corporation i teoretski bi se mogli iskoristiti za distribuciju krivotvorenih ažuriranja operacijskog sustava Windows. Problem je brzo otkriven te su Microsoft i VeriSign poduzeli određene korake kako bi ograničili njegov opseg [12].

2011. godine izvršen je napad na Nizozemski CA DigiNotar koji je rezultirao izdavanjem brojnih lažnih certifikata. Ukupno ih pronađeno oko 500 [13]. Između ostalih, izdani su bili certifikati za tvrtke Yahoo!, Mozilla, WordPress, Google, i Tor. Kasnije je potvrđeno kako su se isti certifikati u Iranu koristili za provođenje man-in-the-middle napada na Googleove servise [14]. Proizvođači preglednika reagirali su stavljanjem svih DigiNotar certifikata na crnu listu [13]. Tvrtka DigiNotar bankrotirala je istog mjeseca [15], a počinitelji nikad nisu sa sigurnošću utvrđeni. Napad je poslužio kao demonstracija nedostataka sustava te osvijestio potrebu za hitnim reformama na kojima se još uvijek radi.

U seminaru je dan kratak pregled sigurnosnih nadogradnji na HTTP koje omogućuje TLS, odnosno, HTTPS. Analizirane su moguće strategije napada na protokol te je pokazano da najuspješnije od njih protokol u potpunosti zaobilaze, bilo downgrade napadima ili kompromitiranjem čimbenika njegove sigurnosti.

Sam HTTPS smatra se sigurnim i ne postoje poznati napadi koji koriste slabosti u njegovu dizajnu. Poznate ranjivosti posljedice su loših implementacija protokola ili korištenja zastarjelih algoritama. se u pravilu mogu otkloniti redovitim ažuriranjem programa i strogom konfiguracijom poslužitelja koja ne dopušta korištenje starih i ranjivih algoritama.

Glavnu slabost protokola predstavljaju autoriteti za izdavanje certifikata (CA) jer kompromitiranje istih dovodi do pada sigurnosti cijelog sustava (eng. single point of failure). U vrijeme pisanja ovog rada još uvijek nije pronađeno rješenje navedenog problema, ali uspješni su napadi na autoritete sve rjeđi.

[1] Christopher Allen, Tim Dierks. The TLS Protocol Version 1.0. Network Working Group, 1999.

[2] Zbigniew Banach. How the BEAST Attack Works. Netsparker, 2020.

[3] Craig Timberg. A flaw in the design. The Washington Post, 2015.

[4] Alan O. Freier, Philip Karlton, Paul C. Kocher. The Secure Sockets Layer (SSL) Protocol Version 3.0. Internet Engineering Task Force, 1994.

[5] Roy T. Fielding, Roy T. Fielding, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Paul J. Leach, Tim Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. Network Working Group, 1999.

[6] Eric Rescorla. HTTP Over TLS. Network Working Group, 2000.

[7] Deland Han, Anna-Li, Simon Xu. Explanation of the three-way handshake via TCP/IP. Microsoft, 2020

[8] Jeff Moser. The First Few Milliseconds of an HTTPS Connection. Moserware blog, 2009.

[9] Mozilla Developer Network. Strict-Transport-Security. MDN, 2020.

[10] Synopsis Inc. The Heartbleed Bug. Synopsis, 2020.

[11] Michael Hicks. How did Heartbleed remain undiscovered, and what should we do about it?. Michael Hicks Blog, 2014.

[12] CERT Division. 2001 CERT Advisories. Carnegie Mellon Univeristy, 2001.

[13] Ars Staff. Comodo hacker: I hacked DigiNotar too; other CAs breached. Ars Technica, 2011.

[14] Elinor Mills. Fraudulent Google certificate points to Internet attack. Cnet, 2011.

[15]Press release. VASCO Announces Bankruptcy Filing by DigiNotar B.V. VASCO Data Security International, 2011

[16] Anastasios Arampatzis. What Are SSL Stripping Attacks? Venafi, 2020.