HTTPS teeb kõik turvaliseks! Mis selle turvalisusega kaasneb?

HTTPS teeb kõik turvaliseks! Mis selle turvalisusega kaasneb?

 

Everything over HTTP

Algselt veebilehtede transportimiseks mõeldud HTTP protokoll on nüüdseks kasutusel sisuliselt kõikide internetirakenduste andmete transpordiks. DNS ja NTP on vist ainsad rakendused, mis oma andmeid HTTP sisse ei kapselda.

Ettevõtete ja teenusepakkujate andmesidevõrkudes on aastakümneid kasutusel olnud mitmesuguseid võrguliiklust jälgivaid ja analüüsivaid seadmeid, mis teatud juhtudel võimaldavad ka võrguliiklust blokeerida, ümber suunata või muuta – IDS/IPS, DLP, DPI, web filtering / URL classification, anti-virus, anti-spam, anti-malware, võrguliikluse mahtude ja iseloomu statistika analüüs jms. Senikasutatud lahtise tekstiga töötavate protokollide, ka HTTP ja sellesse kapseldatud rakenduste andmete jälgimine ja nendest arusaamine ei vaja erilisi tehnilisi vahendeid ega oskusi. Tihti on mitmed neist funktsioonidest integreeritud tulemüüriga, vahetevahel on aga iga asja jaoks oma “kast” ahelas, mille kogu võrguliiklus läbima peab.

Viimase kümnendi jooksul on erinevate turvariskide maandamiseks aina rohkem kasutama hakatud HTTP kodeeritud varianti HTTPS. Brauseri kaudu pakutavate veebiteenuste puhul on HTTPS kasulikud omadused arusaadavad – arvutikasutaja saab olla kindel teenusepakkuja isikus ja veebiliikluse ehtsuses ning kõik serveri ja brauseri vahel liikuvad andmed on kodeeritud; vajadusel saab ka teenusepakkuja veenduda kasutaja isikus. Kodeeritud andmed tähendavad kasutaja ja teenusepakkuja jaoks eelkõige seda, et pealtkuulaja ei saa pealtkuulatud andmetest midagi välja lugeda.

2016. aasta lõpus teatasid Mozilla ja Google, et kõigist Firefox ja Chrome veebibrauserite arvutivariantide näidatavatest veebilehtedest on HTTPS lehtede hulk ületanud HTTP oma. Mobiilseadmetes on HTTPS lehtede ja andmete transpordiks HTTPS’i kasutatavate rakenduste osakaal küll märgatavalt väiksem, kuid ilmselt ei lähe kaua aega, kui ka mobiilimaailmas see tasakaal pöördub.

Lahtisele HTTP liiklusele ei vaata enam hästi hindamisrobotid, turvaspetsid, vastavusnõuded ega audiitorid. Google – kes on peamine “kogu veeb HTTPS peale!” kuulutaja – otsing eelistab teatud juhtudel otsitulemuste seast just neid veebilehti, mida server pakub kasutajatele HTTPS vahendusel. Senini on HTTPS toimimiseks vajalikud serverisertifikaadid maksnud arvestataval määral ning nende serverisse paigaldamise ja regulaarne uuendamine on suures osas olnud käsitsi töö. Lets Encrypt projekt on paari aasta jooksul teinud HTTPS serverisertifikaadid kättesaadavaks täiesti tasuta ja toonud kaasa selle, et nende paigaldamine ei nõua enam suurt tehnilist taipu ja nende regulaarne uuendamine on automatiseeritav.

Internetis on tänu HTTPS’ile liiklus kaitstud kõrvaliste pilkude ja võltsimise eest ja kõik tunnevad ennast hästi. Aja möödudes saavad kõik aru, et lahtine HTTP liiklus on kui postkaardile kirjutatud saladus.

Everything over HTTPS

On selge, et kui lahtise HTTP asemele on tulnud kodeeritud HTTPS, siis tähendab see, et lisaks veebilehtedele on nüüd ka kõigi nende teiste HTTP sisse kapseldatud rakenduste liiklus kodeeritud. Kõik võrguliiklust jälgivad ja analüüsivad seadmed, mis ettevõtete võrkudes on senini edukalt toimetanud, ei oska kodeeritud liiklusest enam midagi välja lugeda, mille põhjal oma tööd teha.

