HTTP/3 donosi bolje performanse i pouzdanost, pored raznih prednosti u bezbednosti i privatnosti, ali postoje i neki značajni izazovi. HTTP3, treća zvanična verzija protokola za prenos hiperteksta (HTTP), neće koristiti protokol za kontrolu prenosa (TCP) kao što su to radili njegovi prethodnici. Umesto toga, koristi protokol brzih UDP internetskih veza (QUIC) koji je Google razvio 2012. godine. QUIC je protokol transportnog sloja zasnovan na multipleksiranoj verziji korisničkog datagram protokola (UDP). Za razliku od TCP-a, UDP ne koristi TCP usaglašavanje u tri koraka, već samo jedno UDP dvosmerno rukovanje. Dakle, QUIC protokol eksponencijalno poboljšava mrežne performanse svake veb komponente jer koristi UDP za svaku vezu između korisnika-agenta i veb servera. Takođe, QUIC se kod upravljanja više interakcija između korisničkog agenta i servera oslanja na neprimetno multipleksiranje preko jedne veze, gde niko ne blokira drugog, pa tako pomaže poboljšanju performansi u poređenju sa prethodnim protokolima.
Zbog nekoliko prednosti iz perspektive performansi i pouzdanosti, HTTP/3 se smatra pravim rešenjem. Iz perspektive bezbednosti i privatnosti postoje i prednosti i ograničenja, a većina je detaljno istražena. Ovaj članak daje detalje o prednostima koje pruža HTTP/3 i neka bezbednosna razmatranja koja se moraju uzeti u obzir.
Bezbednosne karakteristike i prednosti
Šifriranje sa kraja na kraj
TCP protokol kreiran je tako da osigura da šifrovanje korisnog tereta bude prisutno sve vreme prenosa, ali informacije koje se odnose na prenos su i dalje nešifrovane, što dovodi do mnogo pitanja o bezbednosti i privatnosti. Kontramere dizajnirane i implementirane za sprečavanje ovih napada nisu na TCP steku, već na mrežnim i posrednčkim uređajima koji upravljaju protokolom i mrežom. Uz to, parseri izgrađeni za prevazilaženje ovih problema u balanserima opterećenja i ostalim mrežnim uređajima imaju ozbiljnih problema sa performansama i mogu da ograniče buduća proširenja mreže koja se brzo razvija i zavise od brzine i pouzdanosti mreže.
U QUIC protokolu nešifrovana su samo obavezna polja u mrežnom segmentu, dok su ostali podaci podrazumevano šifrovani. Poređenjem mrežnih segmenata TCP i QUIC, otkrivamo da su polja uključujući indikatore paketa (Packet NR i ACK NR), prozor i opcije u QUIC-u šifrovana, a u TCP-u nisu. Predložena enkripcija u QUIC-u pomaže u sprečavanju prodornih napada nadgledanja, koji su preovlađivali pre HTTP/3, kao i upadima prikupljanja podataka o artefaktima i metapodacima protokola i podacima aplikacija. Na sledećoj slici prikazano je kako QUIC protokol izgleda u alatu za analizu mreža, Wireshark. U mrežnom segmentu QUIC-a, sloj internetskog protokola (IP) sadrži podatke o izvornoj i odredišnoj IP adresi. UDP sadrži izvorni i odredišni port, dok QUIC sadrži javne indikatore, broj paketa, ID veze i šifrovani korisni teret.
TLS bezbedna povezanost
Za podršku šifriranju sa kraja na kraj tokom veze, QUIC se uveliko oslanja na kriptografiju i rukovanja transportnog sloja. Budući da QUIC direktno komunicira sa TLS 1.3, on zahteva da se šifrovanje koristi za sve odlazne veze i da ne postoji mogućnost da se onemogući TLS. QUIC takođe preuzima odgovornost za obezbeđivanje uspostavljanja bezbednih veza, uzimajući u obzir zaštitu poverljivosti i integriteta svih odlaznih veza. Za razliku od implementacije HTTP/2 + TLS, QUIC upravlja TLS mehanizmima rukovanja i uzbunjivanja u svom transportnom kontekstu, što zauzvrat pomaže QUIC-u da uspostavi kriptografsku zaštitu koristeći ključeve razmenjene u rukovanju.
Ako razmotrimo protokol kao celinu, postoje dve primarne komunikacije između TLS-a i QUIC-a:
1. QUIC pruža pouzdanu apstrakciju toka za TLS za slanje i primanje poruka kroz QUIC.
2. TLS ažurira QUIC komponentu sledećim:
1. Tajni, autentifikovani algoritmi za šifrovanje i funkciju izvođenja ključeva (KDF),
2. ključevi za zaštitu paketa,
3. promene stanja protokola (kao što su statusi rukovanja), sertifikati servera.
Za razliku od HTTP/2, koji koristi TLS-ove zapise „application_data“, QUIC koristi STREAM okvire u obliku QUIC paketa. TLS rukovanje se odvija u obliku CRYPTO okvira, koji se uglavnom sastoje od podataka o rukovanju u neprekidnom toku. QUIC je dizajniran za slanje paketa paralelno, ponekad pakuje različite poruke u jedan paket i šifruje ih, s obzirom da te poruke imaju isti nivo šifrovanja. Ova funkcija pruža odlične prednosti za performanse mreže i pri tom osigurava da se tokom prenosa primjenjuju pravilni načini šifrovanja.
Potpuna direktna tajnost
Savršena direktna tajnost (PFS – perfect forward secrecy) u protokolu može se postići kada se između korisničkih agenata i servera razmenjuju privremeni privatni ključevi. Svaka sesija koju inicira korisnički agent koristi novi jedinstveni ključ sesije koji nema nikakve veze sa ključem prethodne sesije. Upotrebom zasebnog ključa sesije za svaku transakciju, nijedna informacija iz ranijih ili narednih sesija ne može da bude ugrožena, čak i ako je neki ključ sesije ugrožen. Iz kriptografske perspektive, nijedna razmena ključeva ne može da osigura PFS. Međutim, novi termin, potpuna direktna tajnost, daje realna očekivanja PFS-a.
QUIC koristi TLS 1.3 koji podržava kako unapred poznat zajednički ključ (PSK) tako i Diffie-Hellman (DH) preko eliptičnih krivih (EC) DHE razmena ključeva ili ograničenih polja. Razmene ključeva 0-RTT pružaju potpunu direktnu tajnost, jer kriptografska specifikacija prihvata samo sigurne direktne veze putem rukovanja 0-RTT. Iako TLS 1.2 takođe podržava direktnu tajnovitost, tajnost se tehnički gubi prilikom nastavka sesije kada korisnički agent pošalje kopiju tajnog materijala zaštićenog simetričnim ključem poznatim jedino serveru. Protokol pruža potpunu direktnu tajnost čak i za početne poruke između korisničkog agenta i servera. Takođe, pošto protokol QUIC ne podržava dugoročne tajne ključeve, QUIC, uz pomoć TLS 1.3, može da obezbedi funkciju potpune direktne tajnosti za aplikacije koristeći svoj sloj protokola.
Zaštita od napada ponavljanjem
QUIC implementacija dizajnirana je da pored jednokratnog broja čuva i klijentske vrednosti izvođenja ključa. Server prepoznaje i odbacuje sve ponovljene zahteve sa istom vrednošću izvoda ključa i jednokratnog broja. Za ovaj dizajn se zna da je noćna mora za performanse, s obzirom na preopterećenje saobraćajem protokola između korisničkog agenta i servera. Teoretski, rešenje može izgledati primenljivo, ali u praksi, protokol može da postane glomazniji i da dovede do problema performansi. Trenutni dizajn nije najbolji, ali sprečava da bilo koji server više puta prihvati isti ključ sa nivoa protokola. Takođe, QUIC ne pruža zaštitu od ponovne reprodukcije tokom početnih koraka, jer pokreće zaštitu tek nakon početnog odgovora servera. Dizajn QUIC-a je da se početna transakcija štiti u aplikacijama i tako štedi preopterećenje protokola. S obzirom na to da veb komponente mogu da koriste ključ izveden iz ključa sesije, u ovoj fazi mogu da se pojave napadi ponavljanjem; međutim, da bi se to ublažilo mogu se primeniti mere predostrožnosti na nivou aplikacije.
Zaštita od lažiranja IP adresa
QUIC podržava procenu valjanosti adrese tokom rukovanja i zahteva potpisan dokaz o adresi, čime se eliminišu svi napadi lažiranjem IP adresa. Pitanje podmetanja IP adresa uglavnom se rešava u QUIC-u opsežnim korišćenjem „tokena adrese izvora“, a to je serverski verifikovan blok šifrovanja koji sadrži IP adresu korisničkog agenta i vremensku oznaku servera. Korisnički agenti mogu više puta da koriste token izvorne adrese generisan u serveru sve dok se njihove IP adrese ne pomere zbog promene povezivanja. Pošto se tokeni izvorne adrese koriste kao tokeni nosioca, oni mogu više puta da se koriste, a sva ograničenja IP adrese koja postavlja server mogu da se zaobiđu. Pošto server šalje odgovor samo na IP adresu u tokenu, čak i ukradeni kolačić ili token ne može da dovede do uspešnog lažiranja IP adrese. Takođe, imajući u vidu da QUIC podržava kratkotrajne tokene adrese izvora, vremenski prozor uspešnog napada lažiranjem IP adrese biće praktično gotovo nemoguć.
Sprečavanje smanjenjem SSL-a
Po dizajnu, TLS 1.3 štiti od napada smanjenjem na bezbednost transportnog sloja jer protokol nalaže heš ključeva svih komunikacija pri rukovanju i zahteva da prijemnik rukovanja potvrdi poslani heš ključa. Tokom rukovanja, svaki otkriveni pokušaj neovlašćenog menjanja klijentskih mogućnosti rezultiraće prekidom rukovanja sa greškom. Pored toga, poruke CertificateVerify između korisničkog agenta i servera sadrže PKCS RSA heširan potpis svih prethodnih poruka o konkretnoj vezi. Ova primena kontrolne sume u QUIC-u sprečiće uspešan napad smanjenjem bezbednosti na transportni sloj.
Uticaji HTTP/3 na bezbednost
Ranjivosti 0-RTT nastavka
Jedna od najpovoljnijih karakteristika HTTP/3 je 0-RTT nastavak, koji drastično unapređuje brzinu povezivanja i smanjuje kašnjenje. Međutim, ovaj proces funkcioniše jedino ako postoji prethodna uspešno uspostavljena veza, a trenutna transakcija koristi prethodnu zajedničku tajnu koja je uspostavljena tokom poslednje veze. Postoje bezbednosni nedostaci zbog funkcije 0-RTT nastavka. Jedan od najčešćih puteva napada je napad ponavljanjem koji može da nastane kada protivnik ponovo pošalje početni paket; u određenim scenarijima ovo može prisiliti server da poveruje da je zahtev potekao od ranije poznatog klijenta. Drugi bezbednosni nedostatak 0-RTT nastavka je delimični neuspeh potpune direktne tajnosti. Ako protivnik kompromituje tokene, on može da dešifruju 0-RTT komunikaciju koju šalje korisnički agent.
Napadi manipulisanjem ID-a veze
Napadi manipulisanjem ID-a veze zahtevaju da se napadač postavi između korisničkog agenta i servera. On može da manipuliše ID-om veze tokom početnog rukovanja gde se razmenjuju pozdravne poruke klijenta i servera. Rukovanje će se odvijati kao normalno i server će pretpostaviti da je veza uspostavljena, ali korisnički agent neće moći da dešifruje jer je ID veze ulaz u proces izvođenja ključa za šifrovanje, pa će korisnički agent i server izračunati različite ključeve za šifrovanje. Korisničkom agentu će da istekne vreme, pa će vratiti na server poruku o grešci – saopštenje da je veza prekinuta. Budući da klijent poruku o grešci koju šalje serveru šifrira originalnim ključem za šifrovanje, server neće uspeti da dešifruje poruku i zadržaće stanje veze sve dok ne istekne vreme za neaktivnu vezu (obično 10 minuta).
Kada se izvodi u većem obimu, isti napad može da napravi napad uskraćivanjem usluge na serveru, pri čemu se više veza zadržava sve dok stanje veza ne istekne. Drugi način napada da bi se veza održala živom bila bi promena drugih parametara kao što su tokeni adrese izvora, čime se klijentima onemogućava uspostavljanje bilo kakve veze.
UDP napad pojačanjem
Za uspešan napad pojačanjem, protivnik mora da lažira IP adresu žrtve i pošalje UDP zahtev serveru. Ako server vrati značajniji UDP odgovor, protivnik može da iskoristi ovo ponašanje servera u većem obimu i napravi scenario DDoS napada.
Konkretno, u QUIC-u UDP napadi pojačanjem se dešavaju kada protivnik prihvati od cilja token za potvrdu adrese i oslobodi IP adresu koja je inicijalno upotrebljena za generisanje tokena. Napadač može da pošalje 0-RTT vezu na server sa istom IP adresom, koja se možda promenila i ukazuje na drugu krajnju tačku. Uspešnim izvršenjem ove situacije, napadač potencijalno može da naredi serveru da pošalje značajan promet prema serveru žrtve. Da bi se sprečio ovaj napad, HTTP/3 ima mogućnost ograničavanja brzine i kratkotrajne tokene za potvrdu koji mogu da deluju kao kompenzaciona kontrola DDoS napada, delimično ublažujući scenario napada.
Napad iscrpljivanja tokovima
Napad iscrpljivanja tokovima događa se kada protivnik namerno pokrene više tokova povezivanja, što dovodi do iscrpljivanja krajnje tačke. Napadač može da iskoristi iscrpljujuću sekvencu tako što će zahtev plaviti više puta. Mada određeni transportni parametri mogu da ograniče broj istovremenih aktivnih tokova, ponekad se konfiguracija servera namerno postavlja na veći broj. Napadnuti serveri mogu biti meta takvih napada jer je serverov protokol tako konfigurisan radi povećanja performansi protokola.
Napad resetovanjem veze
Napadi resetovanjem veze uglavnom žrtvama šalju resetovanja bez stanja, što otvara mogućnost napada odbijanjem usluga sličnih napadima injekcijom TCP resetovanja. Potencijalni put napada moguć je ako protivnik uspe da dođe do tokena za resetovanje generisanog za vezu sa određenim ID-om veze. Konačno, napadač može pomoću tokena generisanog za resetovanje aktivne veze koja ima isti ID veze, da primora server da čeka vezu dok ne dođe do tajmauta. Ako se ovaj napad izvrši u većem obimu, server mora značajno da troši svoje resurse samo čekajući da se veze završe.
Napad spuštanjem QUIC verzije
Zaštita QUIC paketa predviđa proveru autentičnosti i šifrovanje za sve pakete u komunikaciji, osim za pregovaračke pakete o verziji. Paketi za pregovaranje o verziji dizajnirani su za pregovaranje o verziji QUIC-a između korisničkog agenta i servera. Ova funkcija može da omogući napadaču da izvrši spuštanje verzije na potencijalno nesigurnu verziju QUIC-a. Ovaj napad trenutno nije primenljiv jer postoji samo jedna verzija QUIC-a, ali na njega treba paziti ubuduće.
Nedostatak podrške u praćenju
Iako nekoliko korisničkih agenata, servera i uglednih veb lokacija podržava HTTP3 / QUIC, mnogi mrežni uređaji kao što su proksiji prosleđivanja i vraćanja, balanseri opterećenja, veb aplikacije za mrežne barijere i alati za praćenje bezbednosnih događaja ne podržavaju u potpunosti HTTP/3. Za razliku od TCP-a, u QUIC vezi nisu potrebni soketi, što otežava otkrivanje domaćina i zlonamernih veza. Zlonamerni napadač može biti u stanju da prosledi zlonamerne aktivne sadržaje i izvrši napade povlačenja podataka putem QUIC-a i da ostane sakriven, jer većina alata za otkrivanje ne bi otkrila QUIC saobraćaj.
Istorija QUIC-a
Tokom 2016. godine, radna grupa za internet inženjering (IETF) započela je standardizaciju Googleovog QUIC-a, a nedavno je najavila da je IETF QUIC okosnica nove verzije HTTP/3. Međutim, IETF QUIC se značajno razlikuje od originalnog QUIC dizajna, iz razloga performansi i bezbednosti. Tradicionalni veb saobraćaj preko TCP-a zahteva rukovanje u tri koraka; QUIC koristi UDP, koji ubrzava veb saobraćaj zbog manje kašnjenja zahvaljujući manjem broju povratnih putovanja i manje poslatih paketa. Pored toga što je brži, UDP pruža i nekoliko prednosti, uključujući migraciju konekcije, poboljšanu latenciju, kontrolu zagušenja i ugrađenu enkripciju. Prema Google-u, „QUIC rukovanje često zahteva nula povratnih putovanja pre slanja korisnog tereta, u poređenju sa 1–3 povratna putovanja za TCP + TLS.“ Prvo povezivanje zahteva jedno povratno putovanje, a za sledeća nisu potrebne povratna putovanja. Takođe, budući da je QUIC namenjen multipleksiranom radu, on se bolje nosi sa gubitkom paketa u odnosu na TCP i omogućava brže rukovanje.
Google-ova verzija QUIC-a sada je gQUIC. HTTP/3 se značajno razvio u odnosu na gQUIC doprinosima i poboljšanjima radne grupe IETF. Iako je, tehnički, HTTP/3 potpuni protokol aplikacije, QUIC se obraća protokolu transporta u osnovi, koji nije ograničen na servisiranje veb saobraćaja. UDP je bez uspostavljanja veze i nije mnogo pouzdan; QUIC prevazilazi ova ograničenja dodavanjem steka sličnog TCP-u preko UDP-a da bi dodao pouzdanu vezu i ponavlja slanje sa funkcijama kontrole protoka preko njega, dok rešava TCP-ov problem blokiranja prvog paketa u nizu.
HTTP/3 koristi UDP, slično kao što HTTP/2 koristi TCP. Svaka veza ima nekoliko paralelnih tokova koji se koriste za istovremeno prenošenje podataka preko iste veze bez uticaja na druge tokove. Dakle, za razliku od TCP-a, izgubljeni paketi koji nose podatke za određeni tok utiču samo na taj konkretan tok. Svaki okvir toka može zatim odmah po dolasku da se pošalje u taj tok, tako da se tok i dalje može u aplikaciji ponovo sastaviti bez gubitaka. Ova QUIC-ova strategija uspostavljanja veze omogućena je kombinacijom kripto i transportnih rukovanja.
Uporedna analiza sa HTTP/2
QUIC je kreiran za poboljšanje performansi tako što ublažava probleme gubitaka i kašnjenja paketa iz HTTP/2. Pošto HTTP/2 koristi jednu TCP vezu za svaki izvor, to dovodi do problema sa blokiranjem prvog paketa u nizu. Na primer, objekat zahteva može da ostane blokiran iza drugog objekta koji je doživeo gubitak, sve dok se ne oporavi. QUIC rešava ovaj problem tako što sloj toka HTTP/2 spušta u transportni sloj, čime se izbegava problem kako na aplikativnom tako i na transportnom sloju. HTTP/3 takođe omogućava multipleksiranje, jer isporučuje zahtev nezavisno od drugih zahteva za povezivanje, dok se istovremeno direktno integriše sa TLS-om. Dok HTTP/2 i HTTP/3 rade na sličan način, ovde su neke od značajnih razlika u karakteristikama HTTP/2 i HTTP/3.
Razlike HTTP/2 HTTP/3
Transport TCP QUIC sa UDP
Sloj toka Aplikacije Transportni
Podrazumevano šifrovanje Ne Da
Nezavisni tokovi Ne Da
Kompresija zaglavlja HPACK QPACK
Rukovanje Brži 0-RTT 1-3 RTT za TCP + TLS
Slabljenje veze Ne Da
Oporavak od gubitka kontrole zagušenja Vrši TCP Vrši QUIC
Iz perspektive mrežnog steka, HTTP/2 uveliko koristi TLS 1.2+ u skladu sa HTTP standardom, pri čemu TCP djeluje kao protokol prenosa u osnovi. Međutim, u HTTP/3, TLS 1.3 se podrazumevano koristi pored QUIC-a, pri čemu je UDP protokol prenosa. Sledeći dijagram ilustruje gde se QUIC nalazi u steku mrežnih protokola. Za poređenje, prethodna verzija koristi TLS 1.2 i upotrebljava funkcije za oporavak od gubitka kontrole zagušenja TCP-a, pri čemu HTTP/2 rukuje mogućnostima multi-streaminga.
Sloj aplikacije HTTP/3
Sloj prezentacije QUIC, TLS 1.3
Sloj sesije
Transportni sloj UDP
Prednosti ID-a veze
TCP veze dizajnirane su tako da za identifikaciju određene veze koriste mrežne subjekte izvora i odredišta (uglavnom adrese i portove). Međutim, QUIC veza koristi ID veze, što je 64-bitni slučajno generisani identifikator klijenta. Ova promena je veoma korisna za trenutne veb tehnologije, pošto su one potrebne za podršku mobilnosti korisnika kao glavnog faktora. Ako korisnik pređe sa Wi-Fi mreže na mobilnu mrežu, HTTP/2 TCP protokol bi morao da uspostavi novu vezu na osnovu trenutne adrese. Međutim, budući da HTTP/3 QUIC protokol koristi slučajni ID veze, klijent koji menja IP adresu na HTTP/3, pri prelasku sa mobilne mreže na Wi-Fi vezu, nastaviće bez prekida da koristi postojeći ID veze.
Iz aspekta protokola, ID veze pruža dodatne prednosti. Server i korisnički agenti mogu da prepoznaju originalnu vezu u vezi za ponovno slanje koristeći ID veze i izbegnu probleme nedoumice kod ponovnog slanja koji preovlađuju u TCP-u.
Zaključak
QUIC već doživljava potpuno prihvatanje i podršku pretraživača; značajne veb stranice poput YouTube-a i Facebooka omogućile su ga, za brže učitavanje stranica. Dok ovo pišemo svega 4% najboljih sajtova trenutno podržava QUIC. Microsoft je najavio da će u kernelu isporučivati Windows sa QUIC bibliotekom opšte namene, MsQuic, radi podrške različitih funkcija prijemnog poštanskog sandučeta. QUIC i HTTP/3 dizajnirani su tako da odgovore današnjim ciljevima performansi, pouzdanosti i bezbednosti Interneta i mreže. Došlo je do značajnih poboljšanja bezbednosti sa obaveznom podrškom za TLS 1.3, čime se rešavaju slabosti u HTTP/2 i prethodnim verzijama HTTP-a. Upotreba šifrovanja sa kraja na kraj tokom tranzita u HTTP/3 pomaže odbrani od nekoliko problema privatnosti s učesnicima stanja i agregatorima podataka. Iako ima nekih slabosti, HTTP/3 će nastaviti da se razvija i predstavlja značajno poboljšanje u odnosu na HTTP/2, kako iz aspekta performansi, tako i iz aspekta bezbednosti.
Izvor: CSO