Ka interneti varjupoolele jäävad tegelased, kelle huviks üldjuhul on varjata oma tegevuse pahaloomulisust võrguliikluse jälgimise ja kontrollimise süsteemide eest ning mööda pääseda rünnete tuvastamise mehhanismidest, on HTTPS’i näol leidnud endale käepärase vahendi oma liikluse peitmiseks nende süsteemide eest. HTTPS kodeerib viiruste ja pahavara signatuurid, rünnete mustrid, õngitsuskirjad jne. Ettevõttest välja liikuvad andmed jäävad HTTPS kasutamisel andmelekke tuvastamise süsteemidele (DLP) arusaamatuks.

Siinkohal tuleb appi “HTTPS inspection”, mis tähendab, et HTTPS-ühenduse otspunktide vahel tehakse ühendus katki ja kogu liiklus dekodeeritakse – sellest liiklusest saavad jälgimise ja analüüsimise süsteemid siis jälle aru – ning seejärel kodeeritakse uuesti. Tänu teatud tehniliste ja administratiivsete meetodite kasutamisele jääb arvutikasutajale ja teenusepakkujale mulje, et ühendus on ikka seesama otsast-otsani HTTPS. Kõik need jälgivad ja analüüsivad süsteemid saavad edukalt edasi töötada. Need „teatud“ administratiivsed meetodid tagavad samas selle, et HTTPS ühenduse katkestamist ei ole siiski võimalik teha kasutaja eest salaja. Kasutajal peab olema teadmine selle kohta, et tema HTTPS liigub võrgus mingil ajal lahtiselt.

Kui jälgivaid-analüüsivaid seadmeid on mitu ja need moodustavad topoloogiliselt ahela, siis „HTTPS inspection“ lahendus dekodeerib liikluse ühe korra, suunab lahtise liikluse läbi kogu selle ahela ning seejärel kodeerib uuesti.

Aga?

Kogu liiklust ei ole siiski mõtet või pole võimalik dekodeerida. Mõnedel juhtudel määravad regulatsioonid, mõnedel juhtudel head tavad, et teatud liiki internetiteenuste liiklust ei dekodeerita (finants- ja kindlustusteenused, terviseandmetega seotud teenused). Kui teenusepakkuja nõuab, et teenuse kasutamiseks tuvastaks klient end kliendisertifikaadi abil, ei ole võimalik „HTTPS inspection“ mehhanismi rakendada. On veel mõned tehnilised vahendid, mis liikluse dekodeerimise välistavad. Kõik „HTTPS inspection“ lahendused võimaldavad käsitsi luua nimekirju veebilehtedest või veebilehtede teemadest, mille liiklust ei dekodeerita –  nende nimekirjade ülalpidamine võib osutuda küllaltki mahukaks tööks.

Kuna „HTTPS inspection“ teeb HTTPS ühenduse katki, ei ole arvutikasutajal enam võimalik vajadusel kontrollida HTTPS serverisertifikaadis olevaid andmeid.

Kui jälgimise-analüüsimisega tegeleb vaid tulemüür ja „HTTPS inspection“ võimaldab tulemüüril toimetada ka kodeeritud liikluse kallal, siis on lihtne häälestada reegleid määramaks, kuidas tulemüür peab kasutajat informeerima liikluses tuvastatud probleemide puhul (veebileht veateatega, kommentaar pahaloomulise liikluse koht vms). Süsteemide ahela puhul võib olla keerukas probleemidest kasutajale teada anda muul viisil kui tühja brauseri aknaga või standardse brauseri „timeout“ või „no response from server“ veateatega.

„Mõned tehnilised vahendid“ võivad tulevikus ärgitada pahaloomulisi tegelasi leidma viise, kuidas neid vahendeid kasutades takistada „HTTPS inspection“ lahendustel liiklust dekodeerida.

SSL Orchestrator

SMN tootevalikus on „HTTPS inspection“ lahenduse jaoks olemas F5 Networks toode SSL Orchestrator. See toode saab olla omaette võrgukomponent või integreeritud olemasoleva BIG-IP’ga.

Äriline vaade: https://www.youtube.com/watch?v=A1iQ0F8Ejsk&list=PLU7nflXizssP3w_KXQiRtg51l6lcn03Aw&index=13 (40m 30s)

Tehniline vaade: https://www.youtube.com/watch?v=ObpSgRunCSo&list=PLU7nflXizssP3w_KXQiRtg51l6lcn03Aw&index=18 (37m 44s)

Detailne vaade: F5 hommikuseminar 17. novembril

Artikli autor SMN-i insener Tarmo Mamers

11.10.2017