ZADÁNÍ DIPLOMOVÉ PRÁCE

Název: Modernizace podpory protokolů SSL/TLS v Privoxy Student: Bc. Václav Švec Vedoucí: Ing. Josef Kokeš Studijní program: Informatika Studijní obor: Počítačová bezpečnost Katedra: Katedra informační bezpečnosti Platnost zadání: Do konce letního semestru 2020/21

Pokyny pro vypracování

1) Proveďte rešerši vývoje šifrovaného HTTP v aktuálních prohlížečích za poslední tři roky. Zohledněte i změny v používaných certifikátech. 2) Zhodnoťte, jak tento vývoj ovlivňuje problematiku filtrování HTTPS pomocí proxy serveru. Vyjděte ze své předchozí implementace podpory SSL/TLS do Privoxy. 3) Navrhněte úpravy do Privoxy pro modernizaci jeho SSL/TLS podpory a zajištění jeho funkcionalit při filtrování komunikace moderních prohlížečů. 4) Analyzujte další uživatelské a programátorské nedostatky předchozí verze podpory SSL/TLS a navrhněte jejich řešení. 5) Proveďte takové úpravy v Privoxy, které popsané nedostatky vyřeší. 6) Otestujte původní i modernizovanou verzi Privoxy v aktuálně používaných prohlížečích. 7) Diskutujte dosažené výsledky.

Seznam odborné literatury

Dodá vedoucí práce.

prof. Ing. Róbert Lórencz, CSc. doc. RNDr. Ing. Marcel Jiřina, Ph.D. vedoucí katedry děkan

V Praze dne 31. ledna 2020

Diplomov´apr´ace

Modernizace podpory protokol˚uSSL/TLS v Privoxy

Bc. V´aclav Svecˇ

Katedra informaˇcn´ıbezpeˇcnosti Vedouc´ıpr´ace:Ing. Josef Kokeˇs

18. kvˇetna2020

Podˇekov´an´ı

R´adbych podˇekoval Ing. Josefu Kokeˇsovi za jeho cenn´erady, podnˇetn´epˇripo- m´ınkya velmi vstˇr´ıcn´ya obˇetav´ypˇr´ıstuppˇriveden´ıt´etopr´ace.

Prohl´aˇsen´ı

Prohlaˇsuji,ˇzejsem pˇredloˇzenoupr´acivypracoval(a) samostatnˇea ˇzejsem uvedl(a) veˇsker´epouˇzit´einformaˇcn´ızdroje v souladu s Metodick´ympokynem o etick´epˇr´ıpravˇevysokoˇskolsk´ych z´avˇereˇcn´ych prac´ı. Beru na vˇedom´ı,ˇzese na moji pr´aci vztahuj´ıpr´ava a povinnosti vypl´yvaj´ıc´ı ze z´akona ˇc.121/2000 Sb., autorsk´ehoz´akona, ve znˇen´ıpozdˇejˇs´ıch pˇredpis˚u. V souladu s ust. § 46 odst. 6 tohoto z´akona t´ımto udˇelujinev´yhradn´ıopr´avnˇen´ı (licenci) k uˇzit´ıt´etomoj´ıpr´ace, a to vˇcetnˇevˇsech poˇc´ıtaˇcov´ych program˚u,jeˇz jsou jej´ısouˇc´ast´ıˇcipˇr´ılohou,a veˇsker´ejejich dokumentace (d´alesouhrnnˇejen D´ılo“), a to vˇsemosob´am,kter´esi pˇrej´ıD´ılouˇz´ıt.Tyto osoby jsou opr´avnˇeny ” D´ılouˇz´ıtjak´ymkoli zp˚usobem, kter´ynesniˇzujehodnotu D´ıla,a za jak´ymkoli ´uˇcelem(vˇcetnˇeuˇzit´ık v´ydˇeleˇcn´ym´uˇcel˚um).Toto opr´avnˇen´ıje ˇcasovˇe,teri- tori´alnˇei mnoˇzstevnˇeneomezen´e.Kaˇzd´aosoba, kter´avyuˇzijev´yˇseuvedenou licenci, se vˇsakzavazuje udˇelitke kaˇzd´emu d´ılu,kter´evznikne (byt’ jen zˇc´asti) na z´akladˇeD´ıla,´upravou D´ıla,spojen´ımD´ılas jin´ymd´ılem,zaˇrazen´ımD´ıla do d´ılasouborn´ehoˇcizpracov´an´ımD´ıla(vˇcetnˇepˇrekladu),licenci alespoˇnve v´yˇseuveden´emrozsahu a z´aroveˇnzpˇr´ıstupnitzdrojov´yk´odtakov´ehod´ılaale- spoˇnsrovnateln´ymzp˚usobem a ve srovnateln´emrozsahu, jako je zpˇr´ıstupnˇen zdrojov´yk´odD´ıla.

V Praze dne 18. kvˇetna2020 ...... Cesk´evysok´euˇcen´ıtechnick´evˇ Praze Fakulta informaˇcn´ıch technologi´ı © 2020 V´aclav Svec.ˇ Vˇsechna pr´ava vyhrazena. Tato pr´ace vznikla jako ˇskoln´ı d´ılo na Cesk´emvysok´emuˇcen´ıˇ technick´em v Praze, Fakultˇeinformaˇcn´ıch technologi´ı.Pr´ace je chr´anˇenapr´avn´ımipˇredpisy a mezin´arodn´ımi´umluvamio pr´avuautorsk´ema pr´avech souvisej´ıc´ıchs pr´avem autorsk´ym.K jej´ımuuˇzit´ı,s v´yjimkoubez´uplatn´ychz´akonn´ychlicenc´ıa nad r´amec opr´avnˇen´ıuveden´ychv Prohl´aˇsen´ına pˇredchoz´ıstranˇe,je nezbytn´ysou- hlas autora.

0.0.1 Odkaz na tuto pr´aci Svec,ˇ V´aclav. Modernizace podpory protokol˚uSSL/TLS v Privoxy. Diplomov´a pr´ace.Praha: Cesk´evysok´euˇcen´ıˇ technick´ev Praze, Fakulta informaˇcn´ıch technologi´ı,2020. Abstrakt

Pr´acereaguje na v´yvoj ˇsifrovan´ehoHTTP v modern´ıch webov´ych prohl´ıˇzeˇc´ıch bˇehemposledn´ıtˇr´ılet. Zejm´enase zamˇeˇrujena zmˇeny, kter´ese t´ykaj´ıproxy server˚ua webov´ych certifik´at˚ua hodnot´ıjejich dopady na filtrov´an´ıHTTPS pomoc´ıproxy server˚u.Souˇc´ast´ıpr´aceje i n´avrha implementace ´uprav, kter´e rozˇsiˇruj´ıpˇredchoz´ıimplementaci podpory SSL/TLS do proxy serveru Privoxy. Tyto ´upravy umoˇzˇnuj´ı filtrov´an´ı veˇsker´ekomunikace modern´ıch webov´ych prohl´ıˇzeˇc˚ua z´aroveˇnkladou d˚urazna zachov´an´ıdostateˇcn´ehov´ykonu proxy serveru. Dosaˇzen´ev´ysledkyjsou testov´any a zhodnoceny v porovn´an´ıs pˇred- choz´ımiverzemi Proxy serveru Privoxy. Z´aroveˇnjsou doplnˇeny o dalˇs´ıvhodn´a vylepˇsen´ı.

Kl´ıˇcov´a slova webov´yprohl´ıˇzeˇc,proxy server, filtrov´an´ı, Privoxy, TLS, HTTPS

7 Abstract

The thesis reacts to the development of encrypted HTTP in modern web browsers over the last three years. It focuses particularly on changes that af- fect proxy servers and web certificates and evaluates their impact on HTTPS filtering using proxy servers. The thesis also includes the design and implemen- tation of modifications that extend the previous implementation of SSL/TLS support to the Privoxy proxy server. These modifications allow filtering of all communication of modern web browsers and at the same time emphasize the maintenance of sufficient proxy server performance. The achieved results are tested and evaluated in comparison with previous versions of the Privoxy proxy server. At the same time, they are supplemented by other suitable im- provements.

Keywords web browser, proxy server, filtering, Privoxy, TLS, HTTPS

8 Obsah

Uvod´ 1

1 Vyvoj´ ˇsifrovan´eho HTTP 3 1.1 Prvn´ıverze protokolu a jej´ıvylepˇsen´ı...... 3 1.2 HTTP/2 ...... 4 1.3 HTTPS ...... 4 1.4 Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch ...... 5 1.4.2 Odstranˇen´ıCBC m´oduu ECDSA TLS ...... 5 1.4.3 Odebr´an´ıTLS 1.2 ECDSA s SHA-1 a SHA-512 . . . . . 5 1.4.4 Ukonˇcen´ıd˚uvˇerypro SHA-1 certifik´aty ...... 6 1.4.5 Odebr´an´ınestandardizovan´everze ChaCha20-Poly1305 6 1.4.6 Cookies striktnˇepˇresHTTPS spojen´ı ...... 7 1.4.7 Podpora shody Common Name v certifik´atech ...... 7 1.4.8 Pˇrihlaˇsovac´ı´udaje v dotazech na subresource ...... 7 1.4.9 Certificate Transparency (CT) ...... 8 1.4.10 Notifikaˇcn´ıAPI jen pˇresHTTPS ...... 10 1.4.11 TLS 1.3 ...... 10 1.4.12 Komprese certifik´at˚u...... 11 1.4.13 AppCache pouze pro zabezpeˇcen´eHTTP ...... 11 1.4.14 Uprava´ hodnot User-Agent ...... 11 1.4.15 Token Binding ...... 12 1.4.16 Zneplatnˇen´ıcertifik´at˚uSymantec ...... 14 1.4.17 Odebr´an´ıHTTP Public Key Pinning ...... 14 1.4.18 Web Packaging ...... 15 1.4.19 Hodnota User-Agent v hlaviˇcce CONNECT ...... 15 1.4.20 Sm´ıˇsen´yobsah ...... 16 1.4.21 Parametr SameSite u cookies ...... 17 1.4.22 TLS 1.0 a TLS 1.1 ...... 18 1.4.23 Opatˇren´ıproti TLS downgrade ´utok˚um ...... 18

9 1.4.24 Stahov´an´ıze zabezpeˇcen´ehokontextu ...... 19 1.4.25 Zastar´an´ınezabezpeˇcen´ehoHTTP ...... 19 1.5 Souhrn ...... 19

2 Dopady pro proxy servery 23 2.1 Zmˇeny v certifik´atech ...... 23 2.2 Zmˇeny pro proxy servery ...... 27

3 N´avrh uprav´ 33 3.1 Proxy server Privoxy ...... 33 3.2 V´ystupbakal´aˇrsk´epr´ace...... 33 3.3 Novˇeimplementovan´arozˇs´ıˇren´ı ...... 36

4 Implementace 41 4.1 Pouˇzit´ıverzovac´ıhosyst´emu Git ...... 41 4.2 Zmˇenakryptografick´eknihovny ...... 43 4.3 Konfigurace kompilaˇcn´ıch skript˚u...... 44 4.4 Filtrov´an´ıpˇrijat´ych poˇzadavk˚u ...... 45 4.5 Zmˇeny konfiguraˇcn´ıhorozhran´ı ...... 50 4.6 Opakovan´epouˇz´ıv´an´ıTLS sessions ...... 52 4.7 Sd´ılen´ıTLS sessions ...... 59 4.8 Konfigurace ˇsifrov´ych sad ...... 62

5 Testov´an´ı dosaˇzenych´ vysledk´ ˚u 65 5.1 Funkˇcnost...... 65 5.2 V´ykonnost ...... 66 5.3 Bezpeˇcnost ...... 69 5.4 Dalˇs´ımoˇznosti rozvoje ...... 69

Z´avˇer 73

Literatura 75

A Seznam pouˇzitych´ zkratek 79

BUˇzivatelsk´a pˇr´ıruˇcka 81 B.1 Poˇzadavky pro instalaci ...... 81 B.2 Instalace ...... 81 B.3 Nastaven´ıwebov´ehoprohl´ıˇzeˇce ...... 82 B.4 Konfigurace proxy serveru ...... 82

C Obsah pˇriloˇzen´eho CD 85

10 Seznam obr´azk˚u

1.1 Komunikace jednotliv´ych prvk˚uCT ...... 9 1.2 Komunikace pˇripouˇzit´ıprotokolu Token Binding ...... 13 1.3 Uk´azkaprobl´emu se sm´ıˇsen´ymobsahem ...... 16 1.4 TLS verze protokolu a jejich vyuˇz´ıv´an´ıve webov´em prohl´ıˇzeˇci. . . 18

2.1 Parametry certifik´atu www.privoxy.org ...... 24 2.2 Uk´azkaparametru SCT list v certifik´atu www.privoxy.org . . . . . 25 2.3 Nastaven´ı´uˇcelupro certifik´at www.privoxy.org ...... 27 2.4 Rozdˇelen´ıTLS spojen´ıpˇripouˇzit´ıproxy serveru ...... 30

3.1 Srovn´an´ıp˚uvodn´ıdoby naˇc´ıt´an´ıwebov´ych str´anekpodle metody . 38 3.2 Naˇc´ıt´an´ıjednotliv´ych ˇc´ast´ıwebov´estr´ankyv bakal´aˇrsk´epr´aci. . . 39

4.1 Zpracov´an´ıHTTPS komunikace metodou TLS tunelu ...... 48 4.2 Zpracov´an´ıHTTPS komunikace metodou MITM ...... 49 4.3 Zpracov´an´ıHTTPS komunikace rozˇs´ıˇren´ımiv diplomov´epr´aci . . 50 4.4 Konfiguraˇcn´ırozhran´ıPrivoxy ...... 51 4.5 Princip opakovan´eho pouˇz´ıv´an´ızabezpeˇcen´ych spojen´ı ...... 53 4.6 Pˇrij´ım´an´ıpoˇzadavk˚ubez a s opˇetovn´ymvyuˇz´ıv´an´ımTLS spojen´ı. 56 4.7 TLS sessions s nadˇrazen´ymproxy, kratˇs´ılok´aln´ıˇcasov´ylimit . . . 58 4.8 TLS sessions s nadˇrazen´ymproxy, delˇs´ılok´aln´ıˇcasov´ylimit . . . . 59

5.1 Srovn´an´ıdoby naˇc´ıt´an´ıwebov´ych str´anekpodle pouˇzit´emetody . 67 5.2 Vliv hodnoty parametru na dobu naˇc´ıt´an´ıwebov´ych str´anek. . . . 68

11

Seznam tabulek

1.1 Srovn´an´ıv´yvoje ˇsifrovan´ehoHTTP ve webov´ych prohl´ıˇzeˇc´ıch . . . 20

4.1 Pouˇzit´ınov´ych pˇrep´ınaˇc˚ukonfiguraˇcn´ıhoskriptu ...... 45 4.2 V´ybˇerobsluhovan´ehospojen´ına z´akladˇeparametr˚u ...... 47 4.3 Funkce nezbytn´epro zaˇclenˇen´ınov´ekryptografick´eknihovny . . . 60

5.1 Podpora kryptografick´ych protokol˚ua algoritm˚uv Privoxy . . . . 66 5.2 UspˇeˇsnostPrivoxy´ pˇriodhalov´an´ınedostatk˚uSSL/TLS spojen´ı . . 70

13

Uvod´

Technologie pro pˇrenosdat mezi dvˇemakoncov´ymizaˇr´ızen´ımi se neust´ale vyv´ıj´ıod prvn´ıch experiment´aln´ıch s´ıt´ıaˇzpo nejnovˇejˇs´ıverze protokolu HTTP. V pr˚ubˇehu tohoto v´yvoje vznikly webov´eprohl´ıˇzeˇcejako n´astroje umoˇzˇnuj´ıc´ı jednoduˇs´ıa efektivnˇejˇs´ız´ısk´an´ıa zobrazen´ıdat. Modern´ıwebov´eprohl´ıˇzeˇcere- aguj´ına v´yvoj nov´ych technologi´ıa mnohdy tento v´yvoj i pˇredurˇcuj´ı.Zmˇen´am se pot´emus´ıpˇrizp˚usobiti mezilehl´azaˇr´ızen´ı,jako jsou napˇr´ıkladproxy ser- very. Jen tak mohou uˇzivatel˚umzaruˇcitbezprobl´emovou funkˇcnostpˇripouˇzit´ı modern´ıch webov´ych prohl´ıˇzeˇc˚u. Proxy servery rozˇsiˇruj´ımoˇznostiuˇzivatel˚unapˇr´ıklado filtrov´an´ıveˇsker´e pˇren´aˇsen´ekomunikace. To umoˇzˇnujeodstranˇen´ı neˇz´adouc´ıho obsahu, jako jsou napˇr´ıkladreklamy. C´ılen´efiltrov´an´ıkomunikace ovˇsemm˚uˇzeslouˇziti pro zv´yˇsen´ıbezpeˇcnostiuˇzivatele. K tomu slouˇz´ınapˇr´ıkladblokov´an´ıpoˇzadavk˚u na potencion´alnˇenebezpeˇcn´eskripty, ˇcizmˇenaobsahu poˇzadavk˚utak, aby byla zt´ıˇzenaidentifikace jejich odesilatele. C´ılem t´eto diplomov´epr´aceje anal´yzamodern´ıch webov´ych prohl´ıˇzeˇc˚u z hlediska v´yvoje ˇsifrovan´ehoHTTP bˇehemposledn´ıch tˇr´ılet. Z´aroveˇnse pr´ace vˇenuje souvisej´ıc´ımzmˇen´amv pouˇz´ıvan´ych webov´ych certifik´atech, kter´emo- hou b´ytbˇehemnavazov´an´ıˇsifrovan´ehoHTTP spojen´ıvyuˇzity k autentizaci protistrany. Na z´akladˇet´etoanal´yzy a anal´yzypˇredchoz´ıverze podpory TLS v proxy serveru Privoxy jsou n´aslednˇenavrˇzenaa implementov´anavhodn´a rozˇs´ıˇren´ı tohoto proxy serveru. Ta umoˇzˇnuj´ı filtrovat veˇskerou HTTPS ko- munikaci pˇren´aˇsenoupˇresproxy server, a to vˇcetnˇeHTTP hlaviˇcek.Z´aroveˇn tato rozˇs´ıˇren´ızohledˇnuj´ıv´yvoj aktu´aln´ıch webov´ych prohl´ıˇzeˇc˚u.D´ıkytomu je zaruˇcenakompatibilita v´ysledn´ehoˇreˇsen´ıs tˇemitoprohl´ıˇzeˇci. Implementaˇcn´ıˇc´astpr´acenavazuje na v´ystupy bakal´aˇrsk´epr´ace[1],kter´a poskytuje rozˇs´ıˇren´ıumoˇzˇnuj´ıc´ıˇc´asteˇcnˇefiltrovat TLS komunikaci v proxy se- veru Privoxy. Proto se tato pr´acezamˇeˇruje i na uˇzivatelsk´ea program´atorsk´e nedostatky pˇredchoz´ıch verz´ı proxy serveru, pro kter´ejsou navrˇzenaa im- plementov´ananov´avhodnˇejˇs´ıˇreˇsen´ı. Anal´yzanedostatk˚use pak zamˇeˇruje

1 Uvod´ zejm´enana zjednoduˇsen´ı zdrojov´eho k´oduproxy serveru tak, aby byl jed- noduˇsejispravovateln´ya rozˇsiˇrovateln´y.D´alejsou analyzov´any moˇznostipro zajiˇstˇen´ıdostateˇcn´ehov´ykonu pro praktick´evyuˇz´ıv´an´ıproxy serveru. Toho je dosaˇzenod´ıkyimplementaci nov´ych podp˚urn´ych mechanism˚u. Souˇc´ast´ıpr´aceje i testov´an´ıdosaˇzen´ych v´ysledk˚ua vyhodnocen´ıtˇechto test˚u,a to z pohledu funkˇcnosti,bezpeˇcnostia v´ykonnosti. Tyto v´ysledky jsou z´aroveˇnsrovn´any s v´ysledkymodern´ıch webov´ych prohl´ıˇzeˇc˚u,pˇr´ıpadnˇe s pˇredchoz´ımiverzemi proxy serveru Privoxy. Naznaˇcenajsou i vhodn´abu- douc´ırozˇs´ıˇren´ıproxy serveru.

2 Kapitola 1

V´yvojˇsifrovan´ehoHTTP

Protokol HTTP (HyperText Transfer Protocol) vytvoˇril v letech 1989 aˇz1991 Tim Berners-Lee a jeho t´ym.Jedn´ase o z´akladn´ıprotokol pro komunikaci klienta s WWW (World Wide Web) servery, kter´yumoˇzˇnujepˇren´aˇsetnejen hypertextov´edokumenty, ale i jin´etypy soubor˚u.Od sv´ehovzniku aˇzdo souˇcasnostiproˇselˇradouzmˇen.Tato kapitola se vˇenuje v´yvoji tohoto pro- tokolu se zamˇeˇren´ım na jeho ˇsifrovanou verzi, tedy HTTP secure (HTTPS).[2]

1.1 Prvn´ıverze protokolu a jej´ıvylepˇsen´ı

Prvn´ıverze protokolu byla pozdˇejioznaˇcenaHTTP/0.9. Cel´ypoˇzadavek se v t´etoverzi skl´adalpouze z jedn´eˇr´adkys jedinou moˇznoumetodou GET. Odpovˇed’ obsahovala pouze vyˇz´adan´ysoubor. Kv˚ulisv´ymlimit˚umbyla tato verze brzy rozˇs´ıˇrenao stavov´ek´odyv kaˇzd´eodpovˇediserveru. Ty umoˇznily webov´emu prohl´ıˇzeˇcidetekovat chyby pˇrizpracov´an´ıpoˇzadavk˚ua pˇrizp˚usobit jim sv´echov´an´ı.Jedn´ımz dalˇs´ıch rozˇs´ıˇren´ıbyla definice HTTP hlaviˇcky, a to jak v poˇzadavku klienta, tak v odpovˇediserveru. Ta umoˇznilapˇren´aˇsetmeta- data, a t´ımuˇcinilaprotokol flexibiln´ıma rozˇsiˇriteln´ym.Takto rozˇs´ıˇren´averze je oznaˇcov´ana jako HTTP/1.0.[2] N´asleduj´ıc´ı verze HTTP/1.1 je prvn´ı standardizovanou verz´ı protokolu. Byla publikov´anav roce 1997 jen nˇekolik mˇes´ıc˚upo verzi HTTP/1.0. Z ˇrady vylepˇsen´ıje d˚uleˇzit´ezejm´enaodstranˇen´ınedostatk˚upˇriopakovan´empouˇz´ıv´an´ı spojen´ı.D´ıkytomu m˚uˇzeb´ytuspoˇren ˇcasna jeho opˇetovn´enavazov´an´ı,pokud klient ˇz´ad´av´ıce dokument˚uod jednoho serveru. Je umoˇznˇenozaslat druh´y poˇzadavek na server pˇredpˇrijet´ım´upln´eodpovˇedina poˇzadavek pˇredchoz´ı. T´ımje sn´ıˇzenalatence komunikace. D´ıkyparametru Host v hlaviˇccepoˇzada- vku, kter´yje v t´etoverzi protokolu jiˇzpovinn´y,je moˇzn´eprovozovat nˇekolik r˚uzn´ych dom´enpod stejnou IP adresou. Pˇrid´an´ıdalˇs´ıch parametr˚udo hlaviˇcek umoˇzˇnujevyjedn´av´an´ıo vlastnostech ˇz´adan´ych dokument˚u,jako je napˇr.jazyk ˇcik´odov´an´ı.Protokol HTTP/1.1 byl d´ıkysv´esnadn´erozˇsiˇritelnosti vylepˇsen dvˇemarevizemi a je dodnes vyuˇz´ıvan´y.[2]

3 1. Vyvoj´ ˇsifrovaneho´ HTTP

1.2 HTTP/2

S rostouc´ımobjemem pˇren´aˇsen´ych dat a nar˚ustaj´ıc´ısloˇzitost´ıwebov´ych str´a- nek v´yraznˇevzrostl i poˇcetHTTP poˇzadavk˚u.Lze vyuˇz´ıtparaleln´ıspojen´ı,coˇz ovˇsempˇrin´aˇs´ıznaˇcnoureˇziia sloˇzitostkomunikace. V roce 2010 pˇredstavila spoleˇcnostGoogle alternativn´ızp˚usobpˇrenosudat mezi klientem a serverem pomoc´ıexperiment´aln´ıhoprotokolu SPDY, kter´yse zamˇeˇrujepr´avˇena tyto probl´emy. Hlavn´ırozd´ılyoproti HTTP/1.1 jsou:[2][3]

• Na rozd´ılod pˇredchoz´ıch verz´ı, kter´ebyly textov´e,je HTTP/2 bin´arn´ı. To umoˇzˇnujejeho jednoduˇs´ıa rychlejˇs´ızpracov´an´ı.

• Paraleln´ıpoˇzadavky mohou b´ytpˇren´aˇseny pˇresjedno spojen´ıbez ohledu na jejich poˇrad´ı.Zpoˇzdˇen´ıjednoho dotazu tak neblokuje ostatn´ı.Staˇc´ı tedy nav´azatpouze jedno TCP spojen´ımezi klientem a serverem.

• Doch´az´ıke kompresi hlaviˇcek, kter´ejsou ˇcastopodobn´enapˇr´ıˇcjednot- liv´ymidotazy. Odstraˇnuj´ıse tak duplicity a sniˇzujereˇzie.

• Pomoc´ımechanismu Server push je serveru umoˇznˇenoodeslat data kli- entovi dˇr´ıve, neˇzsi je vyˇz´ad´a.

• Pˇr´ıjemce m˚uˇzevyuˇz´ıt mechanismy pro ˇr´ızen´ı toku dat od odesilatele a z´aroveˇnm˚uˇzeovlivnit i nˇekter´eparametry protokolu. D´ıkytomu dok´aˇze chr´anitsv´eomezen´eprostˇredky.

Protokol vych´azej´ıc´ız SPDY byl publikov´anv roce 2015 jako HTTP/2 a nyn´ı je pouˇz´ıv´anpˇribliˇznˇe43 % webov´ych str´anek.Je tedy provozov´an paralelnˇes pˇredchoz´ımiverzemi protokolu.[4] P˚uvodnˇese pˇredpokl´adalojeho pouˇz´ıv´an´ıpouze pˇreszabezpeˇcen´espojen´ı.To nakonec nen´ıstriktnˇevyˇzadov´a- no, ale nˇekter´ewebov´eprohl´ıˇzeˇceneˇsifrovan´eHTTP/2 spojen´ıneumoˇzˇnuj´ı.[3]

1.3 HTTPS

HTTP protokol vyuˇz´ıv´apro pˇrenosdat protokol TCP/IP. Z´asadn´ı zmˇena ovˇsemnastala v roce 1994, kdy spoleˇcnostNetscape Communications rozˇs´ıˇrila protokol o ˇsifrovanou vrstvu, tedy o protokol SSL. T´ımzajistila d˚uvˇernost pˇren´aˇsen´ych dat mezi klientem a serverem a z´aroveˇnumoˇznilakontrolovat i integritu a autentiˇcnosttˇechto dat. Vznikl tak protokol HTTPS (HyperText Transfer Protocol Secure). N´aslednˇebyl protokol SSL nahrazen protokolem TLS. T´ımse odstranila ˇradap˚uvodn´ıch zranitelnost´ı.[2]

4 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

1.4 Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

I v souˇcasnostise protokoly HTTP a HTTPS neust´alevyv´ıj´ı.Webov´eprohl´ıˇze- ˇcei proxy servery tak mus´ıneust´alereagovat na tyto zmˇeny. Tato sekce po- pisuje zmˇeny ve webov´ych prohl´ıˇzec´ıch od zaˇc´atkuroku 2017, kter´ese t´ykaj´ı zejm´enaprotokolu HTTPS. N´asledujetabulka srovn´avaj´ıc´ı aktu´alnˇeˇsiroce rozˇs´ıˇren´ewebov´eprohl´ıˇzeˇcepodle implementace tˇechto rozˇs´ıˇren´ı.

1.4.1 RSA-PSS pro TLS

Radaˇ kryptografick´ych metod se spol´eh´ana pˇredpoklad, ˇzepokud veˇrejnˇe zdokumentovan´ea dobˇrezn´am´ealgoritmy byly pˇrezkoum´any velk´ympoˇctem odborn´ık˚ubez jak´ychkoli pr˚ulom˚u, je tento algoritmus bezpeˇcn´y.V minulosti se ale uk´azalo,ˇzei algoritmy kter´ebyly povaˇzov´any za bezpeˇcn´e,byly po ˇcaseprolomeny (MD5, SHA-1 a RSA 512/768 bit). Je ale ˇz´adouc´ıposkytnout tzv. prokazateln´ezabezpeˇcen´ı.To nem˚uˇzeoznaˇcitcel´ykryptografick´ysyst´em za bezpeˇcn´y,ale m˚uˇzeprohl´asit,ˇzebezpeˇcnostsyst´emu souvis´ıs bezpeˇcnost´ı z´akladn´ıhoprobl´emu.[5] V roce 1996 navrhli Mihir Bellare a Phillip Rogaway dvˇeprokazatelnˇe bezpeˇcn´asch´ematapro RSA: Probabilistic Signature Scheme (PSS) pro po- depisov´an´ıa Optimal Asymmetric Encryption Padding (OAEP) pro ˇsifrov´an´ı. Bezpeˇcnosttˇechto sch´emattedy pˇr´ımosouvis´ıs bezpeˇcnost´ıRSA a pouˇzitou hashovac´ıfunkc´ı.[5] TLS 1.3 se od TLS 1.2 liˇs´ımimo jin´ei ve zmˇenˇeRSA padding na pouˇz´ıv´an´ı RSASSA-PSS.[6] V r´amcipˇr´ıprav na podporu protokolu TLS 1.3 tak nˇekter´e webov´eprohl´ıˇzeˇces pˇredstihemimplementovaly PSS algoritmy pro podepi- sov´an´ıi pˇrivyuˇzit´ıprotokolu TLS 1.2.[7]

1.4.2 Odstranˇen´ıCBC m´oduu ECDSA TLS

CBC m´odpro TLS je problematick´ya je velmi obt´ıˇzn´eho implementovat bezpeˇcnˇe.Aˇckoliv je ˇsifrovac´ım´odCBC velmi rozˇs´ıˇren´ypro RSA, pro ECDSA (Elliptic Curve Digital Signature Algorithm) se prakticky nevyuˇz´ıv´a.Proto se nˇekter´ewebov´eprohl´ıˇzeˇcerozhodly z podporovan´ych ˇsifrov´ych sad TLS ode- brat ECDHE ECDSA WITH AES 128 CBC SHA a ECDHE ECDSA WITH- AES 256 CBC SHA.[7]

1.4.3 Odebr´an´ıTLS 1.2 ECDSA s SHA-1 a SHA-512

TLS handshake se pro verzi TLS 1.2 skl´ad´az ˇradykrok˚u.Klient iniciuj´ıc´ı handshake zas´ıl´ana server tzv. Client Hello Message. Kromˇen´ahodn´ych byt˚u,session ID (pokud jiˇzbylo spojen´ıdˇr´ıve nav´az´ano)a seznamu ˇsifrov´ych sad m˚uˇzeobsahovat i seznam poˇzadovan´ych rozˇs´ıˇren´ı.Jedn´ımz nich je i sig- ” nature algorithms“. D´ıkynˇemu m˚uˇzeklient ˇr´ıci,kter´ep´aryalgoritm˚u(pro

5 1. Vyvoj´ ˇsifrovaneho´ HTTP podpis a pro hash) mohou b´ytpouˇzity v digit´aln´ıch podpisech, tedy kter´e algoritmy u digit´aln´ıch podpis˚ubude akceptovat.[8] Pokud server podporuje nˇekterouze ˇsifrov´ych sad pˇrijat´ych od klienta, odpov´ıd´ana jeho zpr´avu.Ta obsahuje n´ahodn´eˇc´ıslo, verzi ˇsifrov´esady podle sv´epreference, session ID a seznam rozˇs´ıˇren´ı,kter´aklient vyˇzaduje a z´aroveˇn mu je m˚uˇzeserver poskytnout. Pokud server nepodporuje vˇsechna rozˇs´ıˇren´ı vyˇzadovan´aklientem, mus´ıi tak spojen´ıakceptovat. Klient se pak m˚uˇzeroz- hodnout, jestli chce ve spojen´ıpokraˇcovat.[8] Aby byla sn´ıˇzena z´avislostwebov´ych prohl´ıˇzeˇc˚una algoritmu SHA-1, a aby se webov´eprohl´ıˇzeˇcepˇripravily na jin´ezach´azen´ıs ECDSA v TLS 1.3, od- straˇnuj´ıalgoritmy ECDSA s SHA-1 a ECDSA s SHA-512 z rozˇs´ıˇren´ı signa- ture algorithms zas´ılan´ych na server. Pro protokol ECDSA byly obvykle ponech´any pouze SHA-256 a SHA-384.[7]

1.4.4 Ukonˇcen´ıd˚uvˇerypro SHA-1 certifik´aty

Hashovac´ı funkce SHA-1 byla ofici´alnˇeoznaˇcenaza zastaralou americk´ym National Institute of Standards and Technology (NIST) v roce 2011, a to pro bezpeˇcnostn´ıslabiny prok´azan´ev r˚uzn´ych anal´yz´ach a teoretick´ych ´utoc´ıch. Pˇrestobyla pouˇz´ıv´anajeˇstˇev roce 2017 pro podepisov´an´ıdokument˚u,TLS certifik´at˚ui v dalˇs´ıch aplikac´ıch, jako je napˇr´ıkladGit. V roce 2017 pˇredstavila skupina odborn´ık˚u´utok,kdy se jim podaˇrilovytvoˇritdva r˚uzn´evalidn´ıPDF dokumenty se stejn´ymSHA-1 otiskem. Jedn´ase tedy o ´utoknalezen´ımko- lize, tzn. nalezen´ıdvou r˚uzn´ych vstup˚u,pro kter´eSHA-1 vygeneruje stejn´y otisk, kter´ynen´ıpˇredemdefinovan´y.To vˇsese podaˇrilopˇribliˇznˇe100 000 kr´at rychleji neˇzpˇripouˇzit´ı´utokuhrubou silou. [9] V reakci na publikov´an´ıtohoto ´utokupˇrestalywebov´eprohl´ıˇzeˇced˚uvˇeˇrovat certifik´at˚um,kter´ebyly vytvoˇren´epr´avˇepomoc´ıSHA-1.

1.4.5 Odebr´an´ınestandardizovan´everze ChaCha20-Poly1305

ChaCha20-Poly1305 je ˇsifra typu Authenticated Encryption with Additional Data (AEAD). Sifryˇ typu AEAD jsou speci´aln´ı d´ıky kombinaci ˇsifrovac´ıho algoritmu a Message Authentication Code (MAC) v jednom celku. Sifrovac´ıˇ algoritmy lze kombinovat s MAC i samostatnˇe,ale i dva samostatnˇebezpeˇcn´e prvky lze spojit do nebezpeˇcn´ekombinace. Doˇslonapˇr´ıkladk prolomen´ınˇekte- r´ych dvojic d´ıkypouˇzit´ıstejn´ehokl´ıˇcepro ˇsifrovac´ıalgoritmus i MAC (AES- CBC s CBC-MAC).[10] V roce 2013 byla ve verzi 31 webov´ehoprohl´ıˇzeˇceChrome nasazena nov´a TLS ˇsifrov´asada ChaCha20-Poly1305. Ta byla pozdˇejistandardizov´anajako RFC 7539 a RFC 7905. Tato standardizovan´averze byla nasazena do prohl´ıˇzeˇce Chrome v roce 2016, a tak mohla b´yto rok pozdˇejiodstranˇena p˚uvodn´ıne- standardizovan´averze.[7] Dalˇs´ı z hlavn´ıch webov´ych prohl´ıˇzeˇc˚uzavedly aˇz standardizovanou verzi protokolu, a tak nemusely pˇredchoz´ıverzi odeb´ırat.

6 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

1.4.6 Cookies striktnˇepˇresHTTPS spojen´ı

Parametrem Set-Cookie v hlaviˇcceHTTP odpovˇedim˚uˇzeserver poˇz´adat klienta, aby na sv´estranˇeuloˇzildata n´asleduj´ıc´ıza t´ımto parametrem. Za daty pak m˚uˇzen´asledovat i parametr Secure jako na pˇr´ıkladun´ıˇze:

Set-Cookie: =; Secure

Takto oznaˇcen´ecookies sm´ıklient odeslat v poˇzadavku na sever pouze po- kud je spojen´ıse serverem zabezpeˇcen´e.[11]Nicm´enˇestarˇs´ıverze prohl´ıˇzeˇc˚u umoˇzˇnovaly pˇridata odebrat Secure cookies, i kdyˇzbyly pˇr´ısluˇsn´epokyny pˇrijaty pˇresnezabezpeˇcen´espojen´ı.Nov´eaktualizace uˇzale znemoˇzˇnuj´ıjak- koli ovlivˇnovat Secure cookies pˇresnezabezpeˇcen´espojen´ı.[7]

1.4.7 Podpora shody Common Name v certifik´atech Aby klient pˇredeˇsel´utok˚umtypu Man In The Middle (MITM) na HTTPS spojen´ı,mus´ıporovnat hostname serveru s hostname uveden´ymv certifik´atu, kter´yod nˇejobdrˇzel.RFC 2818 z roku 2000 ˇr´ık´a,ˇzepokud certifik´atobsahuje rozˇs´ıˇren´ı Subject Alternative Name typu DNSName, pak mus´ıb´ythodnota tohoto rozˇs´ıˇren´ıpouˇzitapro ovˇeˇren´ıidentity serveru. V opaˇcn´empˇr´ıpadˇemus´ı b´ytpouˇzitonejspecifiˇctˇejˇs´ıpole Common Name v poli Subject. Z´aroveˇnRFC dod´av´a,ˇzeaˇckoliv je ovˇeˇrov´an´ıidentity pomoc´ıpole Common Name v praxi pouˇz´ıvan´e, bylo jiˇz v roce 2000 zastaral´e a certifikaˇcn´ı autority (CA) by mˇelypouˇz´ıvat pole DNSName.[12] Webov´eprohl´ıˇzeˇcetak postupnˇeodstraˇnuj´ı podporu kontrolov´an´ıidentity serveru pomoc´ızastaral´ehoparametru Common Name a pˇrech´azej´ıpr´avˇena doporuˇcen´erozˇs´ıˇren´ı Subject Alternative Name.

1.4.8 Pˇrihlaˇsovac´ı´udaje v dotazech na subresource

Url adresa se skl´ad´az ˇradyˇc´ast´ı, z nichˇzkaˇzd´am´asv˚ujspecifick´y´uˇcel. Jedna z nepovinn´ych ˇc´ast´ıpˇredch´azej´ıc´ıdom´enov´emu jm´enu slouˇz´ıpro vloˇzen´ı pˇrihlaˇsovac´ıch ´udaj˚u.Od dom´enov´ehojm´enaje oddˇelenaznakem @“. V´ysled- ” n´aurl pak m˚uˇzevypadat napˇr´ıkladtakto: http://ima_user:[email protected]/yay.tiff

Nev´yhoda t´etometody spoˇc´ıv´av tom, ˇzedata jsou pˇren´aˇsenajako prost´y text. Z´aroveˇnm˚uˇzedoj´ıtke zmaten´ıuˇzivatele, kter´ym˚uˇzepˇrihlaˇsovac´ı´udaje povaˇzovat za dom´enov´ejm´eno.Skuteˇcn´edom´enov´ejm´enopak m˚uˇzeb´ytmas- kov´anok´odov´an´ım.Nˇekter´ewebov´eprohl´ıˇzeˇcese tak rozhodly pro zv´yˇsen´ı bezpeˇcnosti omezit zas´ıl´an´ı pˇrihlaˇsovac´ıch ´udaj˚uv r´amcidotaz˚una subre- sources, tedy pˇrinaˇc´ıt´an´ıkask´adov´ych styl˚u,skript˚unebo obr´azk˚uv r´amci webov´estr´anky. Dotazy na subresources obsahuj´ıc´ıpˇrihlaˇsovac´ı´udaje tak jsou prohl´ıˇzeˇcemblokov´any, nebo je uˇzivatel varov´anpˇredtouto skuteˇcnost´ı.[7][13]

7 1. Vyvoj´ ˇsifrovaneho´ HTTP

1.4.9 Certificate Transparency (CT) Webov´eprohl´ıˇzeˇcemohou detekovat ˇskodliv´eweby s neplatn´ymicertifik´aty. Souˇcasn´ekryptografick´emechanismy vˇsaknejsou tak dobr´ev detekci ˇskodli- v´ych web˚u,pokud jsou jejich certifik´aty vyd´any certifikaˇcn´ıautoritou (CA) chybnˇe, nebo pokud je vydala CA, kter´abyla zkompromitov´ananebo je neˇces- tn´a.V takov´ych pˇr´ıpadech webov´yprohl´ıˇzeˇcnevid´ı na certifik´atunic po- dezˇrel´eho,protoˇzeCA je z jeho pohledu d˚uvˇeryhodn´a.Jedn´ımz probl´em˚uje to, ˇzeneexistuje jednoduch´yzp˚usob,jak sledovat certifik´aty v re´aln´emˇcase. Podezˇrel´ecertifik´aty nejsou obvykle detekov´any a revokov´any nˇekolik t´ydn˚uˇci mˇes´ıc˚u.Nav´ıc se tyto probl´emy opakuj´ıˇc´ımd´alˇcastˇeji.Jako pˇr´ıkladm˚uˇzeme uv´estCA DigiNotar, kter´abyla napadena a ´utoˇcn´ıcidok´azalivyd´avat libo- voln´efaleˇsn´ecertifik´aty.[14] CT je sluˇzbapro monitorov´an´ısyst´emu certifik´at˚ua jeho auditov´an´ı.Snaˇz´ı se zm´ırnitzm´ınˇen´eprobl´emy t´ım,ˇzevyd´av´an´ıa existence certifik´at˚um˚uˇze b´ytkontrolov´anak´ymkoli, tedy vlastn´ıky dom´en,certifikaˇcn´ımi autoritami i uˇzivateli dom´eny. Klade si zejm´enan´asleduj´ıc´ıc´ıle:[15]

• Znemoˇznitnebo alespoˇnzt´ıˇzit CA vydat certifik´atpro dom´enu, aniˇzby o tom vˇedˇelvlastn´ıkdom´eny.

• Umoˇznitkomukoli odhalit, pokud byly certifik´aty vyd´any CA omylem, chybnˇenebo se zl´ym´umyslem.

• Pˇrimˇetklienty, aby odm´ıtliuznat certifik´aty, kter´ese neobjevuj´ıv CT logu. T´ımby byly CA donuceny pˇrid´avat do protokol˚uvˇsechny vydan´e certifik´aty.

SluˇzbaCT se skl´ad´az nˇekolika z´akladn´ıch ˇc´ast´ı.[15]Vz´ajemn´akomunikace mezi nimi je pak pops´anana obr´azku1.1.

• Logy certifik´at˚u Jedn´ase o jednoduch´es´ıt’ov´esluˇzby, kter´eumoˇzˇnuj´ıkomukoli zalogovat ˇretˇezeccertifik´atu.Logy lze pouze pˇrid´avat, nikoli mˇenitˇciodeb´ırat. Toho je dosaˇzeno pomoc´ıtvz. Merkleho stromu. Jeho princip z´aroveˇn umoˇzˇnujeefektivnˇeodhalit, pokud se log pokus´ı odeslat r˚uzn´ymkli- ent˚umr˚uzn´ev´ystupy, ˇcijin´enekorektn´ıchov´an´ılogu. Oˇcek´av´ase, ˇzevˇsechny CA budou zveˇrejˇnovat vˇsechny sv´enovˇevy- dan´ecertifik´aty do jednoho nebo nˇekolika log˚u, pˇr´ıpadnˇeˇzeto bude provedeno majiteli certifik´at˚u.Aby nedoch´azeloke zbyteˇcn´emu zahl- cen´ı log˚u,vyˇzaduje se, aby kaˇzd´yˇretˇezeccertifik´atumˇeljako koˇre- novou CA nˇekterouze zn´am´ych CA. Po zalogov´an´ıˇretˇezcecertifik´atuje navr´acenopodepsan´eˇcasov´eraz´ıtko (Signed Certificate Timestamp, tj. SCT). K podpisu slouˇz´ısoukrom´ykl´ıˇcCT logu. SCT je pˇr´ısliblogu, ˇze zaˇclen´ıpˇrijat´yˇretˇezeccertifik´atuv definovan´emˇcasov´em intervalu.

8 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

Obr´azek1.1: Komunikace jednotliv´ych prvk˚uCT (upraveno podle [15])

• Monitory Monitory sleduj´ılogy a kontroluj´ı,jestli se chovaj´ıkorektnˇe.Monitory mus´ıpˇrinejmenˇs´ımkontrolovat kaˇzd´ynov´yz´aznam v logu, kter´ysleduj´ı. Mohou tak´euchov´avat kopie cel´ych log˚u. • Auditoˇri Auditoˇriberou jako vstup ˇc´asteˇcn´einformace z logu a ovˇeˇruj´ı,jestli jsou v souladu s dalˇs´ımiˇc´asteˇcn´ymiinformacemi, kter´emaj´ı. • TLS klienti TLS klienti nejsou pˇr´ımo klienti CT log˚u,ale z´ısk´avaj´ı SCT jin´ymi cestami, napˇr´ıkladv parametrech certifik´atu,nebo na vyˇz´ad´an´ıod ser- veru pˇriTLS handshake. Pˇrivalidaci certifik´atu(resp. navazov´an´ıTLS spojen´ı)by pak nav´ıcmˇeliovˇeˇritpodpis SCT, ˇzeje skuteˇcnˇepodepsan´y validn´ımCT logem, a ˇzeSCT byl opravdu vytvoˇren´ypro ovˇeˇrovan´ycer- tifik´at.Pokud jsou objeveny nesrovnalosti (napˇr.timestamp SCT z bu- doucnosti), mˇelby klient spojen´ıodm´ıtnout.Jak m´aTLS klient z´ıskat veˇrejn´ykl´ıˇcCT logu, ale RFC nespecifikuje.

Webov´eprohl´ıˇzeˇcetak postupnˇezaˇcalypodporovat tuto sluˇzbu.Jednou z konkr´etnˇezaveden´ych zmˇen je napˇr´ıkladpodpora Expect-CT v hlaviˇcceser- veru. Server nastavuje tento parametr, aby upozornil webov´yprohl´ıˇzeˇc,ˇze certifik´aty serveru jsou zaps´any v CT logu a prohl´ıˇzeˇcby je mˇelkontrolo- vat i pomoc´ısluˇzebCT.[7] Po ´uspˇeˇsn´emzaveden´ıCT pak webov´yprohl´ıˇzeˇc Chrome ozn´amil,ˇzeod dubna 2018 bude vyˇzadovat zaps´an´ıvˇsech novˇevy- dan´ych veˇrejnˇed˚uvˇeryhodn´ych certifik´at˚udo CT logu.[16] T´ımjsou CA nu- ceny vkl´adatveˇsker´enovˇevydan´ecertifik´aty do CT logu, jinak je tento webov´y prohl´ıˇzeˇcoznaˇc´ıza ned˚uvˇeryhodn´e.

9 1. Vyvoj´ ˇsifrovaneho´ HTTP

1.4.10 Notifikaˇcn´ıAPI jen pˇresHTTPS Notifikaˇcn´ıAPI dovoluje webov´ymstr´ank´ama aplikac´ımzas´ılatnotifikace, kter´ese zobraz´ımimo webov´yprohl´ıˇzeˇc.Mohou tak zas´ılatinformace uˇzivateli, i kdyˇzjsou ve stavu idle nebo bˇeˇz´ına pozad´ı.[17]Webov´eprohl´ıˇzeˇce rozhoduj´ı, kdo a za jak´ych podm´ınekm˚uˇzepouˇz´ıvat API pro vytv´aˇren´ınotifikac´ı.Nˇekter´e se tak rozhodly omezit pˇr´ıstupskrz nezabezpeˇcen´eHTTP spojen´ı.[7]

1.4.11 TLS 1.3 TLS 1.3 je revize protokolu TLS, kter´abyla definov´anav RFC 8446 v srpnu 2018. Webov´eprohl´ıˇzeˇcerychle zareagovaly a brzy zaˇcalypodporovat tuto verzi protokolu. Pˇrin´avrhu TLS 1.3 byl kladen d˚urazpˇredevˇs´ımna zv´yˇsen´ı v´ykonnosti a bezpeˇcnostiprotokolu. Nˇekter´ez hlavn´ıch rozd´ıl˚ua vylepˇsen´ı oproti pˇredchoz´ıverzi TLS jsou vyjmenov´any v n´asleduj´ıc´ımseznamu:[6]

• Podporovan´ealgoritmy Seznam podporovan´ych symetrick´ych ˇsifrovac´ıch algoritm˚ubyl zkr´acen o algoritmy, kter´ejsou dnes povaˇzov´any za zastaral´e.Zachov´any byly pouze algoritmy, kter´epodporuj´ıAEAD. Tedy algoritmy, kter´ekromˇe d˚uvˇernostipˇren´aˇsen´ych dat poskytuj´ıi kontrolu integrity a autentiˇcnosti tˇechto dat. Klient tak m˚uˇzez´aroveˇnovˇeˇritp˚uvod dat a skuteˇcnost,ˇze data nebyla bˇehempˇrenosuneopr´avnˇenˇeupravena.[18]

• Zero round-trip time (0-RTT) m´od Po nav´az´an´ıTLS 1.3 spojen´ımezi klientem a serverem zas´ıl´aserver klien- tovi tzv. Pre-Shared Key (PSK). Pˇridalˇs´ımnavazov´an´ıspojen´ım˚uˇzeb´yt tento kl´ıˇcvyuˇzitk ovˇeˇren´ıidentity klienta a k zaˇsifrov´an´ıdat. PSK tak nahrazuje session ID a session tickets z pˇredchoz´ıch verz´ıTLS. Z´aroveˇn m˚uˇzeklient d´ıkyrozˇs´ıˇren´ı early data zaslat aplikaˇcn´ıdata uˇzv prvn´ı skupinˇezpr´avna server. To znaˇcnˇeurychl´ıopˇetovn´evytv´aˇren´ıspojen´ı i pˇrenosprvn´ıch dat.

• Sifrovan´yhandshakeˇ Novˇepˇridan´azpr´ava typu EncryptedExtensions n´asledujevˇzdybezpro- stˇrednˇeza zpr´avou ServerHello a je to prvn´ızpr´ava, kter´aje ˇsifrovan´a. Zpr´ava odpov´ıd´ana seznam rozˇs´ıˇren´ıvyˇzadovan´ych klientem. Vˇsechny n´asleduj´ıc´ı zpr´avyhandshake jsou tak´eˇsifrov´any. T´ım se zlepˇsiloza- bezpeˇcen´ıhandshake.

• Restrukturalizace handshake Byla zmˇenˇenastruktura stavov´ehoautomatu pro handshake oproti pˇred- choz´ımverz´ımprotokolu. Doˇslotak´ek redukci nadbyteˇcn´ych zpr´avzas´ı- lan´ych bˇehemhandshake. Tyto zmˇeny urychluj´ıTLS handshake.

10 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

• Kryptografick´avylepˇsen´ı Nov´averze pˇrineslatak´eˇradukryptografick´ych vylepˇsen´ı.Jako pˇr´ıklad m˚uˇzemeuv´estpˇrid´an´ınov´ych podpisov´ych algoritm˚ujako jsou EdDSA. Naopak byly odebr´any nˇekter´ezastaral´ealgoritmy jako statick´eRSA a Diffie-Hellman.

1.4.12 Komprese certifik´at˚u Certifik´aty ˇcastopˇredstavuj´ı znaˇcnouˇc´astpˇren´aˇsen´ych dat pˇriTLS hand- shake. Proto by bylo velmi v´yhodn´eprov´estpˇred jejich pˇrenosemkompresi, a d´ıkytomu sn´ıˇzitvelikost pˇren´aˇsen´ych dat bˇehemhandshake. TLS 1.3 za- vedlo ˇsifrov´an´ı certifik´at˚u, d´ıky kter´emu je moˇzn´eimplementovat kompresi certifik´at˚u,aniˇzby to zp˚usobovalo probl´emy na mezilehl´ych zaˇr´ızen´ıch. Radaˇ z nich se totiˇzv praxi pokouˇs´ıodchyt´avat pˇren´aˇsen´ecertifik´aty, prov´estje- jich ovˇeˇren´ı a pˇr´ıpadnˇepˇreruˇsitnavazov´an´ı spojen´ı. Pokud by vˇsakm´ısto oˇcek´avan´ehocertifik´atutato zaˇr´ızen´ıodhalila na jeho m´ıstˇepouze nesrozumi- teln´adata komprimovan´ehocertifik´atu,mohla by pˇrikroˇcitk pˇreruˇsen´ıspo- jen´ı.Protoˇzejsou vˇsakcertifik´aty v TLS 1.3 ˇsifrov´any, nem˚uˇzek takov´ym probl´em˚umdoch´azet.[19] Webov´eprohl´ıˇzeˇcetak podstupuj´ı´upravy, aby mohly dekomprimovat pˇrija- t´ecertifik´aty, a n´aslednˇes nimi zach´azetstejnˇejako u starˇs´ıch protokol˚u. Z pohledu proxy server˚uale k ˇz´adn´ymzmˇen´amnedoch´az´ı,protoˇzek dekom- primaci certifik´at˚uby mˇelodoch´azetuˇzv kryptografick´ych knihovn´ach. Po- kud ale proxy servery prov´adˇelykontrolu pˇren´aˇsen´ych certifik´at˚uv r´amciTLS handshake i pˇripouˇzit´ıTLS tunelu, bude jim to ˇsifrov´an´ımcertifik´at˚uv TLS 1.3 znemoˇznˇeno.

1.4.13 AppCache pouze pro zabezpeˇcen´eHTTP AppCache je uloˇziˇstˇeposkytovan´eHTML 5, kter´eumoˇzˇnujewebov´ymapli- kac´ımfungovat i bez pˇripojen´ık Internetu. Do AppCache si aplikace m˚uˇze ukl´adatsoubory, kter´ejsou specifikov´any v souboru manifest, kter´yje uloˇzen´y na webov´emserveru a server ho zas´ıl´aklientovi. Takov´afunkcionalita ale znaˇcnˇerozˇsiˇrujei moˇznosti´utoˇcn´ık˚u.Do AppCache m˚uˇzeb´ytnapˇr´ıkladuloˇzen soubor s ´utokem typu Cross-Site Scripting (XSS), kter´yse d´ıkypodvrˇzen´emu manifestu uchov´ai pˇridalˇs´ıch naˇcten´ıch webov´estr´anky. Proto webov´eprohl´ı- ˇzeˇceomezuj´ıAppCache pouze pro pˇripojen´ıpˇreszabezpeˇcen´eHTTP spojen´ı. Postupnˇetak´epˇrich´azej´ıs proklamacemi, ˇzev n´asleduj´ıc´ıch verz´ıch bude pod- pora AppCache zcela odstranˇena.[20]

1.4.14 Uprava´ hodnot User-Agent RFC 7231[21] ˇr´ık´a,ˇzeatribut User-Agent HTTP hlaviˇckyobsahuj´ıc´ıinfor- mace o syst´emu klienta by nemˇel obsahovat ˇz´adn´ezbyteˇcn´edetaily. Ty by

11 1. Vyvoj´ ˇsifrovaneho´ HTTP mohly poslouˇzit´utoˇcn´ık˚umpˇrihled´an´ıkonkr´etn´ıch slabin v syst´emu klienta a z´aroveˇnzjednoduˇsitidentifikaci konkr´etn´ıhoklienta. Webov´eprohl´ıˇzeˇcetak v souladu se zm´ınˇen´ymRFC v nov´ych verz´ıch odstraˇnuj´ı detaily, jako je napˇr´ıkladˇc´ıslobuildu operaˇcn´ıhosyst´emu.[7]

1.4.15 Token Binding Servery generuj´ı tokeny (napˇr.HTTP cookies), kter´epak slouˇz´ı aplikac´ım k autentizaci pˇridalˇs´ıch pˇr´ıstupech k chr´anˇen´ymprostˇredk˚um.Toho mohou zneuˇz´ıvat ´utoˇcn´ıcit´ım,ˇzez´ıskaj´ıtyto tokeny z komunikace nebo ze zaˇr´ızen´ı a zas´ılaj´ıje na server, ˇc´ımˇzse vyd´avaj´ıza autentizovan´euˇzivatele (tzv. replay ´utok).Protokol Token Binding se snaˇz´ı zabr´anittakov´ym´utok˚umpomoc´ı kryptografick´ehosv´az´an´ıaplikaˇcn´ıch token˚us TLS vrstvou. Pˇrizasl´an´ıto- kenu z jin´ehozabezpeˇcen´ehospojen´ı, neˇzpro kter´ebyl token vytvoˇren,je tato skuteˇcnostodhalena. Pro zjednoduˇsen´ılze na protokol nahl´ıˇzetz pohledu kaˇzd´eze z´uˇcastnˇen´ych stran:[22]

1. Token Binding z pohledu klienta Klient vygeneruje dvojici soukrom´ehoa veˇrejn´ehokl´ıˇcepro kaˇzd´yser- ver, ide´alnˇes pouˇzit´ım bezpeˇcn´ehoHW modulu jako je napˇr.Trus- ted Platform Module (TPM). Serveru je z´aroveˇnprok´az´ano,ˇzeklient je vlastn´ıkem odpov´ıdaj´ıc´ıhosoukrom´ehokl´ıˇce.Jako d˚ukazslouˇz´ıTo- ken Binding Message, kter´aobsahuje Exported Keying Material (EKM) z akut´alnˇepouˇz´ıvan´ehoTLS spojen´ıpodepsan´esoukrom´ymkl´ıˇcemkli- enta. EKM hodnota je odvozen´aod hodnoty TLS master secret, kter´a je vyuˇz´ıv´anak odvozen´ıkl´ıˇc˚uTLS spojen´ı.EKM tak oznaˇcujenav´azan´e TLS spojen´ı.T´ımse zabraˇnujereplay ´utok˚um,protoˇzehodnota Token Binding Message je z´avisl´ana TLS spojen´ı,ale z´aroveˇnje nutn´e,aby aplikace synchronizovala generov´an´ıa ovˇeˇrov´an´ıToken Binding Message s TLS handshake. Token Binding Message slouˇz´ık prok´az´an´ıvlastnictv´ıpriv´atn´ıhokl´ıˇce klientem. Mus´ı b´ytposl´ana,pokud server s klientem ´uspˇeˇsnˇedojed- nali uˇzit´ıprotokolu Token Binding bˇehemTLS handshake, a mus´ıb´yt posl´anav prvn´ızpr´avˇeklienta, kter´aobsahuje aplikaˇcn´ıdata. Pˇr´ıpadnˇe m˚uˇzeb´yti v n´asleduj´ıc´ıch zpr´av´ach, aby bylo prok´az´anovlastnictv´ı i dalˇs´ıch priv´atn´ıch kl´ıˇc˚u.Zpr´ava obsahuje s´eriiToken Binding struktur, z nichˇzkaˇzd´aobsahuje Token Binding identifik´ator(ID), typ Token Bin- ding a soukrom´ymkl´ıˇcemklienta podepsan´ezˇretˇezen´ıEKM, parametr˚u kl´ıˇcea Token Binding typu. Token Binding ID jsou struktury obsahuj´ıc´ıidentifik´atorvyjednan´ych parametr˚uveˇrejn´ehokl´ıˇce,veˇrejn´ykl´ıˇcklienta a jeho d´elku.Maj´ıdlou- hou ˇzivotnost. To znamen´a,ˇzese pouˇz´ıvaj´ıpro v´ıceTLS relac´ıa spojen´ı. Tomu by mˇelyb´ytpˇrizp˚usobeny i parametry kl´ıˇce.Token Binding ID

12 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

Obr´azek1.2: Komunikace pˇripouˇzit´ıprotokolu Token Binding

tak´enikdy nesm´ıb´ytpˇren´aˇsen´epˇresnezabezpeˇcen´espojen´ıa klient je m˚uˇzekdykoli zneplatnit.

2. Token Binding z pohledu serveru Po pˇrijet´ıToken Binding Message od klienta mus´ıserver ovˇeˇrit,jestli pˇrijat´yveˇrejn´ykl´ıˇcklienta splˇnujesjednan´eparametry. Z´aroveˇnser- ver ovˇeˇr´ıpodpis v t´etozpr´avˇe.V pˇr´ıpadˇenesrovnalost´ımus´ıserver To- ken Binding odm´ıtnout.Pokud kontrola probˇehne´uspˇeˇsnˇe,server pˇred´a Token Binding ID aplikaci na serveru a ta ho m˚uˇzepouˇz´ıt pro vy- tvoˇren´ıa ovˇeˇrov´an´ısecurity tokenu. Sch´emakomunikace je zn´azornˇeno na obr´azku1.2. TLS vrstvu lze sv´azatse security tokenem napˇr´ıkladvloˇzen´ımToken Binding ID nebo jeho hashe do security tokenu, pˇr´ıpadnˇeukl´ad´an´ım token˚ua k nim pˇr´ısluˇsej´ıc´ım Token Binding ID. Zp˚usobsv´az´an´ı vol´ı aplikace. Po pˇrijet´ısecurity tokenu od klienta server kontroluje Token Binding ID z tokenu a z TLS spojen´ıs klientem. Pokud si neodpov´ıdaj´ı, mus´ıserver token odm´ıtnout.Pokud je pˇrijatklasick´ya sv´azan´ytoken, z´aleˇz´ı na politik´ach aplikace, jestli bude d´alzpracov´av´an. Aby mohl ´utoˇcn´ık´uspˇeˇsnˇez´ıskata zneuˇz´ıt(replay attack) sv´azan´ytoken, musel by pouˇz´ıtsoukrom´ykl´ıˇcklienta, kter´ysi klient chr´an´ı.

Jako pˇr´ıkladvyuˇzit´ıToken Binding m˚uˇzemeuv´estprotokol HTTPS. Pot´e co klient se serverem vyjednaj´ıpouˇzit´ıprotokolu Token Binding a nav´aˇz´ıTLS spojen´ı,pos´ıl´aklient prvn´ıHTTP poˇzadavek, ve kter´emmus´ıuv´esthlaviˇcku

13 1. Vyvoj´ ˇsifrovaneho´ HTTP

Sec-Token-Binding = EncodedTokenBindingMessage obsahuj´ıc´ıToken Binding Message zak´odovanou pomoc´ıBase64url. Server po ovˇeˇren´ıToken Binding Message sv´aˇzeToken Binding ID s cookies, kter´eslouˇz´ı jako security token. K resetov´an´ıtokenu dojde, pokud klient smaˇzecookies z webov´eho prohl´ıˇzeˇce.[23] Aˇckoli Token Binding zlepˇsujeochranu uˇzivatel˚u,ˇradawebov´ych prohl´ıˇze- ˇc˚uho nikdy nezaˇcalapodporovat a jin´eho postupnˇeodstraˇnuj´ı. D˚uvodem jsou vysok´en´akladyna zaveden´ıa ´udrˇzbuv porovn´an´ıse z´ıskan´ymipˇr´ınosy. Jelikoˇzse tato metoda nikdy ˇsiroce nerozˇs´ıˇrila,objevuj´ıse i probl´emy s kompa- tibilitou. Nav´ıcexistuj´ıalternativn´ızp˚usoby k dosaˇzen´ıpodobn´ych v´ysledk˚u, jako je pˇr´ıznak HttpOnly u cookies, ˇcivyuˇz´ıv´an´ıklientsk´ych certifik´at˚u.[24]

1.4.16 Zneplatnˇen´ıcertifik´at˚uSymantec V lednu 2017 bylo na veˇrejn´emf´orumozilla.dev.security.policy upozornˇeno na nˇekolik podezˇrel´ych certifik´at˚uvydan´ych infrastrukturou veˇrejn´ych kl´ıˇc˚u (PKI) spoleˇcnostiSymantec. Symantec provozuje ˇraduCA jako GeoTrust, Ra- pidSSL a dalˇs´ı.Tyto CA vyd´avaly ˇraducertifik´at˚u,kter´enesplˇnovaly n´aleˇzi- tosti pr˚umyslov´ych CA. Bˇehemn´asledn´ehovyˇsetˇrov´an´ıbylo odhaleno, ˇzeSy- mantec svˇeˇrild˚uvˇerunˇekolika organizac´ım,aby vyd´avaly certifik´aty, aniˇzby zajistil n´aleˇzit´ya nezbytn´ydohled nad jejich poˇc´ın´an´ım.Nav´ıcsi spoleˇcnost byla urˇcitoudobu vˇedomabezpeˇcnostn´ıch nedostatk˚uv tˇechto organizac´ıch a nepodnikla ˇz´adn´aopatˇren´ı.Nejednalo se o prvn´ıbezpeˇcnostn´ıincident t´eto spoleˇcnosti.Naopak se jednalo o dalˇs´ı z ˇradypochyben´ı, a tak se webov´y prohl´ıˇzeˇcChrome rozhodl ukonˇcitd˚uvˇeruv PKI spoleˇcnostiSymantec a po- stupnˇei v certifik´aty, kter´evydala. N´aslednˇese k tomuto postupu pˇripojily i dalˇs´ıwebov´eprohl´ıˇzeˇce.[25]

1.4.17 Odebr´an´ıHTTP Public Key Pinning HTTP Public Key Pinning (HPKP) mimo jin´erozˇsiˇrujeHTTP hlaviˇckuod- povˇediserveru o novou poloˇzku Public-Key-Pins. Ta umoˇzˇnujeinformovat webov´eprohl´ıˇzeˇceo tom, jak´eveˇrejn´ekl´ıˇceby mˇelobsahovat ˇretˇezeccer- tifik´atupro urˇcit´yhostname pˇridalˇs´ıch TLS spojen´ıch. Povinn´yparametr max-age ˇr´ık´a,kolik sekund po pˇrijet´ı hlaviˇckyod serveru je tento z´aznam platn´y.Parametr pin pak specifikuje hash Subject Public Key Information (SPKI) a algoritmus, kter´ybyl pro v´ypoˇcethashe pouˇzit.Pro pˇr´ıpad,kdy by sever ztratil kontrolu nad sv´ympriv´atn´ımkl´ıˇcem,je nutn´ezas´ılatalespoˇn jeden dalˇs´ız´aloˇzn´ı,kter´ynen´ıserverem aktu´alnˇepouˇz´ıvan´y.D´ıkynˇemu lze ob- novit, vytvoˇrita verifikovat nov´espojen´ıpˇriztr´atˇepriv´atn´ıhokl´ıˇce.Nepovinn´y parametr includeSubDomains znamen´a,ˇzekontrola kl´ıˇce m´ab´ytprovedena i u vˇsech subdom´endan´edom´eny. Dalˇs´ınepovinn´yparametr report-uri de- finuje URI, kam maj´ıb´ythl´aˇseny chyby pˇrikontrole kl´ıˇce.Hlaviˇckaodeslan´a serverem pak m˚uˇzevypadat napˇr´ıklad takto:[26]

14 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch

Public-Key-Pins: pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="; report-uri="http://example.com/pkp-report"; max-age=2592000; includeSubDomains

Pokud je HPKP spr´avnˇenastaven´e,umoˇzˇnujesniˇzovat riziko ´utok˚utypu MITM i dalˇs´ıch, kter´ese zamˇeˇruj´ı na prolomen´ı autentizace pomoc´ı certi- fik´at˚u.Pˇrichybn´emnastaven´ıHPKP ale m˚uˇzedoj´ıtk znepˇr´ıstupnˇen´ıurˇcit´ych dom´en.HPKP je ˇcastopouˇz´ıv´anospoleˇcnˇes HTTP Strict Transport Security (HSTS), kter´eumoˇzˇnujeozn´amitwebov´emu prohl´ıˇzeˇci,ˇzena urˇcit´yweb m´a vˇzdypˇristupovat pomoc´ıprotokolu HTTPS. Spoleˇcn´epouˇz´ıv´an´ıobou proto- kol˚uale nen´ıpodm´ınkou.[26] HPKP je mechanismus typu trust-on-first-use. To znamen´a,ˇzepˇriprvn´ım pˇripojen´ına server nem´aklient informace potˇrebn´ek proveden´ıkontroly po- moc´ı HPKP a z´ısk´av´aje pr´avˇez prvn´ıho pˇripojen´ı. Pokud tak je uˇzpˇri prvn´ımpˇripojen´ına server pouˇzit´utokMITM, m˚uˇzesi klient spojit dom´enu s podvrˇzen´ymkl´ıˇcema po ukonˇcen´ı´utokuodm´ıtatprav´ycertifik´atserveru. Zm´ırnit tento probl´emm˚uˇzeseznam dom´ena jejich kl´ıˇc˚upˇredinstalovan´y v prohl´ıˇzeˇci. Ten se tak nemus´ıspol´ehatna prvn´ıpˇripojen´ık serveru. Do to- hoto seznamu vˇsaknelze jednoduˇsezapsat libovolnou dom´enu. Jsou zde hlavnˇe ˇcastonavˇstˇevovan´eweby.[26] Jednoduch´ezanesen´ıchyby do konfigurace a souvisej´ıc´ıriziko znepˇr´ıstu- pnˇen´ıdom´eny spolu s moˇznost´ıpˇripnut´ıpodvodn´ehokl´ıˇcek dom´enˇezp˚usobilo, ˇzenˇekter´ewebov´eprohl´ıˇzeˇce odstraˇnuj´ıtuto funkcionalitu. Jedn´ımz dalˇs´ıch d˚uvod˚upro jej´ıodstranˇen´ıje i n´ızk´erozˇs´ıˇren´ıt´eto funkcionality v praxi.[7]

1.4.18 Web Packaging Radaˇ klient˚uby ocenila moˇznostpˇristupovat k webov´ymstr´ank´ami pokud jsou offline nebo pokud nemaj´ımoˇznostpˇristoupit ke zdrojov´emu webov´emu serveru. Bez pˇripojen´ıke zdrojov´emu serveru ale vznik´aprobl´em s ovˇeˇren´ım pravosti pˇrijat´ehoobsahu. SpoleˇcnostGoogle pˇredstavila technologii Web Pac- kaging. Ta umoˇzˇnujesv´azatzdroje webov´estr´ankya vytvoˇritz nich jedin´y soubor. Tento soubor lze kryptograficky podepsat a n´aslednˇedistribuovat kli- ent˚umdokonce i bez podpory zabezpeˇcen´ehoHTTP spojen´ı.D´ıkypodpisu lze ovˇeˇritjejich p˚uvod a pravost. Distribuci lze prov´adˇetz libovoln´ych webov´ych server˚u,cachovac´ıch server˚ui dalˇs´ıch zaˇr´ızen´ı, jako jsou napˇr´ıklad mobiln´ı telefony.[27]

1.4.19 Hodnota User-Agent v hlaviˇcce CONNECT Pˇrivytv´aˇren´ızabezpeˇcen´ehoHTTP spojen´ıs pouˇzit´ım proxy serveru zas´ıl´a klient na proxy poˇzadavek CONNECT. Tento poˇzadavek m´avlastn´ı parame- try v hlaviˇcce.Webov´eprohl´ıˇzeˇcepˇrijmouod klienta CONNECT poˇzadavek,

15 1. Vyvoj´ ˇsifrovaneho´ HTTP

Obr´azek1.3: Uk´azka probl´emu se sm´ıˇsen´ymobsahem

kter´yn´aslednˇepˇrepos´ılaj´ına proxy server. Nˇekter´ewebov´eprohl´ıˇzeˇcepara- metr User-Agent pouze pˇrepos´ılaj´ı.Jin´evˇsakod t´etopraxe odstupuj´ıa pa- rametr nahrazuj´ıvlastn´ıdefaultn´ıhodnotou.[7]

1.4.20 Sm´ıˇsen´yobsah Po naˇcten´ısouboru webov´estr´anky pˇreszabezpeˇcen´eHTTP spojen´ıjsou kli- entovi za norm´aln´ıch okolnost´ızaruˇceny tyto skuteˇcnosti:[28]

• Komunikace klienta se serverem je ˇsifrov´ana,a tak nem˚uˇzeb´ytjednoduˇse odposlechnut jej´ıobsah zaˇr´ızen´ımi,pˇreskter´eproch´azela.D˚uvˇernostdat tedy byla zajiˇstˇena.

• Klient si mohl ovˇeˇritidentitu zdrojov´ehoserveru. Byla mu tedy umoˇz- nˇenaautentizace zdroje.

• Pˇren´aˇsen´adata nebylo moˇzn´ejednoduˇsemodifikovat bˇehempˇrenosu, aniˇzby to klient odhalil. Byla tedy zajiˇstˇenaintegrita dat.

S´ılatˇechto tvrzen´ım˚uˇzeb´ytsilnˇeoslabena, pokud jsou nˇekter´ez dalˇs´ıch souˇc´ast´ıwebov´estr´anky(skripty, obr´azkyatd.) naˇc´ıt´any pˇresnezabezpeˇcen´e HTTP spojen´ı. Pˇrenostakov´ych ˇc´ast´ı totiˇznen´ı chr´anˇen´ypˇredpˇr´ıpadn´ym ´utokem typu MITM. Nelze tak zaruˇcitˇz´adn´ez pˇredchoz´ıch tvrzen´ı. Tento probl´emse u webov´ych str´anekvyskytuje pomˇernˇeˇcasto.Na obr´azku1.3 je zobrazen´yv´ypisz konzole prohl´ıˇzeˇceFirefox. Ve v´ypisuje ˇcervenˇezv´yraznˇen´y obsah, kter´ynebyl naˇcten´ykv˚ulipˇr´ıstupupˇresnezabezpeˇcen´espojen´ı, jelikoˇz prvotn´ıpoˇzadavek byl zpracov´anpˇreszabezpeˇcen´espojen´ı.[28] Jak vypl´yv´az obr´azku1.3, nˇekter´ewebov´eprohl´ıˇzeˇcemohou v pˇr´ıpadˇe sm´ıˇsen´ehoobsahu blokovat nezabezpeˇcen´ezdroje. Nˇekter´edalˇs´ıwebov´eprohl´ı- ˇzeˇceuˇzale automaticky upravuj´ıurl adresu tak, aby se ke zdroji pˇristupovalo

16 1.4. Aktu´aln´ıv´yvoj ve webov´ych prohl´ıˇzeˇc´ıch pˇreszabezpeˇcen´espojen´ı.K tomu staˇc´ınahradit http://“ na zaˇc´atkuurl za ” https://“. Zat´ımje tato funkce pouˇzitajen pro vybran´etypy objekt˚u,jako ” je audio a video obsah.[7]

1.4.21 Parametr SameSite u cookies Cookies slouˇz´ıwebov´emu serveru k uloˇzen´ıdat u klienta. Obvykle se ukl´adaj´ı tokeny nebo stavy webov´ych str´anek.Server je m˚uˇzenastavit v hlaviˇcceHTTP odpovˇedi.Kaˇzd´apoloˇzkacookie je p´arkl´ıˇca hodnota s ˇradoudalˇs´ıch atribut˚u. Ty urˇcuj´ı,kdy a kde se cookie pouˇzije,jak´aje doba jej´ıplatnosti, jestli sm´ı b´ytzasl´anapouze pˇreszabezpeˇcen´espojen´ı,atd.[29] Pˇridotazu na webov´yserver zas´ıl´aklient cookies pro r˚uzn´edom´eny. Podle toho lze cookies rozdˇelitna ty, kter´eodpov´ıdaj´ı dom´enˇeaktu´aln´ı webov´e str´anky(cookies prvn´ıch stran), a ty, kter´et´etodom´enˇeneodpov´ıdaj´ı(coo- kies tˇret´ıch stran). Parametr SameSite umoˇzˇnujeserveru urˇcit, jak m´aklient s r˚uzn´ymidruhy cookies zach´azet.Moˇzn´ehodnoty pro tento parametr jsou:[29]

• Strict Pro toto nastaven´ıse cookies zaˇsloupouze pokud jsou v dan´emkontextu cookies prvn´ıch stran. Tedy pokud dom´enacookies odpov´ıd´aaktu´aln´ı webov´estr´ance(dom´enˇev URL liˇstˇeprohl´ıˇzeˇce).Typ Strict se vyuˇz´ıv´a pro cookies souvisej´ıc´ı s ˇcinnostmi,kter´euˇzivatel na webov´estr´ance vykon´av´a.

• Lax Toto nastaven´ıumoˇzˇnujeodeslat cookies p˚uvodn´ıwebov´estr´anky, po- kud na ni uˇzivatel pˇristupujepomoc´ıodkazu vyskytuj´ıc´ıhose na jin´e webov´estr´ance.Cookies se ale nezaˇslou,pokud je odkaz na p˚uvodn´ı str´ankupouˇzitpouze pro staˇzen´ıurˇcit´ehoobsahu do aktu´aln´ıwebov´e str´anky. Hodnota Lax se vyuˇz´ıv´azejm´enapro cookies ovlivˇnuj´ıc´ızobra- zen´ıwebov´estr´anky.

• Atribut nen´ınastaven (ekvivalent hodnoty None) Tato moˇznostbyla pˇredzaveden´ımatributu SameSite implicitn´ıa zna- men´a,ˇzecookies budou posl´any z libovoln´ehokontextu.

Pokud nen´ıparametr SameSite specifikovan´y,jsou cookies n´achyln´ena ´utokytypu cross-site request forgery (CSRF). Nˇekter´ewebov´eprohl´ıˇzeˇcese proto rozhodly v takov´empˇr´ıpadˇedefaultnˇenastavovat atribut SameSite na hodnotu Lax. T´ımdok´aˇz´ıchr´anituˇzivatele pˇrednˇekter´ymitypy ´utok˚utypu CSRF. Z´aroveˇnwebov´eprohl´ıˇzeˇcemˇen´ıpˇr´ıstupke cookies s atributem Same- Site=None, pokud u nich nen´ıspecifikov´anatribut Secure (cookies sm´ıb´yt pˇren´aˇseny pouze pˇreszabezpeˇcen´espojen´ı). Takov´ecookies jsou webov´ym prohl´ıˇzeˇcemodm´ıtnuty. K tomu je pˇristoupeno, jelikoˇzcookies tˇret´ıch stran

17 1. Vyvoj´ ˇsifrovaneho´ HTTP

100 93.12 80

60

40 Využití [%] 20 5.68 1.11 0.09 0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Verze protokolu TLS

Obr´azek1.4: TLS verze protokolu a jejich vyuˇz´ıv´an´ıve webov´emprohl´ıˇzeˇci Firefox beta 62 (srpen aˇzˇr´ıjen2018)

b´yvaj´ızneuˇz´ıv´any ´utoˇcn´ıkyke sledov´an´ıchov´an´ıuˇzivatel˚ua mohou obsahovat citliv´adata t´ykaj´ıc´ıse identity uˇzivatele. D´ıkyodm´ıtnut´ıtˇechto cookies jsou uˇzivatel´echr´anˇenipˇred´utokyna identifikaˇcn´ıdata uˇzivatel˚ua z´aroveˇntak lze pˇrimˇetsubjekty k podpoˇrezabezpeˇcen´ehoHTTP spojen´ı.[7]

1.4.22 TLS 1.0 a TLS 1.1 Protokol TLS 1.0 byl vydan´yv roce 1999, tedy jiˇzpˇredv´ıceneˇzdvaceti lety, TLS 1.1 pak o sedm let pozdˇeji.[30]A aˇckoliv nejsou zn´am´ekonkr´etn´ıkri- tick´eprobl´emy v tˇechto protokolech, kter´eby vyˇzadovaly okamˇzitoureakci, jsou dnes jiˇzpouˇz´ıv´anajin´avhodnˇejˇs´ıa robustnˇejˇs´ıˇreˇsen´ı.Nav´ıctyto verze nepodporuj´ıdneˇsn´ımodern´ıkryptografick´ealgoritmy, ale naopak se spol´ehaj´ı na algoritmy SHA-1 ˇciMD5. TLS 1.2 ˇreˇs´ıslabiny pˇredchoz´ıch verz´ıa nav´ıc podporuje i nov´eprotokoly jako je HTTP/2. Jak je moˇzn´evidˇetna grafu 1.4, TLS 1.2 se spoleˇcnˇes novˇejˇs´ıverz´ıTLS 1.3 st´avaj´ımajoritn´ımiproto- koly pro zabezpeˇcen´aspojen´ı.Z tˇechto d˚uvod˚uwebov´eprohl´ıˇzeˇceupozorˇnuj´ı sv´euˇzivatele na zastaralost protokol˚uTLS 1.0 a 1.1 a n´aslednˇepˇristupuj´ı k postupn´emu ukonˇcov´an´ıjejich podpory.[31]

1.4.23 Opatˇren´ıproti TLS downgrade ´utok˚um BˇehemTLS handshake si klient se serverem vymˇeˇnuj´ıpodporovan´eˇsifrov´e sady. N´aslednˇevyb´ıraj´ıˇsifrovou sadu a parametry TLS spojen´ı, kter´eoba podporuj´ı,a kter´ejsou co moˇzn´anejodolnˇejˇs´ıproti ´utok˚um.Downgrade ´utok na TLS se snaˇz´ıoklamat klienta se serverem, aby pouˇzilipro vz´ajemnouko- munikaci starˇs´ıverze protokol˚u,nebo parametry TLS spojen´ı,kter´enejsou pˇr´ıliˇsbezpeˇcn´e.Tyto protokoly mohou b´ytpodporov´any kv˚ulizpˇetn´ekompa- tibilitˇese starˇs´ımizaˇr´ızen´ımi.D´ıkytomu m˚uˇze´utoˇcn´ıkvyuˇz´ıtzn´am´echyby v pouˇzit´ych protokolech, kter´ese vyskytly v TLS komunikaci pr´avˇed´ıky Downgrade ´utoku.K proveden´ı ´utokumus´ı ´utoˇcn´ık zachytit a upravit ko- munikaci mezi klientem a serverem.[32]

18 1.5. Souhrn

Protokol TLS 1.3 se snaˇz´ızabr´anittomuto druhu ´utoku.Podle RFC m´a b´ytv´ysledekvyjedn´av´an´ıparametr˚ustejn´yv pˇr´ıpadˇeDowngrade ´utoku,jako kdyby k ´utokunedoˇslo. K ovˇeˇren´ı,ˇzevyjednan´eparametry nebyly zmˇenˇeny bˇehempˇrenosu,je pouˇzitMessage Authentication Code (MAC). Ten se pouˇzije na konci handshake pˇresvˇsechny pˇredchoz´ızpr´avy. Pokud nav´ıcserver zjist´ı, ˇzejedin´apouˇziteln´averze protokolu je TLS 1.2 nebo starˇs´ı,mus´ıve zpr´avˇe ServerHello nastavit 8 byt˚un´ahodn´ehoˇc´ıslana pˇreddefinovanou hodnotu. Pokud klient s verz´ıTLS 1.3 pˇrikontrole tohoto ˇc´ıslanajde tuto hodnotu, mus´ı spojen´ıukonˇcit.Pokud by se ´utoˇcn´ıkpokusil zmˇenithodnotu n´ahodn´ehoˇc´ısla, doˇsloby k chybˇepˇriprocesu v´ymˇeny kl´ıˇc˚u,bˇehemkter´ehoje n´ahodn´ahodnota pouˇz´ıv´ana.[32] I kdyˇzjsou opatˇren´ıproti Downgrade ´utokuv TLS 1.3 zpˇetnˇekompati- biln´ı,zp˚usobuj´ıu nˇekter´ych proxy server˚upˇreruˇsen´ıspojen´ı.Z tohoto d˚uvodu pˇristoupilynˇekter´ewebov´eprohl´ıˇzeˇcena doˇcasn´evypnut´ınov´ych rozˇs´ıˇren´ıpro kontrolu TLS Downgrade u spojen´ı,kter´amaj´ıˇretˇezeccertifik´atus nezn´am´ym koˇrenov´ymcertifik´atem.Nyn´ıproklamuj´ızaveden´ıtˇechto rozˇs´ıˇren´ıdo praxe.[7]

1.4.24 Stahov´an´ıze zabezpeˇcen´ehokontextu Webov´eprohl´ıˇzeˇcezam´yˇslej´ıblokovat stahov´an´ısoubor˚upˇresnezabezpeˇcen´e spojen´ı, pokud bylo iniciov´anoze zabezpeˇcen´ehokontextu. Nejprve budou uˇzivatel´evarov´ania pozdˇejise pˇrikroˇc´ı k blokov´an´ı. D´ıky tomuto opatˇren´ı bude sn´ıˇzenoriziko pro uˇzivatele, protoˇzepo staˇzen´ım˚uˇzeˇskodliv´ysoubor obej´ıtochrany webov´ehoprohl´ıˇzeˇce.[7]

1.4.25 Zastar´an´ınezabezpeˇcen´ehoHTTP Nejen spoleˇcnostivyv´ıjej´ıc´ıwebov´eprohl´ıˇzeˇcese shoduj´ı,ˇzev budoucnu bude nutn´epouˇz´ıvat ˇsifrov´an´ı pro veˇsker´adata pˇren´aˇsen´apˇresInternet. V pˇr´ı- padˇewebov´ych str´anekto znamen´apouˇz´ıv´an´ızabezpeˇcen´ych HTTP spojen´ı, tedy HTTPS. Nˇekter´ewebov´eprohl´ıˇzeˇcejiˇzzveˇrejnilysv˚ujz´amˇerpostupnˇe ukonˇcitpodporu nezabezpeˇcen´ehoHTTP spojen´ı. Snaˇz´ı se tedy definovat, kter´enov´efunkcionality jiˇznebudou podporov´any pro tato spojen´ı.Z´aroveˇnse webov´eprohl´ıˇzeˇcesnaˇz´ıstanovit ˇcasov´yharmonogram postupn´ehoomezov´an´ı dnes podporovan´ych funkcionalit pro nezabezpeˇcen´aspojen´ı,kter´ebude nutn´e v budoucnu odebrat ˇciomezit s ohledem na bezpeˇcnostuˇzivatel˚u.Z´aroveˇnje vˇsakpˇripouˇstˇeno,ˇzek ´upln´emu odstranˇen´ıpodpory nezabezpeˇcen´ehoHTTP spojen´ız webov´ych prohl´ıˇzeˇc˚uv brzk´edobˇenedojde.[33]

1.5 Souhrn

V tabulce 1.1 m˚uˇzemeporovn´an´ımjednotliv´ych webov´ych prohl´ıˇzeˇc˚uzjistit, ˇzene vˇsechny zmˇeny byly provedeny vˇsemidnes ˇsiroce rozˇs´ıˇren´ymiwebov´ymi prohl´ıˇzeˇci.Pˇr´ıˇcinoutˇechto rozd´ıl˚um˚uˇzeb´ytnapˇr´ıklad odliˇsn´auˇzivatelsk´a

19 1. Vyvoj´ ˇsifrovaneho´ HTTP

Tabulka 1.1: Srovn´an´ı v´yvoje ˇsifrovan´eho HTTP v aktu´aln´ıch webov´ych prohl´ıˇzeˇc´ıch bˇehemposledn´ıch tˇr´ılet Feature Google Chrome1 Firefox2 Safari3 verze datum verze datum verze datum 1.4.1 56 25.1.2017 47 7.7.2016 - - 1.4.2 56 25.1.2017 - - - - 1.4.3 56 25.1.2017 53 19.4.2017 - - 4 1.4.4 56 25.1.2017 43 platn´eod 1.1.2017 13.0.3 30.10.2019 1.4.5 58 19.4.2017 - - - - 1.4.6 58 19.4.2017 52 7.3.2017 - - 1.4.7 58 19.4.2017 - - 13.0.3 30.10.2019 1.4.8 59 5.6.2017 - pouze varov´an´ı - pouze varov´an´ı 1.4.9 61 5.9.2017 - pr˚ubˇeˇznˇe[34] 12.1.1 24.9.2018 1.4.10 62 17.10.2017 - - - - 1.4.11 65 6.3.2018 61 26.6.2018 12.2 25.3.2019 1.4.12 69 4.9.2018 - - - - 1.4.13 70 16.10.2018 60 9.5.2018 - -5 1.4.14 70 16.10.2018 696 3.9.2019 - - 1.4.15 70 16.10.2018 - - - - 1.4.16 70 16.10.2018 63 23.10.2018 - 1.8.20187 1.4.17 72 29.1.2019 72 7.1.2020 - 1.8.2018 1.4.18 73 12.3.2019 - - - - 1.4.19 73 12.3.2019 - - - - 1.4.20 80 4.2.2020 - pˇripravuje se - pˇripravuje se 1.4.21 80 4.2.2020 - pˇripravuje se - - 1.4.22 81 13.2.2020 74 10.3.2020 - kvˇeten2020 1.4.23 81 13.2.2020 72 7.1.2020 12.2 25.3.2019 1.4.24 82 duben 2020 - - - - 1.4.25 - - - 30.4.2015 - -

z´akladnajednotliv´ych webov´ych prohl´ıˇzeˇc˚us odliˇsn´ymipreferencemi ˇcirozd´ıl- n´apolitika jednotliv´ych spoleˇcnost´ı.Nˇekter´epreferuj´ıkonzervatismus a opa- trnou zdrˇzenlivost, jin´ese snaˇz´ıpod´ıletna v´yvoji nejnovˇejˇs´ıch technologi´ıa na prosazov´an´ıtˇechto technologi´ıdo praxe. Zat´ımcourˇcit´ewebov´eprohl´ıˇzeˇceruˇs´ı podporu nˇekter´ych zastar´avaj´ıc´ıch funkcionalit, jin´evyˇck´avaj´ına vhodnˇejˇs´ı pˇr´ıleˇzitost,kdy bude zm´ınˇen´afunkcionalita odstranˇenav r´amcicel´eholo- gick´ehocelku, ˇcipreferuj´ızachov´an´ızpˇetn´ekompatibility. Pˇr´ıpadnˇemohou webov´eprohl´ıˇzeˇcezav´adˇetnov´efunkce, kter´epo nˇekolikamˇes´ıˇcn´ı ˇciroˇcn´ı podpoˇreopˇetodstran´ı,zat´ımcojin´eje na z´akladˇesv´ych uv´aˇzen´ınikdy nezaˇcaly podporovat. Dalˇs´ıwebov´eprohl´ıˇzeˇcese mohou soustˇreditna snadnou pouˇzitel- nost, vysok´yv´ykon ˇcina velk´emnoˇzstv´ıdoplˇnuj´ıc´ıch rozˇs´ıˇren´ı.Proto nelze na z´akladˇetabulky 1.1 jednoduˇse hodnotit kvality jednotliv´ych webov´ych prohl´ıˇzeˇc˚u.

1Zdroj informac´ı: www.chromestatus.com/features 2Zdroj informac´ı: www.mozilla.org/en-US/firefox/releases/ 3Zdroj informac´ı: webkit.org/ a developer.apple.com/

20 1.5. Souhrn

4Odebr´anopouze ECDSA s SHA-512 517.1.2018 zaˇcalWebKit (renderovac´ıj´adrowebov´ehoprohl´ıˇzeˇceSafari) varovat pˇred zastaralost´ıAppCache 6Odebr´an´ıinformac´ıo procesoru (32/64 bit) 7C´asteˇcn´eomezen´ıd˚uvˇery,ˇ absolutn´ıje pl´anov´anona pozdˇeji.

21

Kapitola 2

Dopady pro proxy servery

Pˇredchoz´ıkapitola pˇribliˇzujev´yvoj protokolu HTTP a jeho ˇsifrovan´everze. Z´aroveˇnodhaluje i nutnost neust´al´ehov´yvoje webov´ych prohl´ıˇzeˇc˚u,kter´etyto a mnoh´edalˇs´ıprotokoly vyuˇz´ıvaj´ı.Kromˇewebov´ych prohl´ıˇzeˇc˚uale existuje i ˇradadalˇs´ıch prvk˚u,kter´epˇren´aˇsej´ıa zpracov´avaj´ıprotokol HTTP a kter´e se rovnˇeˇzmus´ıneust´alepˇrizp˚usobovat jeho v´yvoji. Jedny z tˇechto prvk˚ujsou proxy servery. Sifrovan´averzeˇ protokolu pak sama vyuˇz´ıv´adalˇs´ıprostˇredky, jako jsou certifik´aty a s nimi souvisej´ıc´ıinfrastruktura veˇrejn´ych kl´ıˇc˚u(PKI). I u webov´ych certifik´at˚udoch´az´ı k v´yvoji a t´ım i k n´asledn´emu ovlivnˇen´ı protokolu HTTPS. V prvn´ıˇc´astitato kapitola popisuje pr´avˇezmˇeny t´ykaj´ıc´ı se webov´ych certifik´at˚u.Druh´aˇc´astse zamˇeˇrujena proxy servery a na zmˇeny, kter´eje nezbytn´eˇcivhodn´eimplementovat, aby mohly i nad´alefiltrovat pˇren´a- ˇsenouHTTPS komunikaci.

2.1 Zmˇeny v certifik´atech

Pˇrinavazovan´ıHTTPS spojen´ımezi klientem a webov´ymserverem m˚uˇzedoj´ıt v pr˚ubˇehu TLS handshake k v´ymˇenˇecertifik´at˚u.Certifik´atm˚uˇzezaslat ser- ver i klient, pro protokol TLS se obvykle jedn´ao typ X.509v3. Pokud byl certifik´atzasl´an, pak slouˇz´ık autentizaci protˇejˇs´ıstrany. Aby nebyl certifik´at odm´ıtnut jako nevalidn´ı,mus´ısplˇnovat vˇsechny n´aleˇzitostivˇcetnˇenejnovˇejˇs´ıch bezpeˇcnostn´ıch poˇzadavk˚u.

2.1.1 Parametr Subject Alternative Name

Jak jiˇzbylo zm´ınˇeno,pˇrikontrole certifik´atuwebov´ehoserveru je nutn´epo- rovnat hostname serveru s hostname uveden´ymv certifik´atu,kter´yobdrˇzel. Na obr´azku2.1 je zobrazen seznam parametr˚u,kter´eobsahuje certifik´atser- veru www.privoxy.org. Certifik´atobsahuje parametr Subject Common Name i Subject Alternative Name s hodnotou DNS Name. Podle RFC 2818 by tedy

23 2. Dopady pro proxy servery

Obr´azek2.1: Parametry certifik´atu www.privoxy.org

mˇelab´ytpro kontrolu hostname tohoto certifik´atupouˇzitahodnota Subject Alternative Name. Aby mohl proxy server filtrovat pˇren´aˇsenou HTTPS komunikaci, mus´ı pouˇz´ıtmetodu MITM. Pˇripouˇzit´ıt´etometody navazuje proxy server TLS spojen´ıs klientem, a aby autentizace webov´ehoserveru z pohledu prohl´ıˇzeˇce probˇehla´uspˇeˇsnˇe,mus´ıproxy server zaslat klientovi platn´ycertifik´ats od- pov´ıdaj´ıc´ımhostname. Pokud je v certifik´atunastaven pouze parametr Sub- ject Common Name, starˇs´ıverze webov´ych prohl´ıˇzeˇc˚upouˇzij´ıtento parametr. Novˇejˇs´ıverze vˇsakvyˇzaduj´ıparametr Subject Alternative Name a pokud ho certifik´atneobsahuje, oznaˇc´ı ho jako nevalidn´ı a varuj´ı uˇzivatele pˇred pˇr´ıstupem na danou webovou str´anku.Z tohoto d˚uvodu mus´ı zaˇc´ıt proxy servery do generovan´ych certifik´at˚utento parametr vkl´adat.Nˇekter´ekryp- tografick´eknihovny ovˇsemneumoˇzˇnuj´ıtento parametr nastavit, a tak mus´ı proxy server zvolit vhodnou knihovnu.

2.1.2 Certificate Transparency Certificate Transparency umoˇzˇnujewebov´ymprohl´ıˇzeˇc˚umovˇeˇrit,ˇzepˇrijat´y certifik´atnebyl vydan´ycertifikaˇcn´ıautoritou chybnˇe.K tomuto ovˇeˇren´ıvyuˇzij´ı ˇcasov´eraz´ıtko SCT podepsan´elogem, do kter´ehobyl certifik´atvloˇzen.Jed- nou z moˇznost´ı,jak m˚uˇzewebov´yprohl´ıˇzeˇcSCT z´ıskat,je certifik´atserveru, kter´yjej zaˇslebˇehemTLS handshake. Do certifik´atuje SCT ukl´ad´anoCA bˇehemjeho vystavov´an´ı.CA nejprve vytvoˇr´ıtzv. pˇredcertifik´at,kter´yzaˇsle

24 2.1. Zmˇeny v certifik´atech

Obr´azek2.2: Uk´azka parametru SCT list v certifik´atu www.privoxy.org

do CT logu a obratem od nˇejobdrˇz´ıSCT.[14] Pˇredcertifik´atobsahuje totoˇzn´a data jako klasick´ycertifik´at,ale jsou nav´ıcdoplnˇenarozˇs´ıˇren´ım(tzv. poison extension) s pˇreddefinovanou hodnotou. Tato hodnota slouˇz´ı k ujiˇstˇen´ı,ˇze pˇredcertifik´atnebude pouˇzitk nav´az´an´ıTLS spojen´ıani k ovˇeˇren´ıidentity webov´ehoserveru. SCT z´ıskan´eod CT logu pak CA pˇrid´ado novˇevytv´aˇren´eho certifik´atuv rozˇs´ıˇren´ı SCT list. Je vhodn´e,aby certifik´atobsahoval SCT z nˇekolika r˚uzn´ych CT log˚u,stejnˇejako v certifik´atuna obr´azku2.2.[15]

2.1.3 Podporovan´ealgoritmy

Spoleˇcnˇes protokoly HTTP a TLS doch´az´ı k v´yvoji i u algoritm˚u, kter´e jsou tˇemitoprotokoly vyuˇz´ıv´any. Z´aroveˇnvznikaj´ınov´etechniky k prolomen´ı tˇechto algoritm˚ua roste i v´ykon zaˇr´ızen´ı,kter´amohou ´utoˇcn´ıcik prolomen´ı algoritm˚uvyuˇz´ıt.[9]Z tˇechto d˚uvod˚uwebov´eprohl´ıˇzeˇceodstraˇnuj´ınˇekter´eal- goritmy ze seznamu podporovan´ych algoritm˚upro zabezpeˇcenoukomunikaci. Jako pˇr´ıkladm˚uˇzemeuv´estalgoritmus SHA-1, kter´ybyl oznaˇcenza zasta- ral´ya kter´ymohou ´utoˇcn´ıcizneuˇz´ıtk padˇel´an´ıcertifik´atu.Webov´eprohl´ıˇzeˇce n´aslednˇepˇrestalyakceptovat certifik´aty, kter´eobsahuj´ıpodepsan´yhash vy- tvoˇren´ypomoc´ıSHA-1. Webov´eservery tak mus´ınahradit star´ecertifik´aty vyuˇz´ıvaj´ıc´ıSHA-1 nov´ymi,kter´emaj´ıpodepsan´yhash vytvoˇren´ynapˇr.algorit- mem SHA-256. Kromˇehashovac´ıch algoritm˚upˇrest´avaj´ıwebov´eprohl´ıˇzeˇceak- ceptovat i zastaral´ealgoritmy slouˇz´ıc´ık digit´aln´ımpodpis˚um,pˇr´ıpadnˇeurˇcit´e kombinace podpisov´ehoalgoritmu a hashovac´ıfunkce. Jednou z takov´ych kom- binac´ıje i ECDSA s SHA-1 a s SHA-512.[7] Rovnˇeˇztyto zmˇeny mus´ızohlednit webov´eservery ve sv´ych certifik´atech.

25 2. Dopady pro proxy servery

2.1.4 Zneplatnˇen´ıcertifik´at˚u

S opakuj´ıc´ımise probl´emy CA pˇrivyd´av´an´ıcertifik´at˚upˇrich´azej´ıi nov´ezp˚uso- by, jak se s nimi vyrovnat. Certificate Revocation List (CRL) je seznam cer- tifik´at˚u,kter´ebyly vyd´avaj´ıc´ıCA zneplatnˇeny pˇreddatem ukonˇcen´ıplatnosti uveden´ymv certifik´atu.Bˇehemovˇeˇrov´an´ıcertifik´atum˚uˇzewebov´yprohl´ıˇzeˇc nebo proxy server ovˇeˇrit,ˇzecertifik´atnen´ıuveden v tomto seznamu. CRL ovˇsemspravuje CA, kter´acertifik´atvydala, a tud´ıˇzje pro zneplatnˇen´ıcerti- fik´atunutn´ajej´ıspolupr´ace. Pokud CA vydala urˇcit´ycertifik´atchybnˇea ne- spolupracuje pˇrijeho revokaci, je potˇrebavyuˇz´ıtjin´emechanismy. Proxy server ˇciwebov´yprohl´ıˇzeˇcmohou vyuˇz´ıtsluˇzebCT. Pro CT nen´ı nutn´aspolupr´aceCA, jelikoˇzcertifik´atdo CT logu m˚uˇzenahr´atkdokoli. C´ımˇ v´ıceorganizac´ıse ovˇsemzapoj´ıdo nahr´av´an´ız´aznam˚udo CT log˚u,t´ımvyˇsˇs´ı zabezpeˇcen´ım˚uˇzesluˇzba CT poskytnout.[14] Po odhalen´ıprobl´em˚us certi- fik´aty vydan´ymispoleˇcnost´ıSymantec vyuˇzilGoogle pr´avˇeCT. A tak zaˇcal webov´yprohl´ıˇzeˇcChrome vyˇzadovat zaps´an´ıvˇsech novˇevydan´ych certifik´at˚u v CT logu nejprve u certifik´at˚uvydan´ych pr´avˇespoleˇcnost´ıSymantec.[35] Po- kud certifik´att´etospoleˇcnostinebyl zapsan´yv CT logu, varoval uˇzivatele pˇred neplatn´ymcertifik´atema zastavil naˇc´ıt´an´ıwebov´estr´anky. T´ımbyl umoˇznˇen lepˇs´ıdohled nad tˇemitocertifik´aty. Webov´yprohl´ıˇzeˇcChrome nakonec zcela ukonˇcild˚uvˇerupro vˇsechny certi- fik´aty vydan´espoleˇcnost´ıSymantec pomoc´ıp˚uvodn´ıPKI.[25] To zp˚usobilo,ˇze aˇckoliv byly certifik´aty po form´aln´ıstr´anceplatn´e,prohl´ıˇzeˇcChrome je i tak oznaˇcilza neplatn´ea varoval uˇzivatele. Jin´ewebov´eprohl´ıˇzeˇceale totoˇzn´e certifik´aty pˇrijalyjako validn´ıa uˇzivatel˚umumoˇznilypˇr´ıstupna dotazovanou webovou str´anku. V pˇr´ıpadˇepouˇzit´ıproxy serveru, kter´yfiltruje HTTPS ko- munikaci, obdrˇz´ıwebov´yprohl´ıˇzeˇccertifik´atvygenerovan´yproxy serverem. Z´aleˇz´ıtedy pouze na proxy serveru, jestli oznaˇc´ıskuteˇcn´ycertifik´atserveru za validn´ıa umoˇzn´ıklientovi naˇc´ıstdotazovanou webovou str´anku,nebo jestli spojen´ı ukonˇc´ı a klienta varuje. V takov´empˇr´ıpadˇeby tedy byla webov´a str´ankavyuˇz´ıvaj´ıc´ıcertifik´atspoleˇcnostiSymantec zpˇr´ıstupnˇenai v prohl´ıˇzeˇci Chrome bez varov´an´ı.Aby bylo takov´espojen´ıukonˇcenoi s vyuˇzit´ımproxy serveru, bylo by nutn´erozˇs´ıˇritkonfiguraci o blokov´an´ılibovoln´ehocertifik´atu, pˇr´ıpadnˇeo blokov´an´ına z´akladˇeurˇcit´ych parametr˚u.

2.1.5 Uˇcel´ certifik´atu

Bˇehemovˇeˇrov´an´ıplatnosti certifik´atum˚uˇze b´ytzohlednˇeni ´uˇcel,pro kter´y byl certifik´atvyd´an,respektive ke kter´ym´uˇcel˚umlze pouˇz´ıtveˇrejn´ykl´ıˇccer- tifik´atu. Uˇcelycertifik´atumohou´ b´ytdefinov´any pomoc´ıdvou parametr˚u: Key Usage a Extended/Enhanced Key Usages. Nˇekter´ez moˇzn´ych ´uˇcel˚ujsou: autentizace serveru, autentizace klienta, ˇsifrov´an´ı,deˇsifrov´an´ı,podpis certi- fik´at˚u,. . . Pokud tedy webov´yprohl´ıˇzeˇcovˇeˇrujeidentitu severu pomoc´ıcer- tifik´atu,mus´ık tomu b´ytpˇrijat´ycertifik´aturˇcen´y.Pˇripouˇzit´ıproxy serveru

26 2.2. Zmˇeny pro proxy servery

Obr´azek2.3: Nastaven´ı´uˇcelupro certifik´at www.privoxy.org

k deˇsifrov´an´ıHTTPS komunikace tedy mus´ıproxy sever v certifik´atutyto parametry korektnˇenastavit, a to pro vˇsechny certifik´yty v ˇretˇezcivˇcetnˇecer- tifik´atuCA. Na obr´azku2.3 je zn´azornˇeno nastaven´ıtˇechto parametr˚upro www.privoxy.org.

2.2 Zmˇeny pro proxy servery

Proxy servery filtruj´ıc´ı HTTPS komunikaci mus´ı reagovat na v´yvoj tohoto protokolu i na zmˇeny ve webov´ych prohl´ıˇzeˇc´ıch. Zmˇeny se mohou t´ykatpa- rametr˚uˇsifrovan´ehospojen´ı,podporovan´ych protokol˚u,ale i nov´ych funkcio- nalit. Nˇekter´ezmˇeny v proxy serveru jsou nezbytn´epro spr´avnoufunkˇcnost, jin´epouze rozˇsiˇruj´ıjiˇzpodporovan´efunkcionality proxy serveru.

2.2.1 HTTP/2 Protokol HTTP/2 vyˇzadujeznaˇcn´arozˇs´ıˇren´ıproxy server˚upodporuj´ıc´ıpouze starˇs´ıverze protokolu HTTP. Od pˇredchoz´ıch verz´ıse totiˇzvelmi z´asadnˇeliˇs´ı, jak je pops´anov pˇredchoz´ıkapitole. N´asleduj´ıc´ıseznam uv´ad´ınejz´asadnˇejˇs´ı zmˇeny, kter´emus´ıproxy server implementovat pro podporu HTTP/2:[3]

• Jelikoˇz je protokol HTTP/2 na rozd´ıl od pˇredchoz´ıch verz´ı bin´arn´ı, je nutn´eimplementovat zcela nov´yzp˚usobparsov´an´ıpˇrijat´ych r´amc˚u. Z´aroveˇnje nezbytn´efiltrovan´adata pˇred odesl´an´ım opˇetpˇrev´estdo bin´arn´ıhoform´atu. • Komprese hlaviˇcekje v HTTP/2 implementov´anapomoc´ıtabulky hlavi- ˇcekna stranˇeklienta i serveru. Hlaviˇckupak lze nahradit odkazem od t´etotabulky. Cel´ytento mechanismus mus´ıproxy server implementovat pro komunikaci se serverem i s klientem. • HTTP/2 umoˇzˇnujepomoc´ıjedin´ehoTCP spojen´ızpracov´avat paralelnˇe ˇradupoˇzadavk˚u.K tomu slouˇz´ıtzv. streamy. Kaˇzd´ydotaz m´avlastn´ı

27 2. Dopady pro proxy servery

stream a kaˇzd´ypˇren´aˇsen´ypaket obsahuje identifik´atortohoto streamu. Klient tak mus´ıdok´azatparalelnˇezpracovat nˇekolik dotaz˚u.D´ıkyfunkci Server push nav´ıcmus´ıklient zpracov´avat i odpovˇedi,kter´eod serveru nevyˇz´adal.

• Protokol HTTP/2 vyuˇz´ıv´az d˚uvodu zpˇetn´ekompatibility s pˇredchoz´ımi verzemi stejn´eporty, tedy 80 a 443. Jelikoˇzse ale znaˇcnˇeliˇs´ıod pˇredcho- z´ıch verz´ı, mus´ı se bˇehem navazov´an´ı spojen´ı na pˇr´ıpadn´em pouˇzit´ı HTTP/2 domluvit. K tomu slouˇz´ırozˇs´ıˇren´ıApplication-Layer Protocol Negotiation (ALPN) protokolu TLS. To umoˇzˇnujebˇehemTLS hand- shake vyjednat aplikaˇcn´ıprotokol n´asledn´ekomunikace. D´ıkytomu m˚uˇze b´ytpouˇzitaˇradar˚uzn´ych aplikaˇcn´ıch protokol˚upˇresTLS spojen´ına jed- nom portu. Proxy servery tak mus´ıvyuˇz´ıvat knihovnu pro protokol TLS, kter´atoto rozˇs´ıˇren´ıpodporuje. V pˇr´ıpadˇepouˇzit´ı HTTP/2 bez TLS nen´ı rozˇs´ıˇren´ı ALPN dostupn´e. M´ıstonˇejodeˇsleklient dotaz pomoc´ıHTTP/1.1 s hlaviˇckou UPGRADE, ve kter´enavrhne pˇrechod na HTTP/2. Pokud na tento poˇzadavek server pˇristoup´ı,odeˇsleodpovˇed’ se stavov´ymk´odem101 (Switching protocol) a n´aslednˇese vyuˇz´ıv´aHTTP/2.

I kdyˇzproxy server nepodporuje HTTP/2, m˚uˇzeklientovi umoˇznitpˇrenos tˇechto poˇzadavk˚upomoc´ıtunelu skrz.[1] Tento postup lze vyuˇz´ıti v aktu´aln´ı verzi proxy serveru Privoxy.[36] Pˇr´ıpadnˇem˚uˇzepˇripˇrijet´ıpoˇzadavku na nav´a- z´an´ıspojen´ıpro protokol HTTP/2 vyjednat s webov´ymprohl´ıˇzeˇcemdegra- dov´an´ıverze protokolu.

2.2.2 Nov´ekryptografick´ealgoritmy Webov´eprohl´ıˇzeˇceimplementuj´ınejnovˇejˇs´ıverze ˇsifrovac´ıch algoritm˚ua z´aro- veˇnukonˇcuj´ıpodporu pro ty, kter´ejsou jiˇzoznaˇceny za zastaral´e.Z tohoto d˚uvodu by mˇelyi proxy servery pouˇz´ıvat kryptografick´eknihovny implemen- tuj´ıc´ı nejnovˇejˇs´ıˇsifrovac´ı algoritmy. Z´aroveˇnje vhodn´e,aby proxy servery umoˇznilyuˇzivatel˚umdefinovat specifickou ˇsifrovou sadu podle c´ılov´ehoser- veru. D´ıkytomu lze minimalizovat zranitelnosti jednotliv´ych spojen´ı.Pˇr´ıpadnˇe je vhodn´eumoˇznitalespoˇnvˇseobecn´eomezen´ıˇsifrov´esady pro vˇsechna TLS spojen´ıglob´alnˇe.Tato moˇznostale neumoˇzˇnujeudˇelitv´yjimkuz d˚uvodu zpˇet- n´ekompatibility.

2.2.3 Certificate Transparency Certificate Transparency vyˇzaduje bˇehemovˇeˇrov´an´ıplatnosti certifik´atu,aby byl certifik´atzapsan´yalespoˇnv jednom z veˇrejn´ych CT log˚u.Avˇsak CT je zpravidla vyˇzadov´anopouze pro veˇrejnˇed˚uvˇeryhodn´ecertifik´aty. To jsou certifik´aty podepsan´ekoˇrenovou CA, kter´aje dod´anav instalaci webov´eho

28 2.2. Zmˇeny pro proxy servery prohl´ıˇzeˇceˇcioperaˇcn´ıhosyst´emu.[37] Pokud pˇrijmeprohl´ıˇzeˇcod webov´ehoser- veru nebo proxy serveru certifik´atpodepsan´ysoukromou CA, pak k ovˇeˇrov´an´ı tohoto certifik´atupomoc´ı CT nedojde. Pokud tedy proxy server filtruj´ıc´ı HTTPS komunikaci podepisuje generovan´ecertifik´aty pro jednotliv´adom´eno- v´ajm´enapomoc´ısoukrom´eCA, nemus´ıtyto certifik´aty vkl´adatdo CT log˚u. A jelikoˇzCT logy dovoluj´ıvkl´adatpouze certifik´aty podepsan´ezn´amouCA, nebylo by to proxy serveru ani umoˇznˇeno. I kdyˇzproxy server nemus´ı vˇenovat pozornost CT na stranˇewebov´eho prohl´ıˇzeˇce,m˚uˇzeprov´adˇetkontrolu CT u certifik´at˚upˇrijat´ych bˇehemautenti- zace webov´ehoserveru. K tomu ale mus´ıvyuˇz´ıvat kryptografickou knihovnu, kter´atuto funkci podporuje.

2.2.4 TLS 1.3

Verze protokolu TLS 1.3 pˇrineslaˇraduzmˇenoproti pˇredchoz´ımverz´ım.Z hle- diska proxy serveru je d˚uleˇzit´ezejm´enapouˇz´ıv´an´ıkryptografick´eknihovny, kter´arychle implementuje tuto novou verzi protokolu a umoˇzn´ıtak proxy ser- veru jej´ıvyuˇz´ıv´an´ı.Veˇsker´ezmˇeny pˇrich´azej´ıc´ıs novou verz´ıprotokolu pak ˇreˇs´ıtato knihovna a dalˇs´ıpˇr´ım´ed˚usledkypro proxy server z nich nevypl´yvaj´ı.

2.2.5 Komprese certifik´at˚u

Dokud neumoˇzˇnoval protokol TLS ˇsifrovat certifik´aty pˇren´aˇsen´ev pr˚ubˇehu TLS handshake, nebyla komprese certifik´at˚upouˇz´ıv´anapr´avˇez d˚uvodu mezi- lehl´ych zaˇr´ızen´ıjako jsou proxy servery. Proxy servery totiˇzmohou vyuˇz´ıvat toho, ˇzepˇren´aˇsen´ecertifik´aty nejsou bˇehemhandshake ˇsirov´any. A i kdyˇz proxy server nepodporuje filtrov´an´ıHTTPS komunikace a m´ıstovyuˇzit´ıme- tody MITM pˇren´aˇs´ıtuto komunikaci TLS tunelem skrz proxy, dok´aˇzez pˇren´a- ˇsen´ych dat certifik´atvyexportovat. Pokud takto z´ıskan´ycertifik´atoznaˇc´ıjako nevalidn´ı,m˚uˇzeTLS tunel ukonˇcit.TLS 1.3 vˇsakpˇrineslomoˇznostˇsifrov´an´ı a komprese pˇren´aˇsen´ehocertifik´atu.Proxy servery nab´ızej´ıc´ı tuto funkcio- nalitu ji tak mus´ı pˇripouˇzit´ı TLS 1.3 vypnout. Pokud nav´ıc nedok´aˇz´ı od- halit pouˇzitouverzi TLS protokolu, mus´ıtuto funkcionalitu zcela odstranit, pˇr´ıpadnˇepro jej´ızachov´an´ıimplementovat metodu MITM.

2.2.6 Uprava´ hodnot User-Agent

Zmˇenahodnoty User-Agent webov´ymprohl´ıˇzeˇcemv hlaviˇccepoˇzadavku je z hlediska proxy serveru redundantn´ı.Pokud proxy server umoˇzˇnujefiltrovat pˇren´aˇsenoukomunikaci vˇcetnˇeHTTP hlaviˇcek,m˚uˇzehodnotu nejen tohoto parametru libovolnˇemˇenitpodle konfigurace uˇzivatele. Uˇzivatel tak s´amm˚uˇze zvolit vlastn´ıstrategii, jak pˇredej´ıtjeho identifikaci pomoc´ınastaven´ych hod- not v HTTP hlaviˇck´ach.

29 2. Dopady pro proxy servery

Obr´azek2.4: Rozdˇelen´ıTLS spojen´ıpˇripouˇzit´ıproxy na stranˇeklienta a re- verzn´ıproxy na stranˇeserveru

2.2.7 Token Binding

Aˇckoliv webov´eprohl´ıˇzeˇcepostupnˇeukonˇcuj´ıpodporu Token Binding, pˇr´ıpad- nˇeToken Binding nikdy ani nezavedly, proxy servery by mˇelyb´ytpˇripraven´e i na jeho pouˇzit´ı.Na obr´azku2.4 je vidˇet,na kolik samostatn´ych TLS spojen´ı je rozdˇelen´akomunikace mezi klientem a serverem, pokud je na stranˇeklienta pouˇzitproxy server filtruj´ıc´ıpˇren´aˇsenouHTTPS komunikaci pomoc´ımetody MITM a reverzn´ıproxy server pˇreruˇsuj´ıc´ıTLS spojen´ı(TLS terminating re- verse proxy TTRP) na stranˇeserveru. Kaˇzd´aoˇc´ıslovan´aˇsipkana obr´azku zn´azorˇnujejedno TLS spojen´ı. Pˇripouˇzit´ıToken Binding s protokolem HTTPS je token v´az´anke konkr´e- tn´ımu TLS spojen´ı.HTTP server generuj´ıc´ıtoken v r´amcicookies vˇsakpˇri pouˇzit´ı TTRP serveru z´ısk´ainformace jen z TLS spojen´ı s n´ım, napˇr´ıklad z TLS spojen´ıˇc.6. Toto spojen´ıvˇsaknemus´ıb´ytspecifick´epro konkr´etn´ıho klienta, a nav´ıcspecifikuje jen ˇc´astspojen´ımezi klientem a serverem, a tak by sv´az´an´ıtokenu s n´ımnemˇelosmysl. Pokud by byl ukraden´ytoken posl´an ´utoˇcn´ıkem, pˇriˇselby na server opˇet pˇresTLS spojen´ıˇc.6 a kontrola Token Binding by probˇehla´uspˇeˇsnˇe.[38] Tento probl´emje moˇzn´evyˇreˇsitpˇrid´an´ım nov´ych parametr˚udo HTTP hlaviˇckypoˇzadavku po jeho pˇrijet´ıreverzn´ımproxy serverem. TTRP server provede kontrolu Token Binding Message pˇrijat´eod klienta, n´aslednˇez n´ıvy- jme jednotliv´eToken Binding ID a pˇrid´aje do HTTP hlaviˇckyjako n´asleduj´ıc´ı parametry. Tyto parametry nesm´ıb´ytnastaven´eproxy serverem na stranˇekli- enta ani jin´ymimezilehl´ymizaˇr´ızen´ımi.[38]

• Sec-Provided-Token-Binding-ID Jedn´ase o typ Token Binding ID, kter´yslouˇz´ı pro vytvoˇren´ı Token Binding mezi klientem a serverem, respektive mezi proxy serverem na stranˇeklienta a TTRP serverem.

30 2.2. Zmˇeny pro proxy servery

• Sec-Referred-Token-Binding-ID

Typ Token Binding ID kter´yse pouˇz´ıv´apˇriˇz´adostio tokeny, kter´emaj´ı b´ytpˇredloˇzeny na jin´yserver, napˇr´ıkladautorizaˇcn´ı.

• Sec-Other-Token-Binding-ID

Tento parametr obsahuje seznam dalˇs´ıch typ˚uToken Binding zaslan´ych klientem a ovˇeˇren´ych TTRP serverem.

Na stranˇeklienta mus´ı b´ytToken Binding Message uvedena v prvn´ım HTTP poˇzadavku po nav´az´an´ı TLS spojen´ı s webov´ymserverem. Pokud ovˇsemklient vyuˇz´ıv´aproxy sever filtruj´ıc´ıHTTPS komunikaci, je token sv´az´an s TLS spojen´ımnejbl´ıˇze webov´emu serveru, respektive jeho TTRP. Na obr´azku 2.4 je toto spojen´ıoznaˇcen´emˇc´ıslem4. K tomuto spojen´ıovˇsemklient nem´a pˇr´ıstup,a tak pro nˇejnem˚uˇzevytvoˇritToken Binding Message. Parametry TLS spojen´ıvlastn´ıproxy server, a tak mus´ına jejich z´akladˇevytvoˇritToken Binding Message a pˇridatji do HTTP hlaviˇckypoˇzadavku pomoc´ıparame- tru Sec-Token-Binding. Webov´yserver ji sv´aˇzes vytv´aˇren´ymicookies, kter´e odeˇslev odpovˇedi.Proxy server jiˇzm˚uˇzecookies pˇreposlat klientovi, aniˇzby klient vˇedˇelo pouˇz´ıv´an´ıprotokolu Token Binding. Pokud klient uvede cookies v dalˇs´ıch poˇzadavc´ıch, klient je opˇetpˇrepoˇslewebov´emu serveru a ten ovˇeˇr´ı, ˇzebyly pˇrijaty pˇresodpov´ıdaj´ıc´ıTLS spojen´ı.

2.2.8 HTTP Public Key Pinning

HPKP pˇrip´ın´ak dom´enov´emu jm´enu konkr´etn´ıveˇrejn´ekl´ıˇce,kter´eby mˇelcer- tifik´atpˇrijat´yz konkr´etn´ıdom´eny obsahovat. Konkr´etn´ıkl´ıˇcejsou pˇren´aˇseny webov´emu prohl´ıˇzeˇcipˇriprvn´ımnaˇcten´ıwebov´estr´ankyv parametru HTTP odpovˇedi.Tyto parametry m˚uˇzeproxy server vyfiltrovat, a t´ım znemoˇznit klientovi HPKP pouˇz´ıt.Pokud se ale webov´emu prohl´ıˇzeˇcipodaˇr´ıpˇrijmout HPKP hlaviˇckuod serveru napˇr´ıkladv jin´es´ıti,m˚uˇzepˇripˇr´ıˇst´ımpˇripojen´ıpˇres proxy server konkr´etn´ıkl´ıˇcvyˇzadovat, a pokud v certifik´atunebude obsaˇzen, spojen´ıi ukonˇcit.Webov´eprohl´ıˇzeˇcejako Chrome a Firefox ale vyp´ınaj´ıkon- trolu HPKP, pokud je ˇretˇezecpˇrijat´ehocertifik´atuzakonˇcenkoˇrenov´ymcer- tifik´atem,kter´yuˇzivatel importoval do seznamu d˚uvˇeryhodn´ych CA. Tedy pokud byl pˇrijat´ycertifik´atpodepsan´yproxy serverem pomoc´ıCA, kter´aje importovan´av prohl´ıˇzeˇci, pak nebude kontrola HPKP provedena, respektive jej´ı v´ysledekbude ignorov´an.[39]D˚usledektohoto pˇr´ıstupu vˇsakumoˇzˇnuje ´utoˇcn´ık˚umobej´ıtochranu pomoc´ıHPKP, pokud dok´aˇz´ıvloˇzitvlastn´ıCA do seznamu d˚uvˇeryhodn´ych CA napˇr´ıkladpomoc´ımalware. V takov´empˇr´ıpadˇe HPKP klienta neochr´an´ı.[40]I tento fakt je argumentem pro vyuˇzit´ıjin´ych metod ochrany klienta nam´ıstoHPKP.

31 2. Dopady pro proxy servery

2.2.9 SameSite parametr u cookies Proxy server filtruj´ıc´ıHTTPS komunikaci m˚uˇzefiltrovat i parametry HTTP hlaviˇcek.D´ıkytomu m˚uˇzespr´avce proxy serveru libovolnˇeupravovat para- metr SameSite u cookies v z´avislostina dom´enˇe,ze kter´epˇrich´az´ı.Napˇr´ıklad m˚uˇzespecifikovat v´ychoz´ıhodnotu parametru SameSite, pˇr´ıpadnˇedoplnit co- okies s SameSite=None o atribut Secure, aby nebyly webov´ymprohl´ıˇzeˇcem odm´ıtnuty. D´ıkytˇemto moˇznostemmohou proxy servery obej´ıtjak´ekoli na- staven´ıtohoto parametru, pˇr´ıpadnˇejej zcela odstranit.

2.2.10 TLS 1.0 a TLS 1.1 V´yvoj zabezpeˇcen´ehoHTTP spojen´ıse net´yk´apouze kryptografick´ych algo- ritm˚u,ale i kryptografick´ych protokol˚u,kter´etyto algoritmy vyuˇz´ıvaj´ı.Webov´e servery pak postupnˇepˇrech´azej´ı na tyto novˇejˇs´ı verze protokol˚u,a t´ım se zvyˇsujejejich procentu´aln´ızastoupen´ıv r´amciHTTPS. Na tuto skuteˇcnost mus´ıreagovat i proxy servery filtruj´ıc´ıHTTPS komunikaci. Je vhodn´e,aby proxy servery umoˇznilyomezit pouˇzit´ızastaral´ych verz´ıTLS 1.0 a TLS 1.1 a nahradily je nejnovˇejˇs´ımiverzemi. Tyto nov´eprotokoly tak mus´ıb´ytpod- porov´any pouˇz´ıvanou kryptografickou knihovnou.

2.2.11 Zastar´an´ınezabezpeˇcen´ehoHTTP Aˇckoliv dosud webov´eprohl´ıˇzeˇcezpravidla nestanovily pˇresn´edatum pro ukon- ˇcen´ıpodpory nezabezpeˇcen´ehoHTTP protokolu, proklamuj´ı,ˇzek t´etoskuteˇc- nosti dojde. Proxy servery by se proto mˇely pˇripravit na tuto skuteˇcnost.Proxy servery jako je Privoxy, kter´eumoˇzˇnuj´ıfiltrovat pouze neˇsifrovan´yHTTP pro- tokol, by v takov´empˇr´ıpadˇenemohly uplatnit naprostou vˇetˇsinu sv´ych filtro- vac´ıch algoritm˚u.

32 Kapitola 3

N´avrh´uprav

Pro rozˇs´ıˇren´ıproxy serveru Privoxy o moˇznostfiltrovat veˇskerou komunikaci pˇren´aˇsenoupomoc´ıˇsifrovan´ehoHTTP spojen´ıa dalˇs´ınov´efunkcionality je nutn´enavrhnout a implementovat ˇradud´ılˇc´ıch zmˇen.Pˇredt´ımje nezbytn´e analyzovat v´ychoz´ı stav zdrojov´eho k´oduproxy serveru, ze kter´ehobudou n´asledn´e´upravy vych´azet.

3.1 Proxy server Privoxy

Privoxy je webov´yproxy server bez mezipamˇeti,kter´ynab´ız´ıˇradufunkc´ıpro filtrov´an´ıpˇren´aˇsen´eHTTP komunikace, ale pouze pokud nen´ıpˇren´aˇsenapo- moc´ızabezpeˇcen´ehospojen´ı.Tyto funkce umoˇzˇnuj´ıfiltrovat data webov´ych str´anekvˇcetnˇeHTTP hlaviˇcek.Filtry mohou slouˇzitnapˇr´ıkladpro odstranˇen´ı reklam z webov´ych str´anek,ˇcipro zv´yˇsen´ıbezpeˇcnostid´ıkyodstranˇen´ıpoten- cion´alnˇeˇskodliv´ych skript˚u.K dispozici jsou pˇreddefinovan´efiltry a dalˇs´ıakce nad pˇren´aˇsen´ymidaty. Uˇzivatel m´az´aroveˇnmoˇznostspecifikovat filtry podle individu´aln´ıch potˇreb.Bˇehemposledn´ıch tˇr´ılet byly vyd´any dvˇenov´everze proxy serveru. Nyn´ıtak je nejaktu´alnˇejˇs´ıverz´ıPrivoxy 3.0.28.

3.2 V´ystup bakal´aˇrsk´epr´ace

Tato diplomov´apr´acenavazuje na v´ystupbakal´aˇrsk´epr´ace Podpora pro fil- ” trov´an´ıSSL/TLS komunikace v Privoxy“.[1] Bakal´aˇrsk´apr´acerozˇsiˇrujeproxy sever Privoxy ve verzi 3.0.26 o moˇznostˇc´asteˇcnˇefiltrovat pˇren´aˇsenouHTTPS komunikaci. N´ıˇzejsou pops´any jednotliv´eimplementovan´eˇc´asti.

3.2.1 Metoda Man In The Middle Pro ´uspˇeˇsn´efiltrov´an´ıHTTPS komunikace bylo nutn´eimplementovat princip MITM, tedy vytvoˇren´ı dvou samostatn´ych TLS spojen´ı, jedno mezi klien- tem a proxy serverem a druh´emezi proxy serverem a webov´ymserverem.

33 3. Navrh´ uprav´

Tento postup nahradil pro HTTPS komunikaci p˚uvodn´ıpˇrenosdat pomoc´ı TLS tunelu, tedy pouh´epˇrepos´ıl´an´ıˇsifrovan´ych dat mezi klientem a serve- rem pˇresTCP spojen´ı.D´ıkyprincipu MITM jsou pˇren´aˇsen´adata deˇsifrov´ana a mohou na nˇeb´ytn´aslednˇeaplikov´any jiˇzexistuj´ıc´ıfiltrovac´ıalgoritmy im- plementovan´ev Privoxy. N´aslednˇejsou data opˇetzaˇsifrov´anaa zasl´anana c´ılov´ezaˇr´ızen´ı.Tento princip umoˇzˇnujefiltrovat komunikaci v obou smˇerech, tedy jak data pˇrijat´aod klienta, tak data od serveru, a to vˇcetnˇeHTTP hlaviˇcek.Z´aroveˇnbakal´aˇrsk´apr´aceumoˇzˇnujefiltrov´an´ıHTTPS komunikace i pˇripouˇzit´ınadˇrazen´ehoproxy serveru, i kdyˇzse v takov´empˇr´ıpadˇenava- zov´an´ıspojen´ıs c´ılov´ymwebov´ymserverem liˇs´ı.Pro TLS komunikaci byla v bakal´aˇrsk´epr´acipouˇzitakryptografick´aknihovna Mbed TLS.

3.2.2 C´asteˇcn´efiltrov´an´ıkomunikaceˇ

P˚uvodn´ıverze proxy serveru Privoxy jiˇznab´ız´ısadu funkc´ıpro filtrov´an´ıtex- tov´ych dat pˇren´aˇsen´ych pomoc´ınezabezpeˇcen´ehoHTTP spojen´ı,vˇcetnˇefunkc´ı prov´adˇej´ıc´ıch dekompresi a kompresi dat. K manipulaci s daty je moˇzn´epouˇz´ıt filtry definovan´euˇzivatelem v konfiguraˇcn´ımsouboru, pˇr´ıpadnˇepˇreddefinovan´e filtry, a nebo sofistikovanˇejˇs´ıakce, kter´ejsou implementov´any pˇr´ımove zdro- jov´emk´odu.Tyto filtry se n´aslednˇepˇriˇrazuj´ıke konkr´etn´ımurl adres´am.Na tento z´akladnav´azalabakal´aˇrsk´apr´ace,kter´aumoˇznilaaplikovat zm´ınˇen´efil- try a akce na soubory i HTTP hlaviˇckypˇrijat´epˇreszabezpeˇcen´eHTTP spo- jen´ı,ale pouze pokud byly pˇrijaty od c´ılov´ehowebov´ehoserveru. Filtrov´an´ı dat od klienta nebylo kv˚ulinezbytn´ym´uprav´amvelk´ehorozsahu v r´amciba- kal´aˇrsk´epr´acerealizov´ano.

3.2.3 Dynamick´evytv´aˇren´ıcertifik´at˚u

Pˇrivyuˇzit´ımetody MITM navazuje proxy server dvˇesamostatn´aTLS spojen´ı. Nejdˇr´ıve pˇrijmeod klienta HTTP poˇzadavek na nav´az´an´ıspojen´ıs poˇzadova- n´ymwebov´ymserverem. Tento poˇzadavek je pˇrijat pˇresnezabezpeˇcen´espo- jen´ı.Proxy server n´aslednˇevytv´aˇr´ıTLS spojen´ıs webov´ymserverem a pot´e i s klientem. Webov´yprohl´ıˇzeˇcovˇeˇrujeidentitu protˇejˇs´ıstrany pomoc´ıcerti- fik´atupˇrijat´ehov pr˚ubˇehu TLS handshake. Pokud by prohl´ıˇzeˇcoznaˇcilcerti- fik´atjako neplatn´y,upozornil by uˇzivatele a spojen´ıukonˇcil. Aby k tomu ne- doch´azelo,mus´ıproxy server zaslat validn´ıcertifik´at,kter´ybude prohl´ıˇzeˇcem uzn´anjako platn´ypro poˇzadovanou url adresu. Z tˇechto d˚uvod˚ubylo v r´amci bakal´aˇrsk´epr´aceimplementov´anoi dyna- mick´evytv´aˇren´ıcertifik´at˚ua k nim pˇr´ısluˇsej´ıc´ıch p´ar˚usoukrom´ehoa veˇrejn´eho kl´ıˇce.Ty jsou vytv´aˇreny pro kaˇzdoudom´enu, na kterou klient zaˇslepoˇzada- vek. Proxy server certifik´aty podepisuje vlastn´ı CA, kterou je z´aroveˇnne- zbytn´eimportovat do webov´ehoprohl´ıˇzeˇceklienta. Pro vytv´aˇren´ıcertifik´at˚u byla v bakal´aˇrsk´epr´acipouˇzitaknihovna Mbed TLS, kter´avˇsakneumoˇzˇnuje nastavit nˇekter´arozˇs´ıˇren´ıvytv´aˇren´ehocertifik´atu.Jedn´ımz tˇechto rozˇs´ıˇren´ı

34 3.2. V´ystupbakal´aˇrsk´epr´ace je i Subject Alternative Name. Jelikoˇzzaˇcalynˇekter´ewebov´eprohl´ıˇzeˇce striktnˇevyˇzadovat rozˇs´ıˇren´ı typu Subject Alternative Name pro ovˇeˇren´ı identity webov´ehoserveru, zaˇcalyz´aroveˇnkv˚uliabsenci tohoto parametru v pˇrijat´ych certifik´atech oznaˇcovat veˇsker´aTLS spojen´ıs proxy serverem za ned˚uvˇeryhodn´a.

3.2.4 Kontrola certifik´at˚una stranˇeproxy serveru

Jak jiˇzbylo uvedeno, pˇrifiltrov´an´ıHTTPS komunikace pomoc´ıproxy serveru je vytv´aˇrenoTLS spojen´ımezi webov´ymprohl´ıˇzeˇcema proxy serverem. Jelikoˇz proxy server zas´ıl´awebov´emu prohl´ıˇzeˇcicertifik´at,kter´ys´amvytvoˇril,nez´ısk´a prohl´ıˇzeˇcp˚uvodn´ıcertifik´atwebov´eho serveru, a tak nem˚uˇzeani ovˇeˇritplat- nost tohoto certifik´atu.Z tohoto d˚uvodu mus´ıkontrolu certifik´atuwebov´eho serveru prov´adˇetjiˇzproxy server, kter´ys t´ımto serverem navazuje TLS spo- jen´ı. Tato kontrola certifik´at˚ubyla implementov´anajiˇzv r´amcibakal´aˇrsk´e pr´acea k jej´ımu proveden´ıvyuˇz´ıv´aproxy server seznam d˚uvˇeryhodn´ych CA vytvoˇren´yspr´avcem serveru. Pokud by proxy server tuto kontrolu neprov´adˇel a vˇsechny certifik´aty automaticky oznaˇciljako validn´ı,nav´azalby TLS spo- jen´ıs klientem a zaslal mu j´ımvytvoˇren´ycertifik´at.Ten by prohl´ıˇzeˇcpˇrijal jako validn´ıa zah´ajilby s webov´ymserverem komunikaci. D´ıkytomu by bylo HTTPS spojen´ınav´az´anos jak´ymkoli webov´ymserverem bez ohledu na jeho certifik´at.Uˇzivatel by tak z˚ustalpˇredpˇr´ıpadn´ymi´utokyna jeho komunikaci s webov´ymserverem naprosto nechr´anˇen´y. Pokud proxy server oznaˇc´ı certifik´atjako neplatn´y,pˇreruˇs´ı navazov´an´ı TLS spojen´ı s webov´ymserverem, ale pˇresto nav´aˇzeTLS spojen´ı s klien- tem s vyuˇzit´ımplatn´ehocertifik´atu.N´aslednˇevˇsakt´ımto spojen´ımzaˇslekli- entovi HTML str´ankuobsahuj´ıc´ı informace o chybˇebˇehemkontroly certi- fik´atu,vˇcetnˇez´akladn´ıch informac´ıo vˇsech certifik´atech v podpisov´emˇretˇezci. Z´aroveˇnbakal´aˇrsk´apr´ace umoˇzˇnuje uˇzivateli tyto certifik´aty st´ahnout pomoc´ı odkazu. D´ıkytomu m´auˇzivatel detailn´ıinformace o d˚uvodech, pro kter´ebyl certifik´atodm´ıtnut.

3.2.5 Konfigurace

Souˇc´ast´ıbakal´aˇrsk´epr´aceje i rozˇs´ıˇren´ımoˇznost´ıkonfigurace proxy serveru o konfiguraci novˇeimplementovan´ych funkcionalit. Nastavit lze jednak para- metry pro TLS komunikaci, jako je napˇr´ıklad CA pro podpis novˇevytv´aˇren´ych certifik´at˚u,nebo soubor obsahuj´ıc´ıd˚uvˇeryhodn´eCA pouˇzit´epˇrikontrole certi- fik´at˚uwebov´ych server˚u.D´alebylo Privoxy v r´amcibakal´aˇrsk´epr´acerozˇs´ıˇreno o dvˇenov´eakce, kter´em˚uˇzespr´avce proxy serveru pˇriˇraditjednotliv´ymurl ad- res´am.Pomoc´ıakce definovan´ekl´ıˇcov´ymslovem disable-ssl-filtering lze pro protokol HTTPS vyuˇz´ıtm´ıstometody MITM p˚uvodn´ıTLS tunel. Druh´e kl´ıˇcov´eslovo ignore-certificate-errors umoˇzˇnujevypnout kontrolu cer- tifik´at˚upro zvolen´ewebov´eservery.

35 3. Navrh´ uprav´

3.3 Novˇeimplementovan´arozˇs´ıˇren´ı

V r´amcit´etodiplomov´epr´aceje implementov´anaˇradanov´ych funkcionalit a vylepˇsen´ınavazuj´ıc´ıch na pˇredchoz´ıbakal´aˇrskou pr´aci.Z´aroveˇnje provedena ˇradazmˇenve struktuˇrea zpracov´an´ızdrojov´ehok´odu.Hlavn´ıc´ılepr´acejsou uvedeny v t´etoˇc´asti.

3.3.1 Zpracov´an´ıv´ystup˚ubakal´aˇrsk´epr´ace

V´ystupbakal´aˇrsk´epr´acenen´ınijak strukturovan´y,ani nen´ıvloˇzen´ydo ˇz´adn´eho verzovac´ıhosyst´emu. To komplikuje jeho n´asledn´ezpracov´an´ıtˇret´ımistranami a pˇr´ıpadn´enasazen´ıdo produkˇcn´ıhoprostˇred´ı. Z tohoto d˚uvodu je vhodn´e prov´estpˇredsamotnou implementac´ınov´ych rozˇs´ıˇren´ırevizi v´ychoz´ıhozdro- jov´ehok´odua n´aslednˇerozdˇelen´ı´uprav implementovan´ych v bakal´aˇrsk´epr´aci do menˇs´ıch logick´ych celk˚u.Souˇcasnˇeje vhodn´etyto celky vloˇzitdo novˇe vytvoˇren´ehorepozit´aˇreumoˇzˇnuj´ıc´ıho spr´avuverz´ı. Bˇehemposledn´ıch tˇr´ılet doˇslok vyd´an´ıdvou nov´ych verz´ıproxy serveru Privoxy. Nejaktu´alnˇejˇs´ıje nyn´ıverze 3.0.28. P˚uvodn´ıbakal´aˇrsk´apr´ace ovˇsem rozˇsiˇrujeverzi 3.0.26. Pˇredzah´ajen´ımimplementace dalˇs´ıch navazuj´ıc´ıch rozˇs´ı- ˇren´ıje tedy vhodn´espojit zdrojov´yk´odbakal´aˇrsk´epr´aces nejnovˇejˇs´ıverz´ı Privoxy. D´ıkypˇredchoz´ımu rozdˇelen´ıbakal´aˇrsk´epr´acena menˇs´ılogick´ecelky je tato operace jednoduˇsˇs´ı.D´ıkyvyuˇzit´ıverzovac´ıhosyst´emu i pro implemen- taci diplomov´epr´acebude zjednoduˇsenoi jej´ı pˇr´ıpadn´epˇripojen´ı k dalˇs´ım vydan´ymverz´ım Privoxy.

3.3.2 Pˇrizp˚usoben´ıwebov´ymprohl´ıˇzeˇc˚um

Webov´eprohl´ıˇzeˇce neust´alevyd´avaj´ınov´everze, ve kter´ych implementuj´ınov´e funkcionality i nov´abezpeˇcnostn´ıopatˇren´ı.Je nezbytn´e,aby se proxy server tˇemto zmˇen´ampˇrizp˚usobil.Jedinˇetak m˚uˇzeb´ytzaruˇceno,ˇzepˇrispolupr´aci s webov´ymiprohl´ıˇzeˇcinebude doch´azetk neoˇcek´avan´ymud´alostem,jako je napˇr´ıkladn´ahl´eukonˇcen´ıspojen´ı. Jednou z takov´ych d˚uleˇzit´ych zmˇen,kter´abyla vyd´anabˇehemposledn´ıch tˇr´ılet, je kontrola dom´enov´ehojm´enav certifik´atech pouze podle hodnoty rozˇs´ıˇren´ı Subject Alternative Name. Proxy server tak mus´ıv certifik´atech toto rozˇs´ıˇren´ıkorektnˇenastavit a k tomu je nezbytn´avhodn´akryptografick´a knihovna, kter´aumoˇzˇnuje tento parametr ve vytv´aˇren´ych certifik´atech nasta- vit. Jelikoˇzkryptografick´aknihovna Mbed TLS zvolen´av r´amcibakal´aˇrsk´e pr´aceneumoˇzˇnuje nastaven´ıhodnoty pro toto rozˇs´ıˇren´ı,je nutn´ezvolit no- vou, kter´abude l´epe vyhovovat ´uˇcel˚umproxy serveru. Z´aroveˇnje nezbytn´e implementovat veˇsker´efunkcionality z bakal´aˇrsk´epr´acei s vyuˇzit´ımt´etonov´e knihovny tak, aby bylo co nejv´ıcezachov´anorozhran´ıp˚uvodn´ıch funkc´ı.D´ıky tomu bude moˇzn´ezkompilovat proxy server s p˚uvodn´ınebo novou knihovnou podle preferenc´ıuˇzivatele.

36 3.3. Novˇeimplementovan´arozˇs´ıˇren´ı

3.3.3 Umoˇznˇen´ıkompilace bez kryptografick´ych knihoven

D´ıkyzachov´an´ıstejn´eho rozhran´ıu funkc´ıvyuˇz´ıvaj´ıc´ıch novou kryptografic- kou knihovnu, jako maj´ıp˚uvodn´ıfunkce implementovan´ev bakal´aˇrsk´epr´aci, bude moˇzn´epomoc´ımaker v k´oduumoˇznitkompilaci s novou ˇcip˚uvodn´ıkni- hovnou. Z´aroveˇnlze d´ıkymakr˚umupravit zdrojov´ek´odytak, aby se uˇzivatel mohl rozhodnout zkompilovat proxy server v p˚uvodn´ıpodobnˇe,tedy bez kryp- tografick´eknihovny a bez rozˇs´ıˇren´ıumoˇzˇnuj´ıc´ıhofiltrovat HTTPS komunikaci. Rozˇs´ıˇren´ıvstupn´ıch soubor˚udo konfiguraˇcn´ıch skript˚upak umoˇzn´ıuˇzivateli pomoc´ıpˇrep´ınaˇc˚uzvolit preferovan´yzp˚usobkompilace bez jak´ychkoli zmˇen v k´odu.Konfiguraˇcn´ıskripty n´aslednˇevygeneruj´ıodpov´ıdaj´ıc´ı makefile.

3.3.4 Filtrov´an´ıveˇsker´epˇren´aˇsen´eHTTPS komunikace

Hlavn´ım c´ılem t´etodiplomov´epr´aceje modernizovat proxy server Privoxy tak, aby bylo moˇzn´ejeho veˇsker´efunkcionality pro filtrov´an´ıHTTP komu- nikace vyuˇz´ıt i pro komunikaci pˇren´aˇsenoupˇreszabezpeˇcen´espojen´ı, tedy pomoc´ıprotokolu HTTPS. Tato pr´ace navazuje na bakal´aˇrskou pr´aci, kter´a jiˇzumoˇzˇnujepouˇz´ıttyto funkcionality pro data pˇrijat´aod webov´eho serveru. Je tedy potˇrebaupravit naˇc´ıt´an´ı poˇzadavk˚uwebov´ehoprohl´ıˇzeˇcetak, aby i v pˇr´ıpadˇevyuˇzit´ıHTTPS komunikace byly tyto poˇzadavky naparsov´any. Na z´akladˇetakto z´ıskan´ych dat pak bude moˇzn´eaplikovat uˇzivatelem definovan´e akce upravuj´ıc´ıparametry HTTP dotazu. Pot´ese dotaz opˇetsestav´ız upra- ven´ych parametr˚ua odeˇslepomoc´ıˇsifrovan´ehospojen´ına webov´yserver.

3.3.5 Konfiguraˇcn´ırozhran´ıpˇresHTTPS

Proxy server Privoxy umoˇzˇnujezobrazit a editovat konfiguraci nˇekter´ych pa- rametr˚upomoc´ıwebov´estr´ankydostupn´ena specifick´eurl adrese. Z´aroveˇnje moˇzn´ena t´etourl ovˇeˇritaplikovan´efiltry pro zadanou url, pˇr´ıpadnˇeovˇeˇrit v´ystuppo aplikov´an´ı urˇcit´ych filtr˚u. Toto konfiguraˇcn´ı rozhran´ı je ovˇsem v proxy serveru Privoxy dostupn´epouze pˇresnezabezpeˇcen´espojen´ı.Pokud uˇzivatel zad´adotaz na konfiguraˇcn´ıurl s pˇredponou https://“, pak Privoxy ” nevr´at´ıkonfiguraˇcn´ırozhran´ı,ale pokus´ıse dotaz pˇresmˇerovat na konkr´etn´ı webov´yserver, kter´yzpravidla nen´ıdostupn´y. Proxy server nemus´ıb´ytvˇzdyspuˇstˇen´ypˇr´ımona lok´aln´ımzaˇr´ızen´ıuˇzivate- le, ale napˇr´ıklad na serveru, routeru nebo jin´ems´ıt’ov´emzaˇr´ızen´ı. Je tedy vhodn´e,aby pˇr´ıpadn´akomunikace mezi tˇemitodvˇemazaˇr´ızen´ımi,kter´am˚uˇze upravovat konfiguraci proxy serveru, byla zabezpeˇcen´a.To umoˇzn´ızabr´anit odposlechu komunikace v r´amcilok´aln´ıs´ıtˇe.Proto je potˇrebaupravit funkci obsluhuj´ıc´ıpˇrijat´epoˇzadavky tak, aby odchytila specifick´eurl adresy pro ´uˇcel konfigurace, i pokud byly tyto poˇzadavky pˇrijaty pˇresTLS spojen´ı.Pokud by webov´eprohl´ıˇzeˇcepˇristoupilyk blokov´an´ıwebov´ych str´anek,kter´ejsou z ˇc´asti pˇrijat´eprotokolem HTTP a z ˇc´astiprotokolem HTTPS, pak by tato ´uprava

37 3. Navrh´ uprav´

Obr´azek 3.1: Srovn´an´ı doby naˇc´ıt´an´ı vybran´ych webov´ych str´anek podle pouˇzit´emetody a poˇctujej´ıch subresources. Pouˇzit´yproxy server je v´ystupem pˇredchoz´ıbakal´aˇrsk´epr´ace.

pˇredeˇslablokov´an´ıkonfiguraˇcn´ıhorozhran´ı.K tomu by mohlo doj´ıt,jelikoˇz v´ychoz´ıurl adresa pro konfiguraci je subdom´enou www.privoxy.org.

3.3.6 Opakovan´epouˇz´ıv´an´ıTLS sessions

Pokud srovn´amedobu potˇrebnoupro naˇcten´ı kompletn´ıho obsahu webov´e str´ankybez pouˇzit´ıproxy serveru, s pouˇzit´ımp˚uvodn´ıhoˇreˇsen´ıimplemento- van´ehov Privoxy (TLS tunel) a s metodou MITM implementovanou v r´amci bakal´aˇrsk´epr´aceviz obr´azek3.1, vid´ıme velk´yrozd´ıl pˇredevˇs´ım u metody MITM. Pˇripouˇzit´ımetody MITM se doba naˇc´ıt´an´ıstr´ankyznaˇcnˇeprodluˇzuje, a to pˇredevˇs´ıms rostouc´ımpoˇctemsubresources, tedy pokud se webov´astr´anka skl´ad´az velk´ehomnoˇzstv´ıdalˇs´ıch prvk˚u, kter´eje potˇreba samostatnˇenaˇc´ıtat. D˚uvod tohoto n´ar˚ustudoby naˇc´ıt´an´ım˚uˇzemevidˇetna obr´azku3.2. Ten zn´azorˇnujepr˚ubˇehnaˇc´ıt´an´ıwebov´estr´anky www.privoxy.org s pouˇzit´ımproxy serveru, kter´yvyuˇz´ıv´ametodu MITM k filtrov´an´ıkomunikace. Jedn´ase tedy o pˇr´ıstup implementovan´yv r´amcibakal´aˇrsk´epr´ace.Klient nejdˇr´ıve zaˇsle poˇzadavek na adres´aˇr /“, na kter´ymu server vr´at´ıindexov´ysoubor. N´aslednˇe ” klient zas´ıl´apoˇzadavky na dalˇs´ıˇc´astistr´ankyodkazovan´ez indexov´ehosou- boru, tedy na soubory p doc.css“ a favicon.ico“. Pro kaˇzd´yz tˇechto dotaz˚u ” ” vytv´aˇr´ıproxy server nov´eTLS spojen´ıs klientem i webov´ymserverem. Tato spojen´ıjsou na obr´azku3.2 odliˇsena r˚uzn´ymibarvami ˇsipek. Celkem je tedy vytv´aˇrenoˇsestsamostatn´ych TLS spojen´ı,kter´ajsou ihned po pˇrenesen´ısou- boru uzav´ır´ana.Reˇziena vytv´aˇren´ıTLS spojen´ızpomaluje naˇc´ıt´an´ıwebov´e str´ankya nese tak nezanedbateln´ypod´ılna celkov´edobˇepotˇrebn´epro jej´ı naˇcten´ı.Opakovan´evyuˇzit´ıvytvoˇren´ych TLS spojen´ıby tak urychlilo naˇc´ıt´an´ı, zejm´enapro webov´estr´ankys velk´ymmnoˇzstv´ımsubresources. P˚uvodn´ıverze

38 3.3. Novˇeimplementovan´arozˇs´ıˇren´ı

Klient Proxy sever www.privoxy.org

CONNECT www.privoxy.org:443 HTTP/1.1 GET / HTTP/1.1 GET / HTTP/1.1 HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data /

CONNECT www.privoxy.org:443 HTTP/1.1 GET /p_doc.css HTTP/1.1 CONNECT www.privoxy.org:443 HTTP/1.1 GET /p_doc.css HTTP/1.1 GET /favicon.ico HTTP/1.1 HTTP/1.1 200 OK + data /p_doc.css HTTP/1.1 200 OK + data /p_doc.css GET /favicon.ico HTTP/1.1 HTTP/1.1 200 OK + data /favicon.ico HTTP/1.1 200 OK + data /favicon.ico

Obr´azek3.2: Naˇc´ıt´an´ı jednotliv´ych ˇc´ast´ı webov´estr´anky www.privoxy.org s pouˇzit´ımproxy serveru Privoxy s rozˇs´ıˇren´ımiimplementovan´ymiv r´amci bakal´aˇrsk´epr´ace.

Privoxy jiˇzumoˇzˇnujezachov´avat nav´azan´aTCP spojen´ıa n´aslednˇeje i opa- kovanˇevyuˇz´ıt. Pro tento ´uˇcelzohledˇnujehodnotu parametru Keep-Alive z HTTP hlaviˇcky. Zachov´av´an´ıvytvoˇren´ych TLS spojen´ıovˇsemPrivoxy ne- umoˇzˇnuje. K opakovan´emu vyuˇzit´ı TLS spojen´ı se vyuˇz´ıvaj´ı tzv. TLS session. Ty umoˇzˇnuj´ıobnovit dˇr´ıve vytvoˇren´aTLS spojen´ıpomoc´ısession identifik´atoru, kter´yobˇekomunikuj´ıc´ıstrany vyjednaly bˇehemTLS handshake. Pˇri opˇetov- n´emnavazov´an´ıTLS spojen´ım˚uˇzeklient tento identifik´atorna server zaslat, a d´ıky tomu zrychlenˇeobnovit dˇr´ıvˇejˇs´ı pˇredchoz´ı TLS. Server ovˇsemm˚uˇze pˇrijat´yidentifik´atorodm´ıtnoutjako neplatn´y.[8] Opakovan´evyuˇzit´ıTLS sessi- ons m˚uˇzeurychlit naˇc´ıt´an´ıwebov´estr´anky, i pokud jsou jej´ızdroje na r˚uzn´ych webov´ych serverech, avˇsakpouze pokud alespoˇnnˇekter´ez tˇechto zdroj˚usd´ıl´ı spoleˇcn´ywebov´yserver.

3.3.7 Sd´ılen´ıTLS sessions mezi jednotliv´ymiklienty

P˚uvodn´ıproxy server Privoxy umoˇzˇnujeTCP spojen´ınejen uchov´avat k opˇe- tovn´emu pouˇzit´ı.K dispozici je i funkcionalita umoˇzˇnuj´ıc´ıexistuj´ıc´ıTCP spo- jen´ı sd´ılet mezi jednotliv´ymiklienty, respektive mezi vl´akny zpracov´avaj´ıc´ı jednotliv´aspojen´ıze strany klienta. Pokud tedy jeden klient zaˇslepoˇzadavek napˇr´ıkladna www.privoxy.org, proxy server jej odbav´ıa uchov´aspojen´ık dal- ˇs´ımu pouˇzit´ı.Pokud n´aslednˇev urˇcit´emˇcasov´emintervalu pˇrijdedalˇs´ıpoˇzada- vek od jin´ehoklienta na stejnou dom´enu, proxy server nenavazuje nov´espo-

39 3. Navrh´ uprav´

jen´ı,ale poskytne jiˇzexistuj´ıc´ıspojen´ınov´emu klientovi. T´ımdoch´az´ık ´uspoˇre ˇcasupotˇrebn´ehopro nav´az´an´ınov´ehospojen´ı.Tento princip je vhodn´eapliko- vat i pro vytvoˇren´aTLS spojen´ıa za urˇcit´ych okolnost´ıtak urychlit naˇc´ıt´an´ı webov´estr´anky. Sd´ılen´ıspojen´ımezi klienty m´aovˇsemd˚usledkynejen pro rychlost, ale i pro bezpeˇcnost.Pokud proxy server vyuˇz´ıv´anˇekolik uˇzivatel˚u,mohou jednot- liv´ıuˇzivatel´epouˇz´ıvat i spojen´ıjin´ych uˇzivatel˚u.To m˚uˇzeb´ytnebezpeˇcn´e, pokud jsou pouˇzitaautentizaˇcn´ı sch´ematajako je NTLM, kde je autenti- zov´anopouze spojen´ı jako celek a ne jednotliv´edotazy.[41] Z´aroveˇntento pˇr´ıstupm˚uˇzeoslabovat dalˇs´ımetody zabezpeˇcen´ı,kter´evyuˇz´ıvaj´ıinformace o konkr´etn´ım spojen´ı. Jako pˇr´ıklad m˚uˇzemeuv´estmetodu Token Binding, kter´akryptograficky svazuje aplikaˇcn´ıtokeny s TLS vrstvou. Z tˇechto d˚uvod˚u by mˇelspr´avce proxy serveru povolit sd´ılen´ıTLS sessions pouze v pˇr´ıpadˇe, ˇzesi je vˇedomveˇsker´ych souvisej´ıc´ıch rizik a zv´aˇzilje oproti potencion´aln´ım v´yhod´amtohoto ˇreˇsen´ı.K povolen´ısd´ılen´ıTLS sessions slouˇz´ıkl´ıˇcov´eslovo connection-sharing v konfiguraˇcn´ım souboru config. Toto kl´ıˇcov´eslovo slouˇzilojiˇzv pˇredchoz´ıch verz´ıch Privoxy pro sd´ılen´ıTCP spojen´ı.

3.3.8 Konfigurace ˇsifrov´ych sad Kryptografick´eknihovny pˇrinavazov´an´ıTLS spojen´ıodes´ılaj´ıprotˇejˇs´ıstranˇe ˇsifrovou sadu, pomoc´ı kter´especifikuj´ı podporovan´ealgoritmy pro v´ymˇenu kl´ıˇce,ˇsifrov´an´ı pomoc´ı tohoto kl´ıˇcea pro ovˇeˇren´ı zpr´av.Seznam je nav´ıc seˇrazen´ysestupnˇepodle preferenc´ı. Protˇejˇs´ı strana porovn´apˇrijatou sadu s vlastn´ımi podporovan´ymialgoritmy, vybere z nich nejvhodnˇejˇs´ı a odeˇsle tento n´avrhklientovi. Klient n´avrhpotvrd´ınebo zam´ıtne.V p˚uvodn´ıverzi Pri- voxy nelze zvolit vlastn´ıˇsifrovou sadu, a tak knihovna pouˇzijev´ychoz´ı,kter´a je specifick´apro kaˇzdouverzi knihovny. V´ychoz´ıˇsifrov´asada je jak´ymsikom- promisem mezi bezpeˇcnost´ıa kompatibilitou. V knihovnˇeLibreSSL je ovˇsem v t´etosadˇepovolen i algoritmus RC4, kter´yjiˇznen´ıpovaˇzov´anza bezpeˇcn´y. Pro zv´yˇsen´ı´urovnˇezabezpeˇcen´ıje tedy vhodn´e,aby mohl klient s´amdefinovat konkr´etn´ıˇsifrovou sadu pro vybran´ewebov´eservery. D´ıkytomu m˚uˇzenejen nastavit vysokou ´uroveˇnzabezpeˇcen´ı,ale z d˚uvodu zpˇetn´ekompatibility m˚uˇze udˇelitvybran´ymserver˚umi v´yjimku.

40 Kapitola 4

Implementace

Souˇc´ast´ıdiplomov´epr´aceje i implementace navrˇzen´ych ´uprav. Implementace navazuje na v´ystuppˇredchoz´ıbakal´aˇrcepr´ace,kterou d´alerozˇsiˇruje.Mnoh´a z tˇechto rozˇs´ıˇren´ı je moˇzn´eimplementovat ˇradouodliˇsn´ych zp˚usob˚u,kter´e n´aslednˇeovlivˇnuj´ı funkˇcnost,bezpeˇcnosti rozˇsiˇritelnostv´ysledn´ehoˇreˇsen´ı. Proto tato kapitola popisuje principy zvolen´ehoˇreˇsen´ı, vˇcetnˇed˚uvod˚upro pouˇzit´ıkonkr´etn´ıch postup˚u.

4.1 Pouˇzit´ıverzovac´ıhosyst´emu Git

Pro implementaci diplomov´epr´acebyl vytvoˇrenrepozit´aˇrna serveru GitLab. V´ychoz´ıcommit obsahuje zdrojov´yk´odPrivoxy verze 3.0.28, kter´aje nyn´ınej- aktu´alnˇejˇs´ıverz´ıtohoto proxy serveru. Zdrojov´yk´odbakal´aˇrsk´epr´aceovˇsem vych´az´ız Privoxy verze 3.0.26. Hlavn´ızmˇeny mezi tˇemitoverzemi, kter´emaj´ı nejvˇetˇs´ıdopad na spojen´ıt´etoverze s bakal´aˇrskou prac´ı,jsou:

• Rozdˇelen´ıfunkce Chat Funkce Chat je vol´anapo akceptov´an´ıpˇripojen´ıod klienta. Jej´ım´ukolem je pˇrijmoutpoˇzadavek klienta, zpracovat ho, pˇreposlat na c´ılov´yserver a pˇrijatou odpovˇed’ pˇredatklientovi. Ve starˇs´ıch verz´ıch byla tato funkce velmi rozs´ahl´aa nepˇrehledn´a,a tak doˇslok jej´ımu rozdˇelen´ıdo dvou sa- mostatn´ych funkc´ı.Prvn´ıˇc´astz˚ustalasouˇc´ast´ıfunkce chat a zajiˇst’uje naˇcten´ı HTTP hlaviˇcky od klienta, jej´ı parsov´an´ı a nastaven´ı para- metr˚uspojen´ıpodle jej´ıhoobsahu. Druh´afunkce handle established- connection obsahuje cyklus pro zpracov´an´ı, filtrov´an´ı a pˇrepos´ıl´an´ı dalˇs´ıch pˇren´aˇsen´ych dat. Z´aroveˇndoˇslov nov´everzi k celkov´emu pˇrepra- cov´an´ı zdrojov´ehok´odufunkce chat, kter´epˇrineslonapˇr´ıklad zredu- kov´an´ıduplicit d´ıkyvytvoˇren´ınov´ych funkc´ıpro pr´acis daty. Zmˇeny implementovan´ev r´amcibakal´aˇrsk´epr´acezasahuj´ızejm´enado funkce chat, a proto bylo nezbytn´epˇrizp˚usobitzdrojov´yk´odbakal´aˇrsk´epr´ace nov´everzi Privoxy.

41 4. Implementace

• Nahrazen´ıfunkce select funkc´ı poll P˚uvodn´ıverze Privoxy vyuˇz´ıv´ak urˇcen´ıaktivn´ıch soket˚ufunkci select. Nov´averze ovˇsemk tomuto ´uˇcelunab´ız´ıi funkci poll a oznamuje, ˇze v budoucnu tato funkce zcela nahrad´ıfunkci select. D˚uvodem zmˇeny je zejm´enaproblematick´eˇsk´alov´an´ıpoˇctusoket˚upˇripouˇzit´ıfunkce se- lect.[42] To je zp˚usobeno souvisej´ıc´ımmakrem fd set pro vloˇzen´ıso- ketu do mnoˇziny, kter´epouˇz´ıv´abitovou masku urˇcit´eomezen´ed´elky. Na- proti tomu funkce poll umoˇzˇnujeuˇzivateli alokovat pole soket˚ua pˇredat jeho velikost, tud´ıˇzneomezuje poˇcet soket˚u.[43]

Z tˇechto d˚uvod˚ubylo nezbytn´epˇredimplementac´ı nov´ych funkcionalit pˇrizp˚usobitzdrojov´yk´odbakal´aˇrsk´epr´acenov´everzi Privoxy. Proto byl nej- prve zdrojov´yk´odbakal´aˇrsk´epr´acerozdˇelenna menˇs´ılogick´ecelky, kter´elze snadnˇejipˇrizp˚usobitzmˇen´amv novˇejˇs´ıverzi Privoxy. Tyto celky pak byly sa- mostatnˇepˇripojov´any k ´uvodn´ımu commitu. Nejv´yznamnˇejˇs´ımiˇc´astmijsou:

1. Nahrazen´ımetody TLS tunelu metodou MITM • Vytv´aˇren´ıTLS spojen´ıs c´ılov´ymserverem Na z´akladˇeklientova poˇzadavku CONNECT, pˇrijat´ehopˇresnezabez- peˇcen´espojen´ı,iniciuje proxy server navazov´an´ızabezpeˇcen´ehospo- jen´ıs poˇzadovan´ymwebov´ymserverem. • Vytv´aˇren´ıTLS spojen´ıs klientem Pot´e,co proxy server ´uspˇeˇsnˇenav´aˇzeTLS spojen´ıs webov´ymser- verem, potvrd´ıtuto skuteˇcnostklientovi, a n´aslednˇes n´ımnav´aˇze zabezpeˇcen´eTLS spojen´ı. • Pˇrepos´ıl´an´ıdat mezi klientem a serverem Pot´eco je nav´az´anoTLS spojen´ıse serverem i s klientem, je potˇreba pˇrepos´ılatdata mezi nimi. Jako prvn´ıje serveru zasl´anpoˇzadavek klienta. N´aslednˇejsou v cyklu pˇrepos´ıl´anaveˇsker´adata, kter´aproxy server pˇrijme. Pˇrijet´ı dat je detekov´anopomoc´ı funkce select, pˇr´ıpadnˇejsou data ˇcekaj´ıc´ık naˇcten´ına z´asobn´ıkuovˇeˇrena pomoc´ı rozhran´ıkryptografick´eknihovny. Veˇsker´e´upravy mus´ızachov´avat funkˇcnosti pro nezabezpeˇcen´aspojen´ı. • Pouˇzit´ınadˇrazen´ehoproxy serveru Pˇripouˇzit´ınadˇrazen´ehoproxy serveru je potˇrebacel´ypostup upra- vit. Proxy server nenavazuje TLS spojen´ıs c´ılov´ymserverem, ale pˇrepos´ıl´apoˇzadavek CONNECT od klienta na nadˇrazen´yproxy ser- ver. Z´aroveˇnproxy sever nevytv´aˇr´ıpotvrzen´ıo nav´az´an´ıspojen´ı,ale pouze pˇrepos´ıl´apotvrzen´ıvytvoˇren´enadˇrazen´ymproxy serverem. • Podpora funkce poll Pokud klient podporuje funkci poll, je pouˇzit´ı t´etofunkce pre- ferov´ano.Bylo tedy nezbytn´epˇrizp˚usobitdetekci pˇr´ıchoz´ıch dat

42 4.2. Zmˇenakryptografick´eknihovny

pomoc´ıfunkce poll i pˇripouˇzit´ıTLS spojen´ı.Proto je v pˇr´ıpadˇe ˇcekaj´ıc´ıch dat na z´asobn´ıkuruˇcnˇenastavena ud´alost POLLIN signa- lizuj´ıc´ıtuto skuteˇcnost,kter´aje d´alestandardnˇezpracov´ana.

2. Zpracov´an´ıcertifik´at˚u

• Kontrola platnosti certifik´at˚u Bˇehemnavazov´an´ıTLS spojen´ıs poˇzadovan´ymserverem mus´ıpro- xy server ovˇeˇritplatnost pˇrijat´ehocertifik´atu.Pokud je certifik´at platn´y,komunikace m˚uˇzepokraˇcovat. V opaˇcn´empˇr´ıpadˇeje klient informov´ano d˚uvodech, proˇcnebyl certifik´atuzn´anjako platn´y. • Vytv´aˇren´ıcertifik´at˚uwebov´ych str´anek Proxy server mus´ıwebov´emu prohl´ıˇzeˇciv pr˚ubˇehu TLS handshake zaslat certifik´atkoresponduj´ıc´ıs poˇzadovanou dom´enou.V opaˇcn´em pˇr´ıpadˇeby webov´yprohl´ıˇzeˇcpˇreruˇsilnavazov´an´ıspojen´ıa infor- moval uˇzivatele o pˇr´ıˇcin´ach. Proto mus´ı proxy server generovat vlastn´ısoukrom´ekl´ıˇcea pomoc´ıvlastn´ıCA podepisovat pro kaˇzdou z poˇzadovan´ych dom´enodpov´ıdaj´ıc´ıcertifik´at.Aby nebyl certifik´at vytv´aˇrenopakovanˇe,jsou vytvoˇren´ecertifik´aty ukl´ad´any a n´aslednˇe naˇc´ıt´any jednotliv´ymivl´akny, kter´aobsluhuj´ı jednotliv´eklienty. Z d˚uvodu paraleln´ıhobˇehu ve v´ıcevl´aknech jsou vyuˇzity mutexy pro zabr´anˇen´ıkoliz´ım.

3. Konfigurace Souˇc´ast´ıbakal´aˇrsk´epr´aceje i rozˇs´ıˇren´ımoˇznost´ıkonfigurace. Konkr´etnˇe se jedn´ao konfiguraci parametr˚upro generov´an´ı certifik´at˚u,d´aleje umoˇznˇenopro zvolen´eurl adresy nahradit novˇeimplementovanou me- todu MITM p˚uvodn´ımˇreˇsen´ımpomoc´ıTLS tunelu a posledn´ırozˇs´ıˇren´ı konfigurace umoˇzˇnujepro vybran´eurl adresy vypnout kontrolu certi- fik´atuwebov´ehoseveru. Vˇsechna tato rozˇs´ıˇren´ıbyla rovnˇeˇzpˇrizp˚usobena nejnovˇejˇs´ıverzi Privoxy.

4.2 Zmˇena kryptografick´eknihovny

Hlavn´ımd˚uvodem pro zmˇenu kryptografick´eknihovny je zachov´an´ıkompa- tibility s modern´ımiwebov´ymiprohl´ıˇzeˇci.Privoxy je licencov´anopod licenc´ı GNU GPLv28. Je tedy nezbytn´ezvolit takovou kryptografickou knihovnu, kter´anejen ˇzenab´ıdne veˇsker´epotˇrebn´efunkcionality, ale z´aroveˇnbude kom- patibiln´ıs touto licenc´ı.Proto byla v r´amcidiplomov´epr´acepouˇzitakrypto- grafick´aknihovna LibreSSL9. Tato knihovna vznikla v roce 2014 odˇstˇepen´ım

8GNU General Public License, version 2. Dostupn´ena: https://www.gnu.org/licenses/ old-licenses/gpl-2.0.html 9Kryptografick´aknihovna LibreSSL. Dostupn´ena: https://www.libressl.org/

43 4. Implementace od knihovny OpenSSL s c´ılem modernizovat p˚uvodn´ızdrojov´ek´odya zlepˇsit bezpeˇcnost. Knihovna je licencov´anapod licenc´ıOpenBSD.10 Kryptografick´aknihovna LibreSSL umoˇzˇnujenastavovat rozˇs´ıˇren´ı Subject Alternative Name u vytv´aˇren´ych certifik´at˚u,kter´eje nezbytn´epro zajiˇstˇen´ı funkˇcnostis nov´ymiverzemi webov´ych prohl´ıˇzeˇc˚u.Z´aroveˇntato knihovna nab´ız´ıi podporu protokolu APLN, kter´yje vyuˇz´ıv´anpˇri navazov´an´ıHTTP/2 spojen´ı.D´ıkytomu by mohla b´yttato knihovna vyuˇzita,i pokud by se Privoxy v budoucnu rozhodlo pro podporu tohoto protokolu. Jedn´ımz nedostatk˚ut´eto knihovny je aktu´alnˇechybˇej´ıc´ıpodpora CT. Kv˚ulizmˇenˇekryptografick´eknihovny bylo n´aslednˇenutn´eimplementovat veˇsker´ekryptografick´efunkcionality, kter´ejiˇzbyly implementov´any v pˇredchoz´ı bakal´aˇrsk´epr´aci. Jedn´ase o funkce pro navazov´an´ıTLS spojen´ı,pˇrepos´ıl´an´ı dat pˇresTLS spojen´ı,kontrola webov´ych certifik´at˚u,vytv´aˇren´ıwebov´ych cer- tifik´at˚ua dalˇs´ıfunkce, z nichˇznˇekter´ejsou detailnˇejipops´any v ˇc´asti4.1.

4.3 Konfigurace kompilaˇcn´ıch skript˚u

D´ıkypouˇzit´ınov´ekryptografick´eknihovny byla vytvoˇrenadruh´afunkˇcn´ıverze proxy serveru Privoxy implementuj´ıc´ıprincip MITM. Kaˇzd´az tˇechto verz´ım´a sv´ev´yhody i nev´yhody a jednotliv´ıuˇzivatel´emohou preferovat jinou z tˇechto dvou knihoven. Z´aroveˇnmohou nˇekteˇr´ıuˇzivatel´epreferovat pouˇz´ıv´an´ıPrivoxy bez moˇznostifiltrovat HTTPS komunikaci a tedy i bez vyuˇz´ıv´an´ı jak´ekoli kryptografick´eknihovny. Z tˇechto d˚uvod˚ubyl v r´amcidiplomov´epr´ace upra- ven soubor configure.in, na jehoˇzz´akladˇegeneruje n´astroj Autoconf kon- figuraˇcn´ıskript. S vyuˇzit´ım tohoto konfiguraˇcn´ıho skriptu jsou n´aslednˇevy- tvoˇreny soubory makefile a config.h. Zat´ımco makefile slouˇz´ıke kompilaci zdrojov´ych k´od˚u,soubor config.h obsahuje direktivy #define definuj´ıc´ıjed- notliv´eidentifik´atory. Tyto identifik´atoryjsou n´aslednˇevyuˇz´ıv´any v r´amci zdrojov´ych k´od˚uu direktiv #ifdef pro podm´ınˇen´ekompilov´an´ıblok˚uzdro- jov´ehok´odu. Aby mohli uˇzivatel´ezvolit preferovanou kryptografickou knihovnu, kter´a bude pouˇzitav pr˚ubˇehu kompilace, byl soubor configure.in rozˇs´ıˇreno dva nov´eparametry. Ty mohou b´ytpouˇzity pˇrivol´an´ı konfiguraˇcn´ıho skriptu. Zp˚usobpouˇzit´ıtˇechto parametr˚uje popsan´yv tabulce 4.1, ve kter´eje uvedena v´ysledn´akryptografick´aknihovna, kter´abude pˇrizvolen´ekombinaci pˇrep´ınaˇc˚u pouˇzitav pr˚ubˇehu kompilace. Na z´akladˇepouˇzit´ych pˇrep´ınaˇc˚ujsou konfi- guraˇcn´ım skriptem upraveny direktivy #define jednotliv´ych identifik´ator˚u v souboru config.h, a z´aroveˇnjsou nastaveny promˇenn´ev makefile souboru. Tyto identifik´atoryn´aslednˇeaktivuj´ıˇcideaktivuj´ıpˇr´ısluˇsn´ebloky zdrojov´eho k´oduv pr˚ubˇehu kompilace. Uˇzivatel n´aslednˇepouˇzijepˇr´ıkaz make k proveden´ı kompilace podle sv´ych preferenc´ı.

10OpenBSD Copyright Policy. Dostupn´ena: https://www.openbsd.org/policy.html

44 4.4. Filtrov´an´ıpˇrijat´ych poˇzadavk˚u

Tabulka 4.1: Pouˇzit´ınov´ych pˇrep´ınaˇc˚ukonfiguraˇcn´ıhoskriptu

--disable-libressl --enable-mbedtls Z´adn´ypˇrep´ınaˇcˇ --disable Bez kryptografick´e Bez kryptografick´e Mbed TLS -libressl knihovny knihovny --enable Mbed TLS Mbed TLS Mbed TLS -mbedtls Z´adn´yˇ Bez kryptografick´e Mbed TLS LibreSSL pˇrep´ınaˇc knihovny

4.4 Filtrov´an´ıpˇrijat´ych poˇzadavk˚u

Pˇripouˇzit´ıHTTPS spojen´ıumoˇzˇnujepˇredchoz´ıbakal´aˇrsk´apr´acefiltrovat pa- kety pˇrijat´eod webov´ehoserveru vˇcetnˇejejich HTTP hlaviˇcek.Pr´aceovˇsem umoˇzˇnujejen ˇc´asteˇcn´efiltrov´an´ıHTTP hlaviˇceku pˇr´ıchoz´ıch poˇzadavk˚u,po- kud jsou pˇrijaty pˇresHTTPS spojen´ı.V bakal´aˇrsk´epr´acitotiˇzz˚ustalzachov´an bez vˇetˇs´ıch ´uprav mechanismus zpracov´avaj´ıc´ıpˇrijat´epoˇzadavky od klienta. Tento mechanismus umoˇzˇnuje filtrovat veˇsker´eHTTP hlaviˇckypˇrijat´epˇres nezabezpeˇcen´espojen´ı,ale pˇripouˇzit´ıHTTPS se komunikace s klientem liˇs´ı a pro filtrov´an´ıvˇsech pˇrijat´ych hlaviˇcekjsou nutn´erozs´ahlejˇs´ızmˇeny.

4.4.1 Zpracovan´ıHTTP poˇzadavku samostatnou funkc´ı

P˚uvodn´ıimplementace Privoxy jiˇzobsahuje nˇekolik funkc´ı,kter´epˇripostup- n´emvol´an´ıumoˇzˇnuj´ıpˇrijmouta zpracovat HTTP hlaviˇckuklientova poˇzada- vku. Dvˇenejd˚uleˇzitˇejˇs´ıfunkce pro pˇrijet´ıpoˇzadavku jsou:

• receive client request Funkce zabezpeˇcujepˇrij´ım´an´ıdat od klienta tak, aby byl pˇrijatvˇzdy cel´ypoˇzadavek. N´aslednˇeprov´ad´ıkontrolu pˇrijat´ehopoˇzadavku. Proto- kol pˇrijat´ehopoˇzadavku mus´ıb´ytproxy serverem podporov´ana struk- tura poˇzadavku mus´ıodpov´ıdatpouˇzit´emu protokolu. N´aslednˇeje prvn´ı ˇr´adkaHTTP poˇzadavku rozdˇelenana jednotliv´eparametry jako je verze protokolu, metoda poˇzadavku, url adresa a port. Zbytek poˇzadavku je rozdˇelenpo jednotliv´ych ˇr´adk´ach.

• parse client request Funkce podle pˇrijat´ehopoˇzadavku nastavuje hodnoty promˇenn´ych, s je- jichˇzpomoc´ıse ˇr´ıd´ıpr˚ubˇehzpracov´an´ıpoˇzadavku i odpovˇedina nˇej. N´aslednˇena tento poˇzadavek aplikuje pˇr´ısluˇsn´efiltry, kter´eumoˇzˇnuj´ı upravit jeho HTTP hlaviˇcku i obsah.

45 4. Implementace

V p˚uvodn´ıverzi Privoxy doch´azelok pˇrijet´ıa zpracov´an´ıHTTP poˇzadavku pouze jednou pro kaˇzd´ypoˇzadavek klienta, tedy pouze na jednom m´ıstˇev k´odu. Jelikoˇzpro ´uˇcelfiltrov´an´ıHTTPS komunikace je nezbytn´enaˇcten´ıa parsov´an´ı poˇzadavku opakovanˇe,byla vytvoˇrenanov´afunkce process client request. Tato funkce sdruˇzujeveˇsker´efunkce pro zpracov´an´ıpoˇzadavku klienta do jed- noho celku. Vol´an´ım t´etofunkce lze opakovanˇenaˇc´ıtat poˇzadavky klienta. Z´aroveˇnje moˇzn´eupravit a doplnit p˚uvodn´ıfunkce na jednom jedin´emm´ıstˇe o dalˇs´ırozˇs´ıˇren´ıa pˇredch´az´ıse i duplicit´amv k´odu.Nahrazen´ırozs´ahlejˇs´ıch blok˚uk´oduz p˚uvodn´ıfunkce chat nav´ıctuto funkci v´yraznˇezkr´at´ıa zv´yˇs´ı tak jej´ıpˇrehlednost.

4.4.2 Zapouzdˇren´ıfunkc´ıpro zpracov´an´ıdat Existuj´ıc´ıfunkce pro pˇrij´ım´an´ı(respektive kontrolu dostupnosti) a odes´ıl´an´ı dat jsou v origin´aln´ıverzi Privoxy implementov´any pouze pro TCP spojen´ı. V bakal´aˇrsk´epr´acipak byly doplnˇeny ekvivalentn´ımifunkcemi pro TLS spo- jen´ı.Privoxy z´aroveˇnobsahuje ˇradu funkc´ıpro zpracov´an´ıpˇrijat´ych dat, kter´e jsou pˇrizp˚usobeny pouze pro TCP spojen´ı.V bakal´aˇrsk´epr´acibyly nˇekter´e z tˇechto funkc´ıch upraveny pro potˇreby TLS spojen´ı.Pro vˇsechna vol´an´ıfunkc´ı z´avisej´ıc´ıch na typu pouˇzit´ehospojen´ıtak byla vloˇzena if-else podm´ınka, kter´apodle typu vytvoˇren´ehospojen´ıvol´afunkci obsluhuj´ıc´ıtoto spojen´ı.Pro kaˇzd´epˇrij´ım´an´ıˇciodes´ıl´an´ıdat tedy byla vytvoˇrena podm´ınka typu: if (client_use_ssl(csp)) { ret= ssl_send_data(&(csp->ssl_client_attr.ssl), receive_buffer, len); if (ret<0){ ... } } else { ret= write_socket(csp->cfd, receive_buffer, len) if (ret<0){ ... } }

Pro filtrov´an´ıpoˇzadavk˚upˇrijat´ych pˇres zabezpeˇcen´eTLS spojen´ıje potˇre- ba vyuˇz´ıtnˇekter´ejiˇzexistuj´ıc´ıfunkce. Tyto funkce ovˇsemmus´ıb´ytpˇrizp˚uso- beny jak pro TCP spojen´ı,tak pro zabezpeˇcen´aTLS spojen´ı.Aby nebylo nutn´e nahrazovat vˇsechna vol´an´ıfunkc´ıpro komunikaci v´yˇseuvedenou podm´ınkou, byly vytvoˇreny nov´efunkce pro kaˇzdouz operac´ınad spojen´ım.Tyto funkce pˇrij´ımaj´ıstrukturu client state, kter´aobsahuje vˇsechny potˇrebn´epromˇenn´e pro komunikaci s klientem ˇciserverem pˇresexistuj´ıc´ıspojen´ıs n´ım,bez ohledu na typ tohoto spojen´ı.D´alefunkce pˇrij´ımaj´ıparametr typu int, pro kter´yjsou pˇreddefinov´anamakra CLIENT a SERVER, pˇr´ıpadnˇedalˇs´ıpotˇrebn´eparametry

46 4.4. Filtrov´an´ıpˇrijat´ych poˇzadavk˚u

Tabulka 4.2: V´ybˇerobsluhovan´ehospojen´ına z´akladˇeparametr˚u

C´ılkomunikace Klient Server Komunikace Komunikace TCP s klientem pˇres se serverem pˇres Typ nezabezpeˇcen´espojen´ı nezabezpeˇcen´espojen´ı spojen´ı Komunikace Komunikace TLS s klientem pˇres se serverem pˇres zabezpeˇcen´eTLS spojen´ı zabezpeˇcen´eTLS spojen´ı

jako je z´asobn´ık pro data a jeho d´elka.Volaj´ıc´ı tak funkci pˇred´apotˇrebn´e struktury a definuje, jestli m´afunkce ˇc´ıstdata od serveru ˇciklienta. Volan´a funkce pak sama na z´akladˇeparametr˚uvybere vhodnou funkci a pˇred´aj´ı potˇrebn´eparametry. Vˇsechny varianty, kter´efunkce bere v ´uvahu, jsou zobra- zeny v tabulce 4.2. D´ıkyzapouzdˇren´ıvˇsech p˚uvodn´ıch funkc´ıpro komunikaci mohly b´ytp˚u- vodn´ı if-else bloky ve zdrojov´em k´odunahrazeny tˇemito nov´ymifunk- cemi. To n´aslednˇeumoˇznilobez rozs´ahlejˇs´ıch ´uprav vyuˇz´ıtjiˇzexistuj´ıc´ıfunkce v Privoxy pro zpracov´an´ınezabezpeˇcen´ekomunikace, i pokud se jedn´ao za- bezpeˇcen´aspojen´ı.Pouˇzit´espojen´ıje zvoleno automaticky na z´akladˇepˇreda- n´ych parametr˚u.

4.4.3 Pˇrijet´ıHTTP hlaviˇckypˇreszabezpeˇcen´espojen´ı

P˚uvodn´ıverze proxy serveru Privoxy vyuˇz´ıv´apro zpracov´an´ıHTTPS komuni- kace tzv. tunel. Tato metoda je zn´azornˇenana obr´azku 4.1. Pokud klient v´ı,ˇze jeho komunikace je smˇerov´anana proxy server (tuto informaci z´ısk´az nasta- ven´ıwebov´ehoprohl´ıˇzeˇce,pˇr´ıpadnˇez nastaven´ıoperaˇcn´ıhosyst´emu), zahajuje komunikaci poˇzadavkem typu CONNECT. V nˇemuv´ad´ıpouˇz´ıvanou verzi pro- tokolu HTTP a poˇzadovanou url adresu. Ta m˚uˇzeobsahovat nejen c´ılovou dom´enu, ale i poˇzadovan´yprotokol, pˇr´ıpadnˇeport. Na z´akladˇetˇechto infor- mac´ıse proxy server pokus´ınav´azatTCP spojen´ıs c´ılov´ymserverem. Pokud je pouˇzitnadˇrazen´yproxy server, aplikuj´ıse na poˇzadavek CONNECT defino- van´efiltry a n´aslednˇeje pˇreposl´annadˇrazen´emu proxy serveru. Po ´uspˇeˇsn´em nav´az´an´ıTCP spojen´ıs c´ılov´ymserverem (respektive pot´e,co spojen´ıs c´ılo- v´ymserverem nav´aˇzenadˇrazen´yproxy server) je o tom klient informov´an. Veˇsker´an´asleduj´ıc´ıkomunikace mezi klientem a webov´ymserverem je proxy serverem jiˇzpouze pˇrepos´ıl´anave zn´azornˇen´esmyˇcce. Pokud klient vyˇzaduje zabezpeˇcen´espojen´ı, vytv´aˇr´ı toto spojen´ı pˇr´ımo s webov´ymserverem. Po nav´az´an´ı TLS spojen´ı jsou jiˇzveˇsker´apˇren´aˇsen´adata ˇsifrov´ana,a tak na nˇenem˚uˇzeproxy server aplikovat filtrov´an´ı.To se t´yk´ai n´aslednˇezaslan´eho

47 4. Implementace

Klient Proxy sever www.privoxy.org

Navázání TCP spojení

CONNECT www.privoxy.org:443 HTTP/1.1 Navázání TCP spojení HTTP/1.1 200 Connection established

Šifrovaná HTTPS komunikace - TLS tunel

Obr´azek4.1: Zpracov´an´ıHTTPS komunikace p˚uvodn´ımproxy serverem Pri- voxy pˇripouˇzit´ımetody TLS tunelu. Cern´eˇsipkyzn´azorˇnuj´ıTCPˇ spojen´ı, ˇcerven´azabezpeˇcen´eTLS spojen´ı.

poˇzadavku typu GET, kter´ymklient serveru specifikuje poˇzadovan´adata. Bakal´aˇrsk´apr´acetento pˇr´ıstupˇc´asteˇcnˇeupravila. Nahradila TLS tunel me- todou MITM. Princip t´etometody, tak jak byl implementovan´yv bakal´aˇrsk´e pr´aci,je zn´azornˇen´yna obr´azku4.2. Proxy server po pˇrijet´ıpoˇzadavku CON- NECT navazuje nejprve TCP spojen´ı a n´aslednˇei zabezpeˇcen´eTLS spojen´ı s poˇzadovan´ymwebov´ymserverem. Pot´einformuje klienta o ´uspˇeˇsn´emvy- tvoˇren´ıtohoto spojen´ı.Kdyˇzse klient n´aslednˇepokouˇs´ınav´azatTLS spojen´ı s webov´ymserverem, proxy server s´amvystupuje jako webov´yserver a nav´aˇze s klientem TLS spojen´ı.Pot´eklient zaˇslepoˇzadavek typu GET na konkr´etn´ı soubor. Proxy server uˇzovˇsemstejnˇejako u metody TLS tunelu ve smyˇcce okamˇzitˇepˇrepos´ıl´atento poˇzadavek webov´emu serveru. Neaplikuj´ıse na nˇej ˇz´adn´efiltry, jelikoˇzp˚uvodn´ıproxy server Privoxy poˇc´ıtals pˇrijet´ımpouze je- din´ehoHTTP poˇzadavku, kter´ymohl b´ytzpracov´an.Pˇripouˇzit´ıTLS tunelu jiˇzˇz´adn´ydalˇs´ıpoˇzadavek nebyl pro proxy server ˇciteln´ya nemohl jej tak zpra- covat. Pˇripouˇzit´ınezabezpeˇcen´ehoHTTP spojen´ıklient nezas´ıl´apoˇzadavek typu CONNECT, ale jiˇzprvn´ıpoˇzadavek je typu GET. Ten obsahuje i url adresu c´ılov´ehoserveru. Z´adn´ydalˇs´ıpoˇzadavekˇ nen´ıproxy serverem pˇrijat.P˚uvodn´ı verze Privoxy jiˇzimplementovala filtrov´an´ıdat pˇren´aˇsen´ych od webov´ehoser- veru, pokud byla pˇren´aˇsenapomoc´ınezabezpeˇcen´ehospojen´ı.V bakal´aˇrsk´e pr´acipak byla tato funkcionalita rozˇs´ıˇrenai na zabezpeˇcen´aspojen´ı,jelikoˇz nebyly potˇrebn´erozs´ahlejˇs´ı´upravy. Aby mohl b´ytfiltrov´ani druh´ypoˇzadavek zaslan´yklientem pˇripouˇzit´ı zabezpeˇcen´ehospojen´ı,je potˇrebajej nejdˇr´ıve naˇc´ıstdo pˇripraven´ych struk- tur. Proto byla funkce chat doplnˇenao druh´evol´an´ıfunkce process client- request po nav´az´an´ıTLS spojen´ıs klientem. Tak je zpracov´ani druh´yHTTP poˇzadavek od klienta. D´ıkypˇredchoz´ım´uprav´amfunkce sama zvol´ıpouˇz´ıvan´y

48 4.4. Filtrov´an´ıpˇrijat´ych poˇzadavk˚u

Klient Proxy sever www.privoxy.org

Navázání TCP spojení

CONNECT www.privoxy.org:443 HTTP/1.1 Navázání TCP spojení

Navázání TLS spojení HTTP/1.1 200 Connection established

Navázání TLS spojení

GET / HTTP/1.1 GET / HTTP/1.1

Aplikování HTTP/1.1 200 OK + data filtrů filtrované: HTTP/1.1 200 OK + data

Obr´azek 4.2: Zpracov´an´ı HTTPS komunikace proxy serverem Privoxy s rozˇs´ıˇren´ımimplementovan´ymv bakal´aˇrsk´epr´aci(pouˇzit´ımetody MITM). Cern´eˇsipkyzn´azorˇnuj´ıTCPˇ spojen´ı,ˇcerven´ezabezpeˇcen´aTLS spojen´ı.

typ spojen´ı. V tomto pˇr´ıpadˇetedy spojen´ı typu TLS. Hlaviˇckanaˇcten´eho poˇzadavku je vkl´ad´anado totoˇzn´estruktury jako pˇredchoz´ıpoˇzadavek typu CONNECT. Funkce ale v pˇr´ıpadˇenaˇc´ıt´an´ıdruh´ehopoˇzadavku v t´etostruktuˇre jen dopln´ıˇcipˇrep´ıˇse nˇekter´ez p˚uvodn´ıch hodnot v z´avislostina jejich typu. Parametry jako je pouˇzit´yport a adresa c´ılov´ehoserveru jsou beze zmˇeny uchov´any, jelikoˇzje nov´ypoˇzadavek neobsahuje. Obsahuje naopak relativn´ı cestu na poˇzadovan´ysoubor, tak jak je zn´azornˇenona obr´azku 4.2. Upra- ven´ı pˇredchoz´ıho poˇzadavku typu CONNECT je moˇzn´e,protoˇzenˇekter´ejeho parametry jiˇznejsou potˇreba,pˇr´ıpadnˇeje druh´ypoˇzadavek ani neobsahuje, a tak d´ıky ´upravˇefunkce get destination from headers nejsou pˇreps´any. Tento pˇr´ıstupumoˇzˇnujevyuˇz´ıtp˚uvodn´ıfunkce pro naˇc´ıt´an´ıpoˇzadavku bez rozs´ahlejˇs´ıch ´uprav. Na takto zpracovan´ypoˇzadavek jsou aplikov´any odpov´ıda- j´ıc´ıfiltry a poˇzadavek je pˇreposl´anwebov´emu serveru pˇres existuj´ıc´ızabezpeˇce- n´espojen´ı.Teprve pot´eje spuˇstˇenafunkce handle established connection, kter´av cyklu pˇrepos´ıl´adata pˇrijat´aod serveru a filtruje jejich obsah. Kom- pletn´ıpostup je zobrazen na obr´azku4.3.

4.4.4 Dalˇs´ızjednoduˇsen´ıa opravy

Aby byla i nad´alezachov´ana jednoduchost a pˇrehlednostzdrojov´ehok´odu, byly p˚uvodn´ırozs´ahl´efunkce rozdˇeleny do menˇs´ıch logick´ych celk˚u.Jednou z takov´ych ´uprav je vytvoˇren´ıfunkce create server connection pro nav´az´a- n´ıspojen´ıs webov´ymserverem. Tento celek byl p˚uvodnˇesouˇc´ast´ıfunkce chat.

49 4. Implementace

Klient Proxy sever www.privoxy.org

Navázání TCP spojení CONNECT www.privoxy.org:443 HTTP/1.1 Navázání TCP spojení Navázání TLS spojení HTTP/1.1 200 Connection established Navázání TLS spojení

GET / HTTP/1.1 Aplikování filtrované: GET / HTTP/1.1 filtrů

HTTP/1.1 200 OK + data Aplikování filtrované: HTTP/1.1 200 OK + data filtrů

Obr´azek 4.3: Zpracov´an´ı HTTPS komunikace proxy serverem Privoxy s rozˇs´ıˇren´ım implementovan´ymv diplomov´epr´aci. Cern´eˇsipkyzn´azorˇnuj´ıˇ TCP spojen´ı,ˇcerven´ezabezpeˇcen´eTLS spojen´ı.

Funkce obsahuje nejen samotn´enav´az´an´ıTCP a TLS spojen´ı,ale i veˇsker´a s nimi souvisej´ıc´ınastaven´ıpˇr´ısluˇsn´ych promˇenn´ych, postup pro nav´az´an´ıspo- jen´ıs nadˇrazen´ymproxy serverem, postup pro vytvoˇren´ıTLS tunelu, ˇciinfor- mov´an´ıklienta o neplatnosti certifik´atuc´ılov´ehoserveru. Nejen d´ıkytˇemto zjednoduˇsen´ımse podaˇrilov r´amcidiplomov´epr´aceod- halit i chybu v p˚uvodn´ıverzi Privoxy 3.0.28. Spoˇc´ıv´av pouˇz´ıv´an´ıneinicializo- van´epromˇenn´e csp->fwd ve funkci handle established connection. Tato promˇenn´aby mˇelaobsahovat parametry nadˇrazen´ehoproxy serveru, pokud je pouˇzit.Ve verzi 3.0.26 jiˇznebyla tato promˇenn´ainicializov´ana,nebyla vˇsak ani pouˇz´ıv´anaa m´ıston´ıse pˇr´ısluˇsn´eparametry vkl´adalydo lok´aln´ıpromˇenn´e fwd. Ve verzi 3.0.28 byla funkce chat obsahuj´ıc´ızm´ınˇenoulok´aln´ıpromˇennou rozdˇelenana dvˇesamostatn´efunkce. V nov´efunkci bylo pouˇzit´ıpromˇenn´e fwd nahrazeno promˇennou csp->fwd, jelikoˇz csp z´ısk´ajako parametr. Promˇenn´a csp->fwd ovˇsemst´alez˚ustalaneinicializov´ana.Tato chyba byla opravena.

4.5 Zmˇeny konfiguraˇcn´ıhorozhran´ı

Aby mohlo b´ytexistuj´ıc´ıkonfiguraˇcn´ırozhran´ıpro klienta dostupn´ei pomoc´ı zabezpeˇcen´ehospojen´ı(obr´azek4.4), je nezbytn´erozˇs´ıˇritjiˇzexistuj´ıc´ıfunkce, kter´etoto rozhran´ıposkytuj´ıpouze pˇres nezabezpeˇcen´espojen´ı.Z´aroveˇnje nutn´edoplnit algoritmus pro zpracov´an´ıpoˇzadavku klienta o nov´emoˇznosti.

50 4.5. Zmˇeny konfiguraˇcn´ıho rozhran´ı

Obr´azek 4.4: C´astˇ konfiguraˇcn´ıho rozhran´ı Privoxy z´ıskan´a pomoc´ı za- bezpeˇcen´ehospojen´ı.

4.5.1 Odchycen´ıHTTPS poˇzadavk˚una konfiguraˇcn´ırozhran´ı Po pˇrijet´ıpoˇzadavku od klienta proxy server kontroluje, jestli m´ab´yttento poˇzadavek zpracov´anpˇr´ımoproxy serverem, nebo jestli m´ab´ytpˇreposl´anna webov´yserver. Jelikoˇzp˚uvodn´ıproxy server umoˇzˇnujeodchytit a zpracovat pouze poˇzadavky pˇrijat´epˇresnezabezpeˇcen´espojen´ı,m˚uˇzeokamˇzitˇegenero- vat odpovˇed’ na z´akladˇepoˇzadavku. Prvn´ıpˇrijat´ypoˇzadavek pˇripouˇzit´ıproto- kolu HTTPS je ovˇsemtypu CONNECT, a tak z nˇejlze z´ıskatpouze poˇzadovanou dom´enu, protokol a port. Proto m˚uˇzeproxy server pouze detekovat skuteˇcnost, ˇzedotaz nebude pˇrepos´ıl´anale bude zodpovˇezenpˇr´ımoproxy serverem. Kom- pletn´ıinformace z´ısk´aovˇsemaˇzz druh´ehodotazu pˇrijat´ehopˇresTLS spojen´ı. Kv˚ulizm´ınˇen´ymrozd´ıl˚ummezi zabezpeˇcen´yma nezabezpeˇcen´ymspojen´ım musel b´ytupraven p˚uvodn´ızp˚usobzpracov´an´ıpoˇzadavk˚u.Pokud proxy se- ver na z´akladˇepoˇzadavku zjist´ı,ˇzepro poˇzadovanou dom´enu bude generovat odpovˇed’ on s´am,postupuje n´asledovnˇepodle typu spojen´ı:

• Nezabezpeˇcen´espojen´ı Odpovˇed’ je vygenerov´anaa odesl´anaklientovi okamˇzitˇe,jelikoˇzveˇsker´e potˇrebn´einformace jsou k dispozici.

• Zabezpeˇcen´espojen´ı Proxy server pokraˇcujeobvykl´ymzp˚usobem s t´ımrozd´ılem,ˇzese ne- pokouˇs´ınav´azatspojen´ıs poˇzadovan´ymwebov´ymserverem. Klientovi ovˇsem odeˇsle zpr´avu 200 Connection established. N´aslednˇeklient zas´ıl´adruh´ypoˇzadavek, kter´ymspecifikuje zb´yvaj´ıc´ıparametry. Na je- jich z´akladˇem˚uˇzeproxy sever vygenerovat odpovˇed’ a odeslat ji klientovi.

51 4. Implementace

P˚uvodn´ıfunkce crunch response triggered pro rozhodnut´ıo odchycen´ı poˇzadavku, generov´an´ı a odesl´an´ı odpovˇedibyla doplnˇenafunkc´ı should- trigger crunch response. Ta rozhodne o odchycen´ıpoˇzadavku, a na z´akladˇe parametru prepare rsp vygeneruje konkr´etn´ıodpovˇed’ na poˇzadavek. Tato funkce je pak vol´anabud’to samostatnˇe,nebo z p˚uvodn´ı funkce crunch- response triggered, jej´ıˇzchov´an´ıje zachov´ano,tedy vˇzdyz´aroveˇnvyge- neruje a odeˇsle odpovˇed’.

4.5.2 Zmˇena ˇsablonkonfiguraˇcn´ıch webov´ych str´anek Pro korektn´ıchov´an´ıkonfiguraˇcn´ıhorozhran´ıovˇsemnestaˇciloupravit postup zpracov´an´ıpoˇzadavk˚u.To samotn´esice umoˇzn´ız´ıskatpomoc´ızabezpeˇcen´eho spojen´ıwebovou str´ankuvytvoˇrenou proxy serverem. Pokud by ovˇsemodkazy v tˇechto str´ank´ach i nad´aleodkazovaly na nezabezpeˇcen´aspojen´ı, uˇzivatel by pˇriprvn´ıpouˇzit´ılibovoln´ehoodkazu pˇreˇselopˇetna nezabezpeˇcen´espo- jen´ı.Proto musely b´ytupraveny i veˇsker´efunkce vytv´aˇrej´ıc´ıobsah webov´ych str´anek.Pro tento ´uˇcelbyly funkce doplnˇeny o nov´yparametr, na jehoˇz z´akladˇese funkce dozv´ı,pˇres jak´ytyp spojen´ıbude vygenerovan´yobsah pˇren´a- ˇsen,a tedy jak´yprotokol m´ab´ytspecifikovan´yu jednotliv´ych odkaz˚u.Odkazy tak dopln´ıprefixem http://“ nebo https://“. ” ” 4.6 Opakovan´epouˇz´ıv´an´ıTLS sessions

Aby nedoch´azeloke zbyteˇcn´emu navazov´an´ıa ukonˇcov´an´ıTLS spojen´ımezi vyˇrizov´an´ımjednotliv´ych poˇzadavk˚uklienta, je nutn´etato spojen´ıuchovat i po odbaven´ıpoˇzadavku, pro kter´ybyla vytvoˇrena.D´ıkytomu m˚uˇzeb´ytspojen´ı s klientem vyuˇzitoi pro pˇrijet´ıdalˇs´ıhopoˇzadavku na totoˇzn´ywebov´yserver, a n´aslednˇelze znovu vyuˇz´ıti existuj´ıc´ıspojen´ıs webov´ymserverem. V´ysledn´y efekt je zn´azornˇenna obr´azku4.5. Oproti p˚uvodn´ımu ˇreˇsen´ıbakal´aˇrsk´epr´ace zobrazen´emu na obr´azku3.2 je patrn´e,ˇzepˇriopakovan´empouˇz´ıv´an´ıTLS spo- jen´ıjsou m´ıstop˚uvodn´ıch ˇsestiTLS spojen´ıvytv´aˇrenapouze ˇctyˇri(uveden´e hodnoty plat´ıpro konkr´etn´ıwebovou str´anku www.privoxy.org). Nejdˇr´ıve je od klienta pˇrijatpoˇzadavek CONNECT. Podle nˇejproxy server vytvoˇr´ıprvn´ıTLS spojen´ı.Pot´eje s klientem nav´az´anodruh´eTLS spojen´ı.Pˇres tato dvˇespojen´ı je vyˇr´ızenklient˚uvpoˇzadavek na prvn´ıdokument. Klient zpracuje pˇrijat´adata a vyˇzadujedalˇs´ıdva soubory z totoˇzn´ehowebov´ehoserveru. Prvn´ıpoˇzadavek zas´ıl´apˇresjiˇzexistuj´ıc´ıTLS spojen´ı,kter´ebylo pro tento ´uˇcel uchov´ano.Spo- jen´ıje v ten okamˇzikplnˇevyuˇzito,a pokud klient nepodporuje zas´ıl´an´ıv´ıce poˇzadavk˚upˇredobdrˇzen´ımodpovˇedina pˇredchoz´ı(v´ychoz´ıchov´an´ıvˇetˇsiny modern´ıch webov´ych prohl´ıˇzeˇc˚u),nem˚uˇzeb´ytv tu chv´ıli pouˇzito pro dalˇs´ı poˇzadavky. Zas´ıl´an´ınˇekolika poˇzadavk˚upˇredobdrˇzen´ımodpovˇedina prvn´ı z nich se naz´yv´apipelining, kter´yproxy server Privoxy nepodporuje ani v nej- novˇejˇs´ı verzi (pouze umoˇzˇnuje jeho tolerov´an´ı, ale ani tuto moˇznostnedo- poruˇcuje).Klient tedy zas´ıl´anov´ypoˇzadavek CONNECT, podle kter´ehoproxy

52 4.6. Opakovan´epouˇz´ıv´an´ıTLS sessions

Klient Proxy sever www.privoxy.org

CONNECT www.privoxy.org:443 HTTP/1.1 GET / HTTP/1.1 GET / HTTP/1.1 HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data /

GET /p_doc.css HTTP/1.1 CONNECT www.privoxy.org:443 HTTP/1.1 GET /p_doc.css HTTP/1.1 GET /favicon.ico HTTP/1.1 HTTP/1.1 200 OK + data /p_doc.css HTTP/1.1 200 OK + data /p_doc.css GET /favicon.ico HTTP/1.1 HTTP/1.1 200 OK + data /favicon.ico HTTP/1.1 200 OK + data /favicon.ico

Obr´azek4.5: Princip opakovan´eho pouˇz´ıv´an´ızabezpeˇcen´ych spojen´ı.Kaˇzd´a barva pˇredstavuje samostatn´eTLS spojen´ı.

server vytvoˇr´ınov´eTLS spojen´ı(celkovˇejiˇztˇret´ı).N´aslednˇeje vytvoˇrenonov´e TLS spojen´ıs klientem, pˇreskter´eklient m˚uˇze zaslat poˇzadavek na konkr´etn´ı dokument. Ten mu je obratem doruˇcen.Celkem jsou tedy vytvoˇrenaˇctyˇriTLS spojen´ıpro z´ısk´an´ıtˇr´ısoubor˚u.Tato spojen´ız˚ustanouotevˇren´ai po pˇrenesen´ı vˇsech poˇzadovan´ych dokument˚u,a tak mohou b´ytopˇetovnˇevyuˇzita,dokud nevyprˇs´ıˇcasov´ylimit keep-alive-timeout nastaven´yv konfiguraˇcn´ımsou- boru config. D´ıkytomu m˚uˇzeklient n´aslednˇeodeslat dva souˇcasn´epoˇzadavky na totoˇzn´ywebov´yserver, aniˇzby se vytv´aˇrelonov´espojen´ı.To pˇrin´aˇs´ıdalˇs´ı zrychlen´ıpˇrivyˇrizov´an´ıpoˇzadavk˚uklienta.

4.6.1 Zvolen´yprincip

Pro opakovan´evyuˇzit´ı TLS sessions je moˇzn´ezvolit nˇekolik postup˚u.Zde jsou pops´any dva moˇzn´epˇr´ıstupy, z nichˇzjeden byl implementov´anv r´amci diplomov´epr´ace:

1. Obnova spojen´ıpomoc´ısession ID BˇehemTLS handshake pˇrivytv´aˇren´ınov´ehospojen´ımezi klientem a we- bov´ymserverem jsou vyjedn´av´any parametry session. Ty obsahuj´ımimo kryptografick´ych parametr˚ui tzv. session ID (pˇr´ıpadnˇesession tiket ˇci PSK v z´avislostina verzi TLS). Pokud je n´aslednˇetoto TLS spojen´ı ukonˇceno,m˚uˇzeklient pˇridalˇs´ımnavazov´an´ıTLS spojen´ıvyuˇz´ıttoto session ID k obnoven´ıpˇredchoz´ısession. Staˇc´ı,aby vloˇzilna zaˇc´atkuTLS handshake do Client Hello zpr´avysession ID z pˇredchoz´ıhospojen´ı. Server n´aslednˇeovˇeˇr´ı,ˇzepˇrijat´esession ID odpov´ıd´anˇekter´ez pˇred-

53 4. Implementace

choz´ıch sessions a rozhodne o pˇrijet´ıˇcizam´ıtnut´ıpoˇzadavku na obno- ven´ı session. Pokud je poˇzadavek serverem pˇrijat, jsou pro TLS spo- jen´ıpouˇzity totoˇzn´ekryptografick´eparametry jako v pˇredchoz´ımspo- jen´ıa nemus´ıtak b´ytprov´adˇenavelk´aˇc´asthandshake. T´ımdoch´az´ıke znaˇcn´e´uspoˇreˇcasupro nav´az´an´ıspojn´ı.Pokud sever zam´ıtnepoˇzadavek na obnoven´ısession, probˇehneklasick´yhandshake.[6]

2. Uchov´an´ıaktivn´ıhospojen´ı Alternativn´ımpˇr´ıstupem m˚uˇzeb´ytuchov´an´ıspojen´ıi po vyˇr´ızen´ıpoˇza- davku klienta. Nedojde tak u uzavˇren´ıTLS spojen´ı.Spojen´ıst´aleexis- tuje, pouze nen´ıaktivnˇevyuˇz´ıv´ano.K ukonˇcen´ıTLS spojen´ıdoch´az´ı pomoc´ıupozornˇen´ıtypu close notify. Tato zpr´ava m˚uˇze b´ytzasl´ana libovolnou stranou a upozorn´ı pˇr´ıjemce,ˇzeprotˇejˇs´ı strana jiˇznebude zas´ılatpˇresspojen´ıˇz´adn´adalˇs´ıdata. Protˇejˇs´ıstrana mus´ıpo obdrˇzen´ı close notify zpr´avyodeslat totoˇznouzpr´avuprotˇejˇs´ıstranˇe.Nen´ıvˇsak nutn´e,aby protˇejˇs´ıstrana pˇreduzavˇren´ımspojen´ına tuto zpr´avuˇcekala. Dokud tedy nen´ıpˇrijata close notify zpr´ava, m˚uˇzeb´ytTLS spojen´ı st´alevyuˇz´ıv´anok zabezpeˇcen´emu pˇrenosudat.[6]

Z tˇechto dvou metod byl v t´etodiplomov´epr´aciimplementov´andruh´y z pˇr´ıstup˚u,kter´yuchov´av´aaktivn´ıspojen´ı.Aˇckoli je jednou z jeho nev´yhod napˇr´ıkladnutnost uchov´avat vˇetˇs´ımnoˇzstv´ıdat v pamˇetiproxy serveru oproti prvn´ımetodˇe,zvolen byl zejm´enaz n´asleduj´ıc´ıch d˚uvod˚u:

• Prodlevy mezi jednotliv´ymipoˇzadavky klienta na proxy server jsou velmi mal´e.Nejˇcastˇejiod nˇekolika des´ıtekmilisekund do des´ıteksekund. Spo- jen´ı je tedy vyuˇz´ıv´anovelmi ˇcastoa nehroz´ı jeho ukonˇcen´ı ze strany webov´ehoserveru.

• Pokud nen´ıspojen´ıukonˇceno,doch´az´ık jeˇstˇevˇetˇs´ı´uspoˇreˇcasupˇrijeho opakovan´empouˇzit´ıi v porovn´an´ıse zkr´acen´ymhandshake.

• V porovn´an´ıs obnovou spojen´ıpomoc´ısession ID je toto ˇreˇsen´ım´enˇe sloˇzit´e.

4.6.2 Spr´ava stavu TLS spojen´ı

Aby mohl b´ytalgoritmus pro zpracov´an´ıdat od klienta i webov´ehoserveru pˇrizp˚usoben pro uchov´an´ıaktivn´ıch spojen´ıi pro dalˇs´ıpoˇzadavky, je nezbytn´e m´ıt v kaˇzd´emokamˇzikupˇrehled o stavu vˇsech tˇechto spojen´ı, respektive o tom, jak m´ab´ytse spojen´ımizach´azeno.Proto byla struktura client state, kter´aobsahuje veˇsker´einformace vl´aknazpracov´avaj´ıc´ıhopoˇzadavky klienta, rozˇs´ıˇrenao promˇennou ssl flags. Ta je vyuˇz´ıv´anajako bin´arn´ımapa, kde jednotliv´ebity specifikuj´ıtyto vlastnosti:

54 4.6. Opakovan´epouˇz´ıv´an´ıTLS sessions

• 0x01U = CSP SSL FLAG SERVER CONNECTION REUSED TLS spojen´ıs webov´ymserverem (pˇr´ıpadnˇenadˇrazen´ymproxy serve- rem) je jiˇzvyuˇz´ıv´anoopakovanˇe.

• 0x02U = CSP SSL FLAG CLIENT CONNECTION REUSED TLS spojen´ıs klientem je jiˇzvyuˇz´ıv´anoopakovanˇe.

• 0x04U = CSP SSL FLAG CONNECTIONS TO BE REUSED TLS spojen´ı s klientem i webov´ymserverem nemaj´ı b´ytpo vyˇr´ızen´ı poˇzadavku uzavˇrena,aby mohlo doj´ıtk jejich opˇetovn´emu vyuˇzit´ı.

• 0x08U = CSP SSL FLAG SERVER CONNECTION TAINTED TLS spojen´ıs webov´ymserverem mus´ıb´ytuzavˇreno,jelikoˇzm˚uˇze ob- sahovat neoˇcek´avan´adata.

• 0x10U = CSP SSL FLAG CLOSE SERVER CONNECTION TLS spojen´ıs webov´ymserverem mus´ıb´ytuzavˇrenopro nespecifikovan´y d˚uvod.

4.6.3 Pˇrijmut´ıpoˇzadavku pˇresopˇetovnˇepouˇzit´espojen´ı Aby mohly b´ytaplikov´any filtry i na poˇzadavky klienta pˇrijat´epˇreszabezpeˇce- n´espojen´ı,byl upraven postup pro zpracov´an´ıpˇrijat´ych poˇzadavk˚u,jak je pops´anov sekci 4.4.3. Pˇriopˇetovn´emvyuˇz´ıv´an´ıTLS spojen´ıovˇsem doch´az´ı k dalˇs´ımzmˇen´am.Prvn´ıpoˇzadavek po nav´az´an´ıTCP spojen´ıje typu CONNECT. V nˇemje definov´anc´ılov´yserver a typ poˇzadovan´ehospojen´ı.Podle tˇechto parametr˚uproxy server vytvoˇr´ı pˇr´ısluˇsn´eTLS spojen´ı s c´ılov´ymserverem. Pot´eje vytvoˇrenoTLS spojen´ıi s klientem. Klient n´aslednˇezas´ıl´adotazy na jednotliv´eprvky webov´estr´anky. Pokud je ovˇsemTLS spojen´ıvyuˇz´ıv´anoopa- kovanˇe,nen´ıpotˇrebajej znovu vytv´aˇret, a tud´ıˇzklient jiˇznezas´ıl´apoˇzadavek typu CONNECT, ale rovnou zaˇslepoˇzadavek na specifick´ysoubor. Rozd´ıl je zn´azornˇen´yna obr´azku4.6. Z obr´azkuje rovnˇeˇzpatrn´e,ˇzepoˇzadavek typu GET na konkr´etn´ısoubor jiˇzneobsahuje celou url adresu, ale jen relativn´ıcestu k poˇzadovan´emu souboru. Na z´akladˇeuveden´epromˇenn´e ssl flags tak byl upraven postup pro zpra- cov´an´ıpˇrijat´ych poˇzadavk˚u.Pokud proxy server pˇrij´ım´aprvn´ıpoˇzadavek pˇres TCP spojen´ıa jedn´ase o poˇzadavek typu CONNECT, nav´aˇzepoˇzadovan´espo- jen´ı a oˇcek´av´ajeˇstˇejeden poˇzadavek na konkr´etn´ı soubor. Pokud je vˇsak poˇzadavek pˇrijat´ypˇres jiˇzexistuj´ıc´ıTLS spojen´ı,oˇcek´av´ase, ˇzejiˇzbude spe- cifikovat konkr´etn´ısoubor. Z´adn´ydalˇs´ıpoˇzadavekˇ jiˇznen´ıaˇzdo vyˇr´ızen´ıpr´avˇe pˇrijat´ehopoˇzadavku pˇrij´ım´an. Proxy server nav´ıci nad´alepodporuje p˚uvodn´ı postup, kter´yje vyuˇz´ıv´an,pokud spr´avce proxy serveru poˇzadujepro vybran´e url adresy pouˇz´ıtTLS tunel.

55 4. Implementace

Klient Proxy sever Klient Proxy sever

Bez opětovného využívání S opětovným využívání TLS spojení TLS spojení

CONNECT www.privoxy.org:443 HTTP/1.1 CONNECT www.privoxy.org:443 HTTP/1.1

GET / HTTP/1.1 GET / HTTP/1.1

CONNECT www.privoxy.org:443 HTTP/1.1 GET /p_doc.css HTTP/1.1

GET /p_doc.css HTTP/1.1

Obr´azek4.6: Pˇrij´ım´an´ıpoˇzadavk˚ubez a s opˇetovn´ymvyuˇz´ıv´an´ımTLS spojen´ı

4.6.4 Vytv´aˇren´ıspojen´ıs c´ılov´ymserverem

Funkce create server connection pro nav´az´an´ıspojen´ıs poˇzadovan´ymwe- bov´ymserverem dosud vytv´aˇrelavˇzdynov´eTLS spojen´ı, pokud ho klient vyˇzadoval. Veˇsker´eparametry vytvoˇren´ehoTLS spojen´ıpak funkce vkl´ad´ado struktury typu ssl connection attr, kter´aje uloˇzenave struktuˇre client- state. Tu obsahuje kaˇzd´evl´aknoobsluhuj´ıc´ıkonkr´etn´ıhoklienta. Pokud m´ab´ytTLS spojen´ıopˇetovnˇevyuˇz´ıv´ano,je potˇrebanovˇevytvoˇren´e TLS spojen´ıpo vyˇr´ızen´ıpoˇzadavku neuzav´ırat.Toho je dosaˇzenonastaven´ım odpov´ıdaj´ıc´ıch hodnot v promˇenn´e ssl flags. Ta je kontrolov´anapˇrikaˇzd´em vol´an´ıfunkce pro uzavˇren´ıTLS spojen´ı.Pokud je pak vol´anafunkce create- server connection, a z´aroveˇnexistuje jiˇzvytvoˇren´eTLS spojen´ı,mus´ıb´yt ovˇeˇreno,ˇzeexistuj´ıc´ıspojen´ıje st´alepˇripraveno k pouˇzit´ıa z´aroveˇnˇzeod- pov´ıd´apoˇzadavk˚umklienta. K ovˇeˇren´ı,ˇzeTLS spojen´ınebylo neˇcekanˇeuzavˇrenoprotˇejˇs´ıstranou slouˇz´ı novˇevytvoˇren´afunkce connection is still alive. Ta, pokud je vyuˇz´ıv´ano zabezpeˇcen´espojen´ı,nejdˇr´ıve kontroluje, ˇzeod protˇejˇs´ıstrany nebyla pˇrijata zpr´ava typu close notify. Pokud tomu tak nen´ı,nebo pokud bylo vytvoˇreno jen nezabezpeˇcen´eTCP spojen´ı,je n´aslednˇekontrolov´anoi TCP spojen´ıpo- moc´ıp˚uvodn´ıfunkce socket is still alive. Pot´ejsou porovn´any parame- try existuj´ıc´ıhospojen´ıs parametry, kter´epoˇzadoval klient v poˇzadavku typu CONNECT. Tato kontrola byla doplnˇenai o porovn´an´ıtypu spojen´ı,tedy jestli se jedn´ao zabezpeˇcen´eTLS spojen´ı.Takov´akontrola nen´ısice nezbytn´apro opa- kovan´epouˇz´ıtTLS spojen´ı,protoˇzeby nemˇelodoj´ıtke zmˇenˇepoˇzadovan´ych parametr˚umezi jednotliv´ymipoˇzadavky. Nezbytn´aje ovˇsempro nezabezpeˇce- n´aspojen´ıi pokud jsou TLS session sd´ıleny mezi jednotliv´ymivl´akny. Jestliˇzetedy parametry spojen´ıodpov´ıdaj´ıa spojen´ınebylo neoˇcek´avanˇe uzavˇrenoprotˇejˇs´ıstranou, m˚uˇzeb´ytproces navazov´an´ınov´ehospojen´ıs c´ılo- v´ymserverem vynech´an.Pokud by parametry spojen´ıneodpov´ıdalypoˇzadav-

56 4.6. Opakovan´epouˇz´ıv´an´ıTLS sessions k˚um,pˇr´ıpadnˇepokud bylo spojen´ıneoˇcek´avanˇeukonˇceno,proxy server zaˇsle vlastn´ı close notify zpr´avu.M´ıstop˚uvodn´ıhouzavˇren´ehospojen´ın´aslednˇe vytvoˇr´ınov´e,kter´em˚uˇzeb´ytpouˇzitopro vyˇr´ızen´ıpoˇzadavku klienta.

4.6.5 Zpracov´an´ıpoˇzadavk˚una konfiguraˇcn´ırozhran´ı Aˇckoliv byl proxy server jiˇzpˇrizp˚usoben pro zpracov´an´ıHTTPS poˇzadavk˚una konfiguraˇcn´ırozhran´ı(sekce 4.5.1), opakovan´evyuˇz´ıv´an´ıTLS spojen´ıovlivˇnuje i zpracov´an´ıtˇechto poˇzadavk˚u.Pˇriopakovan´empouˇzit´ıTLS spojen´ıtotiˇzkli- ent nezas´ıl´apoˇzadavek typu CONNECT, kter´yse p˚uvodnˇeu dotaz˚una konfi- guraˇcn´ırozhran´ıpˇreszabezpeˇcen´espojen´ıvˇzdypˇredpokl´adal.Proto pokud je opakovanˇevyuˇz´ıv´anoTLS spojen´ıs klientem, pˇreskter´eklient ˇz´adalspojit s konfiguraˇcn´ıurl adresou, proxy server generuje pˇr´ısluˇsnouwebovou str´anku jiˇzpo pˇrijet´ıprvn´ıhopoˇzadavku.

4.6.6 Spolupr´aces nadˇrazen´ymproxy serverem D´ıkypouˇzit´emu principu pro opakovan´evyuˇz´ıv´an´ıTLS sessions, kter´yneu- konˇcujeTLS spojen´ıpo vyˇr´ızen´ıpoˇzadavku, iniciuje proxy server uzavˇren´ı TLS spojen´ıs klientem aˇzpo vyprˇsen´ıˇcasov´eholimitu Keep-Alive. Tento ˇcasov´ylimit definuje dobu, po kterou m´ab´ytudrˇzov´anovytvoˇren´eTCP spo- jen´ı.(Spojen´ıs webov´ymserverem uzav´ır´aproxy server ve stejn´yokamˇzik, pokud nebyla s webov´ymserverem vyjedn´anajin´ahodnota parametru Keep- -Alive, pˇr´ıpadnˇepokud nen´ıˇcasov´ylimit definov´anv konfiguraˇcn´ımsouboru proxy serveru.) TLS spojen´ıjsou tedy uzav´ır´anatˇesnˇepˇreduzavˇren´ımTCP spojen´ı.Z toho vypl´yvaj´ıurˇcit´aspecifika pˇripouˇzit´ınadˇrazen´eho proxy ser- veru, kter´ajsou d´ana rozd´ıln´ymiˇcasov´ymilimity Keep-Alive na obou proxy serverech. Obecnˇemohou nastat dva pˇr´ıpady.

1. Nadˇrazen´yproxy sever m´adelˇs´ıˇcasov´ylimit Keep-Alive Jak m˚uˇzemevidˇetna obr´azku4.7, pokud je ˇcasov´ylimit pro uzavˇren´ı spojen´ıdelˇs´ına nadˇrazen´emproxy serveru, nedoch´az´ık ˇz´adn´ymkom- plikac´ım.Prvn´ıproxy server po vyprˇsen´ıˇcasov´eho limitu uzavˇrespo- jen´ıs nadˇrazen´ymproxy serverem, a kdyˇzobdrˇz´ıdalˇs´ıpoˇzadavek na totoˇzn´yserver, opˇetjej vytvoˇr´ı.Nadˇrazen´yproxy server existuj´ıc´ıspo- jen´ı s webov´ymserverem uchov´av´a,a jelikoˇznov´ypoˇzadavek pˇrijde v ˇcasov´emlimitu, nemus´ı nadˇrazen´yproxy server spojen´ı obnovovat, ale okamˇzitˇevyuˇzijejiˇzexistuj´ıc´ı.

2. Nadˇrazen´yproxy server m´akratˇs´ıˇcasov´ylimit Keep-Alive Pokud je ˇcasov´ylimit pro uzavˇren´ıspojen´ına nadˇrazen´emproxy ser- veru kratˇs´ıneˇzna pˇredch´azej´ıc´ım,doch´az´ıke zkomplikov´an´ıcel´eho pro- cesu. Na obr´azku4.8 je zobrazeno, jak mus´ı proxy servery reagovat. Oba proxy servery po prvn´ım poˇzadavku vytvoˇr´ıTCP i TLS spojen´ı,

57 4. Implementace

Nadřazený Proxy sever www.privoxy.org proxy sever

CONNECT www.privoxy.org:443 HTTP/1.1

GET / HTTP/1.1 GET / HTTP/1.1

HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data / Keep-Alive timeout = 3 s Keep-Alive timeout = 1 s Uzavření TLS i TCP spojení

CONNECT www.privoxy.org:443 HTTP/1.1

GET / HTTP/1.1 GET / HTTP/1.1 HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data / Prodloužení timeout Keep-Alive timeout = 1 s

Obr´azek4.7: Opˇetovn´epouˇzit´ıTLS sessions s nadˇrazen´ymproxy serverem, kdy nadˇrazen´yproxy server m´adelˇs´ıˇcasov´ylimit

kter´apo vyˇr´ızen´ıpoˇzadavku uchov´avaj´ıaˇzdo uplynut´ıˇcasov´eholimitu. Nadˇrazen´yproxy server n´aslednˇeuzavˇrespojen´ınejen s c´ılov´ymserve- rem, ale i s pˇredchoz´ımproxy serverem. To znamen´a,ˇzepˇredch´azej´ıc´ımu proxy serveru zaˇsle close notify zpr´avu.Jelikoˇzpˇredch´azej´ıc´ıproxy server naslouch´apoˇzadavk˚umklienta, nedetekuje uzavˇren´ıtohoto spo- jen´ıa zjist´ıho aˇzve chv´ıli,kdy pˇrijdeod klienta dalˇs´ıpoˇzadavek typu GET na totoˇzn´yserver. V tu chv´ılizjist´ı,ˇzespojen´ıbylo nadˇrazen´ym proxy serverem uzavˇrenoa mus´ıb´ytznovu vytvoˇrenopomoc´ıpoˇzadavku CONNECT. Zbytek komunikace jiˇzprob´ıh´astandardn´ım zp˚usobem.

Probl´em ve druh´em pˇr´ıpadˇespoˇc´ıv´av tom, ˇze prvn´ı z proxy server˚u uchov´av´aaktivn´ı TLS spojen´ı s klientem i ve chv´ıli, kdy nadˇrazen´yproxy sever jiˇzuzavˇrel spojen´ıs webov´ymserverem i pˇredchoz´ımproxy serverem. Prvn´ız proxy server˚utak pˇrijmeod klienta poˇzadavek typu GET, ale protoˇze bylo n´asleduj´ıc´ıspojen´ıuzavˇreno,mus´ıjej obnovit. K tomu je nezbytn´eza- slat poˇzadavek typu CONNECT na nadˇrazen´yproxy server. Tento poˇzadavek ovˇsemnen´ıv tu chv´ıliod klienta k dispozici. V r´amcidiplomov´epr´acebyl tento probl´emˇreˇsenuloˇzen´ımcel´eho CONNECT poˇzadavku ze zaˇc´atkukomuni- kace s klientem, ovˇsemaˇzpo aplikov´an´ıpˇr´ıpadn´ych filtr˚u.Pokud tedy mus´ı b´ytspojen´ıs nadˇrazen´ymproxy serverem obnoveno, je k tomu pouˇzittento uloˇzen´ypoˇzadavek. Pot´eproxy server pokraˇcujestejn´ymzp˚usobem jako po vytvoˇren´ınov´ehoTLS spojen´ı. Pokud nen´ıpouˇzitnadˇrazen´yproxy server, k t´etokomplikaci nedoch´az´ı,

58 4.7. Sd´ılen´ıTLS sessions

Nadřazený Proxy sever www.privoxy.org proxy sever

CONNECT www.privoxy.org:443 HTTP/1.1

GET / HTTP/1.1 GET / HTTP/1.1

HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data / Keep-Alive timeout = 1 s Keep-Alive timeout = 3 s Odeslání zprávy close_notify Uzavření TLS i TCP spojení Přijetí dalšího požadavku GET od klienta na totožný webový server CONNECT www.privoxy.org:443 HTTP/1.1 GET / HTTP/1.1 GET / HTTP/1.1

HTTP/1.1 200 OK + data / HTTP/1.1 200 OK + data / Keep-Alive timeout = 1 s Keep-Alive timeout = 3 s

Obr´azek4.8: Opˇetovn´epouˇzit´ıTLS sessions s nadˇrazen´ymproxy serverem, kdy nadˇrazen´yproxy server m´akratˇs´ıˇcasov´ylimit

jelikoˇzproxy server po vyprˇsen´ıˇcasov´eholimitu odes´ıl´a close notify zpr´avu pˇr´ımoklientovi. Ten tak pˇred odesl´an´ımdalˇs´ıhopoˇzadavku zjist´ı,ˇzespojen´ı bylo uzavˇrenoa nav´aˇzes proxy serverem nov´e.

4.6.7 Pˇrizp˚usoben´ıknihovnˇeMbed TLS

Souˇc´ast´ıdiplomov´epr´aceje i podpora pro vyuˇzit´ınov´ych rozˇs´ıˇren´ıi s p˚uvodn´ı kryptografickou knihovnou Mbed TLS. Proto byly veˇsker´efunkce potˇrebn´epro opakovan´evyuˇz´ıv´an´ıTLS sessions implementov´any i s pouˇzit´ımt´eto knihovny. Uˇzivatel tak pˇrikompilaci s knihovnou Mbed TLS m˚uˇzetoto rozˇs´ıˇren´ıvyuˇz´ıt. Jelikoˇzs touto skuteˇcnost´ıbylo poˇc´ıt´anojiˇzbˇehemn´avrhu ´uprav, bylo vˇse navrˇzenotak, aby bylo v budoucnu moˇzn´ejednoduˇsenahradit p˚uvodn´ıkryp- tografick´eknihovny jakoukoli jinou. Staˇc´ıimplementovat s vyuˇzit´ımkonkr´etn´ı knihovny funkce z tabulky 4.3 tak, aby splˇnovaly velmi obecn´erozhran´ı.

4.7 Sd´ılen´ıTLS sessions

Aby bylo dosaˇzenojeˇstˇevˇetˇs´ıhozrychlen´ıbˇehemvyˇrizov´an´ıklientov´ych poˇza- davk˚u,implementuje diplomov´apr´acesd´ılen´ıTLS spojen´ımezi vl´akny. Tato vl´aknaobsluhuj´ıjednotliv´eklienty, a tak vytv´aˇr´ıi poˇzadovan´ytyp spojen´ı

59 4. Implementace

Tabulka 4.3: Funkce nezbytn´epro zaˇclenˇen´ınov´ekryptografick´eknihovny

Soubor N´azevfunkce [client|server] use ssl is ssl pending tunnel established successfully ssl [send|recv] data ssl send data delayed ssl flush socket ssl libressl.c ssl send certificate error ssl mbedtls.c create [client|server] ssl connection close client and server ssl connections close [client|server] ssl connection close ssl connection was connection closed by peer is server certificate valid

s c´ılov´ymiwebov´ymiservery. Spojen´ımezi sebou mohou n´aslednˇesd´ılet.P˚u- vodn´ı verze proxy serveru Privoxy jiˇzumoˇzˇnujesd´ılen´ı TCP spojen´ı mezi vl´akny. Toto p˚uvodn´ıˇreˇsen´ıbylo v r´amcidiplomov´epr´acepouˇzitojako z´aklad pro sd´ılen´ıexistuj´ıc´ıch TLS spojen´ı.

4.7.1 P˚uvodn´ısd´ılen´ıTCP spojen´ı Pro sd´ılen´ıexistuj´ıc´ıch TCP spojen´ıvyuˇz´ıv´ap˚uvodn´ıverze Privoxy pole fixn´ı velikosti 100 spojen´ı,kter´eje sd´ılen´emezi vˇsemivl´akny proxy serveru. Do nˇej jsou vkl´ad´any kromˇeTCP soketu i parametry popisuj´ıc´ıtoto spojen´ı(napˇr. dom´enov´ejm´eno,port, informace o nadˇrazen´emproxy serveru, . . . ) a para- metry pro spravov´an´ıtohoto spojen´ı.Mezi nˇemimo jin´epatˇr´ıˇcasov´ylimit Keep-Alive a ˇcas,kdy bylo spojen´ı naposledy aktivnˇeuˇz´ıv´ano.Posledn´ım d˚uleˇzit´yparametr ud´av´a,jestli je konkr´etn´ıspojen´ıaktu´alnˇevyuˇz´ıv´anonˇekte- r´ymz vl´aken. Pˇr´ıstup do tohoto pole je ˇr´ızenpomoc´ımutex˚u. Spojen´ıjsou do tohoto pole vkl´ad´ana ve dvou pˇr´ıpadech:

1. Novˇepˇrijat´ypoˇzadavek je urˇcen´ypro jin´ywebov´yserver neˇzpˇredchoz´ı Pˇripouˇzit´ınezabezpeˇcen´eho spojen´ıpro HTTP komunikaci zas´ıl´akli- ent v kaˇzd´emdotazu konkr´etn´ıdom´enov´ejm´eno.Poˇzadavek tedy m˚uˇze vypadat napˇr´ıkladtakto:

GET http://www.privoxy.org/ HTTP/1.1

D´ıky tomu m˚uˇzeb´ytkaˇzd´yz pˇr´ıchoz´ıch poˇzadavk˚uurˇcen´ypro jin´y webov´yserver, aniˇzby bylo spojen´ımezi klientem a webov´ymserverem

60 4.7. Sd´ılen´ıTLS sessions

uzavˇreno.Pokud je tedy nov´ypoˇzadavek urˇcenpro jin´ywebov´yserver neˇzpˇredchoz´ı,proxy server p˚uvodn´ıspojen´ıse serverem neuzavˇre,ale vloˇz´ıho do zmiˇnovan´ehopole sd´ılen´ych spojen´ı.Pro nov´ypoˇzadavek pak vytvoˇr´ıi nov´eTCP spojen´ı.Jelikoˇzpˇripouˇzit´ıTLS spojen´ıobsa- huje dom´enov´ejm´enopouze prvn´ıpoˇzadavek typu CONNECT, nem˚uˇzeb´yt z novˇepˇr´ıchoz´ıhopoˇzadavku zjiˇstˇenazmˇenac´ılov´ehoserveru, a tak ani nem˚uˇzeb´ytexistuj´ıc´ıTLS spojen´ıvloˇzenomezi sd´ılen´a. 2. Spojen´ıs klientem je uzavˇrenodˇr´ıve, neˇzvyprˇs´ıˇcasov´ylimit Keep-Alive spojen´ıs webov´ymserverem Po vyˇr´ızen´ıklientova poˇzadavku vl´aknozachov´av´aspojen´ıotevˇren´ea ˇce- k´ana dalˇs´ıpoˇzadavek. Pokud jej klient nezaˇsleve stanoven´emˇcasov´em limitu Keep-Alive, spojen´ı s klientem je uzavˇreno.Uzavˇren´ı spojen´ı m˚uˇzeiniciovat i klient, pokud v´ı,ˇzejiˇznebude cht´ıtzas´ılatdalˇs´ıpoˇzadav- ky. Pokud je spojen´ıs webov´ymserverem i pot´eaktivn´ıa neuplynul jeho stanoven´yˇcasov´ylimit Keep-Alive, m˚uˇze b´ytuloˇzeno pro dalˇs´ıpouˇzit´ı. V´ychoz´ı Keep-Alive limit pro webov´yserver m˚uˇzespr´avce proxy serveru nastavit v konfiguraˇcn´ımsouboru.

Kdyˇzn´aslednˇejin´evl´aknopˇrijmepoˇzadavek na spojen´ıs urˇcit´ymwebov´ym serverem, m˚uˇzenejdˇr´ıve zkontrolovat, jestli vhodn´espojen´ıjiˇznen´ıvytvoˇren´e ve sd´ılen´empoli. Pokud takov´espojen´ıexistuje, nen´ıvyuˇz´ıv´anojin´ymvl´aknem, je st´aleaktivn´ıa nevyprˇseljeho Keep-Alive ˇcasov´ylimit, nastav´ıu nˇejvl´akno pˇr´ıznak,ˇzeje jiˇzvyuˇz´ıv´anonˇekter´ymz aktivn´ıch vl´aken, a n´aslednˇeho vyuˇzije pro komunikaci s webov´ymserverem. Nemus´ıtak vytv´aˇretnov´espojen´ı,jehoˇz navazov´an´ıby zpomalilo cel´yproces vyˇrizov´an´ıklientova poˇzadavku. Pokud vl´aknopoˇzadavek vyˇr´ıd´ıa spojen´ıs klientem je uzavˇreno,opˇetnastav´ıpˇr´ıznak v poli sd´ılen´ych spojen´ı,ˇzeje k dispozici pro ostatn´ıvl´akna.Pokud je spo- jen´ı v pr˚ubˇehu komunikace uzavˇreno, odstran´ı ho pˇr´ısluˇsn´evl´aknoze se- znamu sd´ılen´ych spojen´ı.Pˇr´ıpadnˇejsou spojen´ı,u kter´ych vyprˇselˇcasov´ylimit, uzavˇrenav pr˚ubˇehu prohled´av´an´ısd´ılen´ehopole.

4.7.2 Spr´ava TLS parametr˚usd´ılen´ych spojen´ı Aby mohla b´ytsd´ılen´aspojen´ıvyuˇz´ıv´anai pokud jsou zabezpeˇcen´apomoc´ı protokolu TLS, je nezbytn´esd´ıletkromˇep˚uvodn´ıhosoketu i dalˇs´ıparametry nezbytn´epro pouˇzit´ıTLS vrstvy. Pro sd´ılen´ıtˇechto parametr˚uby mohl b´yt vytvoˇrensamostatn´ymechanismus. V r´amcidiplomov´epr´aceale bylo zvoleno rozˇs´ıˇren´ıp˚uvodn´ıhopostupu. Proto byly rozˇs´ıˇreny tˇrihlavn´ıfunkce pro spr´avu sd´ılen´ych spojen´ı:

• remember connection Tato funkce vkl´ad´anov´aspojen´ı do sd´ılen´ehopole. Aby mohly b´yt uloˇzeny i parametry t´ykaj´ıc´ı se TLS spojen´ı, byly pˇrid´any do struk- tury reusable connection, kter´aje v parametru t´etofunkce. Funkce

61 4. Implementace

tyto parametry zkop´ırujedo struktury uloˇzen´eve sd´ılen´empoli. Pokud ve sd´ılen´empoli nejsou ˇz´adn´avoln´am´ısta,pˇredan´espojen´ıje uzavˇreno, a to vˇcetnˇevrstvy TLS, pokud se jedn´ao zabezpeˇcen´espojen´ı. Novˇebyla funkce rozˇs´ıˇrena i o n´avratovou hodnotu. Podle n´ıvolaj´ıc´ı zjist´ı,jestli se podaˇrilospojen´ı´uspˇeˇsnˇeuloˇzit,pˇr´ıpadnˇejestli bylo funkc´ı uzavˇreno.Na z´akladˇen´avratov´ehodnoty tedy mohou b´ytnastaveny parametry o stavu ukl´adan´ehospojen´ı.

• close unusable connections Spojen´ı,kter´abyla uzavˇrenawebov´ymserverem, nebo kter´ymvyprˇsel ˇcasov´ylimit Keep-Alive jsou spravov´anatouto funkc´ı.Ta proch´az´ıpole sd´ılen´ych spojen´ı,a pokud jiˇznemohou b´ytpouˇzita,provede jejich ko- rektn´ıuzavˇren´ı.Proto byla p˚uvodn´ıfunkce pro kontrolu, jestli je TCP spojen´ıst´aleaktivn´ı,nahrazena funkc´ıkontroluj´ıc´ıi stav TLS spojen´ı. Z´aroveˇnbyla p˚uvodn´ıfunkce uzav´ıraj´ıc´ıTCP spojen´ıdoplnˇenafunkc´ı pro uzavˇren´ıTLS spojen´ı.

• get reusable connection Funkce proch´az´ıpole sd´ılen´ych spojen´ıa na z´akladˇepˇredan´ych para- metr˚uv nˇemhled´aodpov´ıdaj´ıc´ıspojen´ı.Aby mohla funkce v pˇr´ıpadˇe shody vr´atiti nezbytn´eparametry pro TLS komunikaci, byl mezi jej´ı parametry pˇrid´anukazatel na strukturu ssl connection attr.

D´ıkyzm´ınˇen´ym´uprav´amfunkc´ıpro spr´avusd´ılen´ych spojen´ıjiˇznejsou nutn´erozs´ahlejˇs´ı ´upravy algoritmu pro obsluhu klientov´ych poˇzadavk˚u.Al- goritmus byl doplnˇeno nastaven´ıpˇr´ıznak˚ut´ykaj´ıc´ıch se opˇetovnˇepouˇzit´eho TLS spojen´ına z´akladˇen´avratov´ych hodnot funkc´ıspravuj´ıc´ıch sd´ılen´aspo- jen´ı.Pˇrid´any byly tak´eobecn´efunkce pro uzavˇren´ısamostatn´ehoTLS spo- jen´ıa uvolnˇen´ıpamˇeti,kter´evyuˇz´ıvaj´ıstruktury obsahuj´ıc´ıparametry tohoto spojen´ı. P˚uvodn´ı ekvivalenty tˇechto funkc´ı byly pˇrizp˚usobeny vˇzdyspojen´ı s webov´ymserverem nebo s klientem.

4.8 Konfigurace ˇsifrov´ych sad

Privoxy vyuˇz´ıv´anˇekolik typ˚ukonfiguraˇcn´ıch soubor˚u.Pro pˇriˇrazen´ıakc´ık jed- notliv´ymurl adres´amˇciwebov´ymserver˚uslouˇz´ısoubory s pˇr´ıponou .action. Aby mohl uˇzivatel definovat vlastn´ıˇsifrovou sadu pro libovoln´ywebov´yserver, byla vytvoˇrenanov´aakce s kl´ıˇcov´ymslovem set-cipher-list. Parametrem tohoto kl´ıˇcov´ehoslova je ˇretˇezec,jehoˇzstruktura se liˇs´ıv z´avislostina pouˇzit´e kryptografick´eknihovnˇe.Na dalˇs´ıch ˇr´adk´ach za kl´ıˇcov´ymslovem je nezbytn´e uv´estseznam url adres webov´ych server˚u.Pro tyto servery bude zadan´aˇsifrov´a sada vyuˇz´ıv´ana.

62 4.8. Konfigurace ˇsifrov´ych sad

• Knihovna LibreSSL Uˇzivatel m˚uˇzepomoc´ıkl´ıˇcov´ych slov11 a speci´aln´ıch symbol˚udefinovat libovolnou podmnoˇzinu podporovan´ych algoritm˚u.Vyuˇzitom˚uˇzeb´yt kl´ıˇcov´eslovo DEFAULT, kter´epˇredstavuje v´ychoz´ıˇsifrovou sadu. Tuto sadu lze n´aslednˇeupravovat. Uk´azkovou hodnotou m˚uˇzeb´ytnapˇr´ıklad:

DEFAULT:!RC4:!MD5

• Knihovna Mbed TLS Retˇezecobsahujeˇ seznam kl´ıˇcov´ych slov12 definuj´ıc´ıch jednotliv´eˇsifrov´e sady. Kl´ıˇcov´aslova jsou oddˇelena znakem :“. Kaˇzd´az uveden´ych sad ” bude proxy serverem povolena. Uk´azkovou hodnotou m˚uˇzeb´ytnapˇr´ıklad:

TLS-RSA-WITH-AES-128-CBC-SHA:...

Pokud je zadan´yˇretˇezech chybn´y,dotˇcen´aspojen´ınejsou nav´az´anaa uˇzi- vatel je upozornˇenv logovac´ım souboru. U knihovny LibreSSL je zadan´y ˇretˇezecpˇred´anpˇr´ımoknihovn´ıfunkci. U knihovny Mbed TLS je ˇretˇezecrozdˇe- len na jednotliv´akl´ıˇcov´aslova, kter´ajsou pˇrevedena na pole odpov´ıdaj´ıc´ıch ˇc´ıseln´ych hodnot. To je d´alezpracov´anoknihovn´ıfunkc´ı.

11Kompletn´ıpˇrehledpodporovan´ych kl´ıˇcov´ych slov a syntaxe konfiguraˇcn´ıhoˇretˇezceje k dispozici na https://man.openbsd.org/SSL_set_cipher_list.3 12Kompletn´ı pˇrehled podporovan´ych kl´ıˇcov´ych slov je k dispozici na https:// tls.mbed.org/supported-ssl-ciphersuites

63

Kapitola 5

Testov´an´ıdosaˇzen´ychv´ysledk˚u

Implementovan´ezmˇeny jsou v t´etokapitole testov´any z nˇekolika r˚uzn´ych po- hled˚u.Z´aroveˇnjsou zde zhodnoceny dosaˇzen´ev´ysledky a naznaˇcenai vhodn´a budouc´ırozˇs´ıˇren´ı,kter´aby nav´azalana tuto diplomovou pr´aci.

5.1 Funkˇcnost

Novˇeimplementovan´arozˇs´ıˇren´ıbakal´aˇrsk´epr´ace´uspˇeˇsnˇeumoˇzˇnuj´ıfiltrovat veˇskerou pˇren´aˇsenouHTTPS komunikaci v obou smˇerech. Tedy nejen data pˇrijat´aod webov´ehoserveru jako pˇredchoz´ıbakal´aˇrsk´apr´ace, ale i data pˇrijat´a od klienta. Filtrovat lze pˇren´aˇsen´adata vˇcetnˇeHTTP hlaviˇcek,a to i pˇri pouˇzit´ınadˇrazen´ehoproxy serveru. K dispozici jsou tak uˇzivatel˚umveˇsker´e funkcionality pro filtrov´an´ı,kter´ejsou obsaˇzeny v p˚uvodn´ımPrivoxy verze 3.0.28, a to nejen pro protokol HTTP, ale i pro protokol HTTPS. Souˇc´ast´ıproveden´ych test˚ufunkˇcnostije i ovˇeˇren´ıpodpory bˇeˇzn´ych i neob- vykl´ych algoritm˚u,protokol˚ua nastaven´ızabezpeˇcen´ych spojen´ı.Pro ovˇeˇren´ı funkˇcnostibyly pouˇzity testy z webov´ych str´anek https://www.badssl.com, jejichˇzv´ysledkyjsou zobrazeny v tabulce 5.1. Z tabulky vypl´yv´a,ˇzeproxy ser- ver Privoxy podporuje veˇsker´etestovan´efunkcionality jako modern´ıwebov´e prohl´ıˇzeˇce.

5.1.1 Kryptografick´eknihovny

D´ıkypouˇzit´ınov´ekryptografick´eknihovny je moˇzn´evyuˇz´ıvat Privoxy se vˇsemi nejrozˇs´ıˇrenˇejˇs´ımimodern´ımiwebov´ymiprohl´ıˇzeˇci.Po nainstalov´an´ıvlastn´ıCA tyto prohl´ıˇzeˇceuˇzivatele nijak neupozorˇnuj´ına bezpeˇcnostn´ırizika. Byl tak odstranˇenjeden ze z´asadn´ıch nedostatk˚up˚uvodn´ıbakal´aˇrsk´epr´ace. Z´aroveˇn vˇsakbyla zachov´anakompatibilita s p˚uvodnˇepouˇzitoukryptografickou kni- hovnou Mbed TLS, vˇcetnˇejej´ıch v´yhod a nedostatk˚u.Uˇzivatel si tak m˚uˇzes´am zvolit kryptografickou knihovnu, kter´abude pˇrikompilaci pouˇzita.Z´aroveˇnje

65 5. Testovan´ ´ı dosaˇzenych´ vysledk´ ˚u

Tabulka 5.1: Srovn´an´ıPrivoxy a webov´ych prohl´ıˇzeˇc˚uv podpoˇrevybran´ych kryptografick´ych protokol˚ua algoritm˚u.(Ano – zpracuje, Ne – nezpracuje) Privoxy Privoxy Google Test Firefox16 Safari17 LibreSSL13 MbedTLS14 Chrome15 Neobvykl´e 1000-sans Ano Ne Ano Ano Ano 10000-sans Ne Ne Ne Ne Ne sha384 Ano Ano Ano Ano Ano sha512 Ano Ano Ano Ano Ano rsa8192 Ano Ano Ano Ano Ano no-subject Ano Ano Ano Ano Ano no-common-name Ano Ano Ano Ano Ano incomplete-chain Ano Ano Ano Ano Ano Bˇeˇzn´e tls-v1-2 Ano Ano Ano Ano Ano sha256 Ano Ano Ano Ano Ano rsa2048 Ano Ano Ano Ano Ano ecc256 Ano Ano Ano Ano Ano ecc384 Ano Ano Ano Ano Ano extended-validation Ano Ano Ano Ano Ano mozilla-modern Ano Ano Ano Ano Ano Upgrade hsts Ano Ano Ano Ano Ano upgrade Ano Ano Ano Ano Ano preloaded-hsts Ano Ano Ano Ano Ano https-everywhere Ne Ne Ne Ne Ne

uˇzivateli umoˇznˇenoprov´estkompilaci bez jak´ekoli kryptografick´eknihovny, tedy se stejn´ymifunkcionalitami jako p˚uvodn´ıPrivoxy verze 3.0.28.

5.2 V´ykonnost

Pˇriimplementaci nov´ych funkcionalit pro Privoxy byl kladen d˚urazi na v´ykon- nost proxy serveru. Implementov´anoproto bylo rozˇs´ıˇren´ıumoˇzˇnuj´ıc´ıopako- vanˇevyuˇz´ıvat vytvoˇren´aTLS spojen´ıs klienty i s webov´ymiservery. D´ıkytomu nemus´ıproxy server pro kaˇzd´epˇrijet´ıa vyˇr´ızen´ıdotazu navazovat nov´aTLS spojen´ı,ˇc´ımˇzje znaˇcnˇeurychleno vyˇrizov´an´ıˇradydotaz˚una jeden konkr´etn´ı webov´yserver. Zrychlen´ı je tedy patrn´ezejm´enau webov´ych str´anekob- sahuj´ıc´ıch vysok´ypoˇcet subresource ze spoleˇcn´eho webov´eho serveru. Po- rovn´an´ıdoby potˇrebn´epro naˇcten´ıvybran´ych webov´ych str´anekpˇrivyuˇzit´ı r˚uzn´ych metod implementovan´ych v jednotliv´ych verz´ıch proxy serveru Pri-

13LibreSSL verze 3.0.2 14Mbed TLS verze 2.16.6 15Google Chrome verze 81.0.4044.113 (64 bit˚u) 16Firefox verze 75.0 (64 bit˚u) 17Safari iPadOS 13.4.1

66 5.2. V´ykonnost

Obr´azek 5.1: Srovn´an´ı doby naˇc´ıt´an´ı vybran´ych webov´ych str´anek podle pouˇzit´emetody a poˇctujej´ıch subresources. Pouˇzit´yproxy server pro metody TLS tunel a TLS MITM je v´ystupem pˇredchoz´ıbakal´aˇrsk´epr´ace.

voxy, pˇr´ıpadnˇebez pouˇzit´ıproxy serveru, je zobrazeno v grafu na obr´azku 5.1. V grafu je rovnˇeˇzu kaˇzd´ewebov´estr´ankyzobrazen poˇcet subresour- ces, kter´ebyly naˇc´ıt´any jako jej´ı souˇc´ast.Pro metodu TLS tunelu a TLS MITM byl pouˇzitproxy server z pˇredchoz´ıbakal´aˇrsk´epr´ace.Aby mohlo b´yt mˇeˇren´ıprovedeno s vyuˇzit´ımmodern´ıhowebov´ehoprohl´ıˇzeˇce, byly pˇredem pˇripraveny certifik´aty pro jednotliv´ewebov´estr´anky. Certifik´aty vytvoˇren´e p˚uvodn´ıknihovnou Mbed TLS by totiˇzbyly webov´ymprohl´ıˇzeˇcemoznaˇceny jako ned˚uvˇeryhodn´ea test by nebylo moˇzn´euskuteˇcnit.

Jak m˚uˇzemevidˇetna grafu 5.1 srovn´avaj´ıc´ım dobu potˇrebnouk naˇcten´ı kompletn´ıwebov´estr´anky, rozˇs´ıˇren´ıproxy serveru Privoxy o opakovan´evyuˇz´ı- v´an´ıspojen´ıs klientem i c´ılov´ymserverem znaˇcnˇezrychlilo naˇc´ıt´an´ıwebov´ych str´anekoproti metodˇeMITM pouˇzit´ev pˇredchoz´ıbakal´aˇrsk´epr´aci.Nejvˇetˇs´ı zrychlen´ıje podle oˇcek´av´an´ıu webov´ych str´aneks velk´ympoˇctemsubresour- ces. V pr˚umˇerubylo na testovan´emnoˇzinˇewebov´ych str´anekdosaˇzenozrych- len´ı33,5 % proti p˚uvodn´ımetodˇeMITM. Z grafu je rovnˇeˇzpatrn´e,ˇzepomoc´ı sd´ılen´ıTLS spojen´ıbylo dosaˇzenot´emˇeˇrshodn´edoby pro odbaven´ıpoˇzadavku klienta jako pˇripouˇzit´ımetody TLS tunelu. Ta ovˇsemneumoˇzˇnujefiltrovat HTTPS komunikaci, a ani proxy server pˇrin´ınevytv´aˇr´ıTLS spojen´ı.Jelikoˇz pro mˇeˇren´ıdoby naˇcten´ıu metod TLS MITM a TLS tunelu byla pouˇzitaim- plementace z pˇredchoz´ıbakal´aˇrsk´epr´ace,m˚uˇzeb´ytv´ysledekˇc´asteˇcnˇeovlivnˇen i rozd´ıln´ymikryptografick´ymiknihovnami, pˇr´ıpadnˇedalˇs´ımizmˇenami prove- den´ymiv r´amcidiplomov´epr´ace.

67 5. Testovan´ ´ı dosaˇzenych´ vysledk´ ˚u

Obr´azek5.2: Vliv hodnoty parametru keep-alive-timeout na dobu naˇc´ıt´an´ı vybran´ych webov´ych str´anek

5.2.1 Vliv parametru keep-alive-timeout na v´ykonnost

Graf 5.2 zobrazuje dobu naˇc´ıt´an´ıwebov´ych str´anekv z´avislosti na nastaven´ı hodnoty parametru keep-alive-timeout v konfiguraˇcn´ımsouboru proxy ser- veru. Ten ovlivˇnujedobu, po kterou jsou spojen´ıs klientem a webov´ymser- verem po ukonˇcen´ı aktivn´ı komunikace zachov´ana.Z grafu vypl´yv´a,ˇzepˇri jednor´azov´emnaˇcten´ıkonkr´etn´ıwebov´estr´ankyhodnota tohoto parametru prakticky nehraje roli (pokud tedy nen´ınulov´a).D˚uvodem je velmi mal´yin- terval mezi pˇr´ıjmemjednotliv´ych dozat˚uod webov´ehoprohl´ıˇzeˇce.Hodnota parametru by se naopak projevila pˇridlouhodob´emprohl´ıˇzen´ı konkr´etn´ıho webu, kdy jsou intervaly mezi poˇzadavky ovlivnˇeny i interakc´ıuˇzivatele.

5.2.2 Sd´ılen´ıTLS session

Sd´ılen´ıTLS spojen´ımezi jednotliv´ymivl´akny proxy severu nem´aprakticky ˇz´adn´edopady na v´ykon pˇrizpracov´an´ı samostatn´ych dotaz˚una jednotliv´e webov´estr´anky. V´yhodu pˇrin´aˇs´ıpˇredevˇs´ımpˇriparaleln´ımobsluhov´an´ınˇekolika klient˚u.Pro vˇetˇs´ıvyuˇzit´ıt´etofunkcionality je vhodn´ev konfiguraˇcn´ımsou- boru config nastavit parametr default-server-timeout na hodnotu vyˇsˇs´ı neˇzu parametru keep-alive-timeout. D´ıkytomu roste pravdˇepodobnost, ˇze spojen´ıs webov´ymserverem bude udrˇzov´anoi po uzavˇren´ıspojen´ıs klientem, a bude tak nab´ıdnuto dalˇs´ımvl´akn˚um.I tato implementovan´afunkcionalita tak pˇrin´aˇs´ıdalˇs´ımoˇznost, jak zv´yˇsitv´ykonnost proxy severu. Vzhledem ke dˇr´ıve zmiˇnovan´ymbezpeˇcnostn´ımrizik˚umv sekci 3.3.7 je konkr´etn´ınastaven´ı na zv´aˇzen´ıspr´avce proxy serveru.

68 5.3. Bezpeˇcnost

5.3 Bezpeˇcnost

Bˇehemimplementace rozˇs´ıˇren´ıpro proxy server Privoxy byl kladen d˚urazna zachov´an´ıbezpeˇcnosti.Jelikoˇzproxy server prov´ad´ıTLS handshake s c´ılov´ym serverem, prov´ad´ırovnˇeˇzkontrolu jeho certifik´atua vˇsech dalˇs´ıch parametr˚u spojen´ı. Z tohoto d˚uvodu byla rozˇs´ıˇrenakonfigurace proxy severu o novou akci umoˇzˇnuj´ıc´ıkonfigurovat seznam povolen´ych ˇsifrov´ych sad pro komunikaci s webov´ymserverem. D´ıkytomu m˚uˇzeklient nastavit ´uroveˇnzabezpeˇcen´ıpro libovolnou url adresu. Nav´ıci pˇresto, ˇzebyla nov´arozhran´ıimplementov´ana s vyuˇzit´ımnov´ekryptografick´eknihovny, z˚ustalozachov´anoinformov´an´ıkli- enta o ne´uspˇeˇsn´evalidaci certifik´atupˇrijat´ehood c´ılov´ehoserveru, a to vˇcetnˇe moˇznostistaˇzen´ıkompletn´ıhoˇretˇezcecertifik´atu. V´ysledn´a´uroveˇnzabezpeˇcen´ıbyla ovˇeˇrenapomoc´ıtest˚udostupn´ych na https://www.badssl.com. V´ysledkytˇechto test˚ujsou zobrazeny v tabulce 5.2 spoleˇcnˇes v´ysledkymodern´ıch webov´ych prohl´ıˇzeˇc˚u.V tabulce jsou zobra- zeny v´ysledkypro v´ychoz´ınastaven´ıbez dalˇs´ıch z´asah˚uspr´avce proxy serveru. Z tohoto d˚uvodu jsou zejm´enanedostatky v ˇc´asti Sifrov´esady“ˇ a V´ymˇena ” ” kl´ıˇce“ zanedbateln´e,nebot’ je lze odstranit vhodnou konfigurac´ı.Ze zbyl´ych rizik, kter´amodern´ıwebov´eprohl´ıˇzeˇcena rozd´ılod proxy serveru odhal´ı,je nejvˇetˇs´ımnedostatkem zejm´enachybˇej´ıc´ıkontrola revokovan´ych certifik´at˚u.

5.4 Dalˇs´ımoˇznosti rozvoje

Aby byl proxy server i v budoucnu konkurenceschopn´y,je nezbytn´e,aby i nad´alepˇrin´aˇseluˇzivatel˚umnov´efunkcionality a rozˇs´ıˇren´ı.Aˇckoli tato diplo- mov´apr´aceimplementuje ˇradurozˇs´ıˇren´ı,nab´ız´ıse mnoho dalˇs´ıch moˇznost´ı, jak tato rozˇs´ıˇren´ınad´alerozv´ıjetˇcidoplˇnovat. D´ıkynˇekter´ymz nich se rozˇs´ıˇr´ı funkcionality proxy serveru, jin´ezase zv´yˇs´ıuˇzivatelsk´ykomfort ˇcizlepˇs´ıza- bezpeˇcen´ıpˇren´aˇsen´ych dat.

5.4.1 V´yjimky pro nevalidn´ıcertifik´aty Proxy server pˇrifiltrov´an´ıHTTPS komunikace ovˇeˇrujecertifik´aty webov´ych server˚ua webov´eprohl´ıˇzeˇcejiˇzpˇrijmoupouze certifik´atgenerovan´yproxy ser- verem. V nˇekter´ych pˇr´ıpadech ovˇsemm˚uˇzeuˇzivatel vyˇzadovat pˇripojen´ıke konkr´etn´ımu webov´emu serveru i pˇresurˇcit´enedostatky certifik´atu.Privoxy jiˇzumoˇzˇnujeuˇzivateli zobrazit veˇsker´eparametry certifik´atuwebov´ehoser- veru, pokud je oznaˇcenjako nevalidn´ı.Proxy server by ovˇsemkromˇeinformac´ı o webov´emcertifik´atumohl uˇzivateli nab´ıdnouti moˇznostudˇelen´ıv´yjimky pro konkr´etn´ı certifik´at.(V souˇcasnostije umoˇznˇenoudˇelitv´yjimkupouze pro urˇcit´edom´enov´ejm´eno,nelze specifikovat konkr´etn´ıcertifik´at.)Vhodnou formou pro vytvoˇren´ıv´yjimkyje napˇr´ıkladodkaz na webov´estr´ances infor- macemi o neplatn´emcertifik´atu.Po jeho otevˇren´ıby proxy server pˇridalˇs´ım zpracov´an´ıtohoto certifik´atunav´azalspojen´ıbez ohledu na jeho platnost.

69 5. Testovan´ ´ı dosaˇzenych´ vysledk´ ˚u

Tabulka 5.2: Srovn´an´ı ´uspˇeˇsnostiPrivoxy a webov´ych prohl´ıˇzeˇc˚upˇriodha- lov´an´ınedostatk˚uSSL/TLS spojen´ı(Ano – odhaleno, Ne – neodhaleno) Privoxy Privoxy Google Test Firefox21 Safari22 LibreSSL18 MbedTLS19 Chrome20 Validace certifik´atu expired Ano Ano Ano Ano Ano wrong.host Ano Ano Ano Ano Ano self-signed Ano Ano Ano Ano Ano unrusted-root Ano Ano Ano Ano Ano revoked Ne Ne Ano Ano Ano pinning-test Ne Ne Ano Ano Ne no-sct Ne Ne Ano Ne Ne sha1-intermediate Ne Ano Ano Ano Ano invalid-expected-sct Ano Ano Ano Ano Ano Sifrov´esadyˇ cbc Ne Ne Ne Ne Ne rc4-md5 Ne Ano Ano Ano Ano rc4 Ne Ano Ano Ano Ano 3des Ne Ano Ne Ne Ne null Ano Ano Ano Ano Ano V´ymˇenakl´ıˇce dh480 Ano Ano Ano Ano Ano dh512 Ano Ano Ano Ano Ano dh1024 Ne Ne Ano Ne Ano dh2048 Ne Ne Ano Ne Ano dh-small-subgroup Ne Ne Ano Ne Ano dh-composite Ne Ne Ano Ne Ano Zn´am´eˇspatn´e Superfish Ano Ano Ano Ano Ano eDellRoot Ano Ano Ano Ano Ano DSD Test Provider Ano Ano Ano Ano Ano preact-cli Ano Ano Ano Ano Ano Webpack-dev-server Ano Ano Ano Ano Ano Zanikl´e Zanikl´e– sha1-2016 Ano Ano Ano Ano Ano Zanikl´e– sha1-2017 Ano Ano Ano Ano Ano

5.4.2 Nov´emetody pro kontrolu certifik´at˚u Jak vypl´yv´az tabulky 5.2, proxy server nekontroluje seznamy revokovan´ych certifik´at˚u.Proto m˚uˇzeklienta pˇripojit i k webov´emu serveru, kter´yse pro- kazuje zneplatnˇen´ymcertifik´atem.Tento bezpeˇcnostn´ı nedostatek by bylo vhodn´eodstranit rozˇs´ıˇren´ımst´avaj´ıc´ıkontroly. V r´amci kontroly certifik´at˚u by mohl proxy server nab´ıdnouti podporu CT.

18LibreSSL verze 3.0.2 19Mbed TLS verze 2.16.6 20Google Chrome verze 57.0.2987.133 (64 bit˚u) 21Firefox verze 75.0 (64 bit˚u) 22Safari iPadOS 13.4.1

70 5.4. Dalˇs´ımoˇznostirozvoje

5.4.3 Nov´einformativn´ızpr´avy Proxy server jiˇznyn´ı informuje klienta pomoc´ı pˇripraven´ych ˇsablono ˇradˇe probl´em˚uvznikl´ych bˇehemnavazov´an´ı spojen´ı s webov´ymserverem. Jako pˇr´ıklad m˚uˇzemeuv´estzpr´avutypu No such domain“, pokud se nepodaˇr´ı ” nal´eztwebov´yserver pro zadanou url adresu. S podporou zabezpeˇcen´ych TLS spojen´ıovˇsempˇrich´az´ıˇradadalˇs´ıch specifiˇctˇejˇs´ıch chyb. Jedn´ımz vhodn´ych rozˇs´ıˇren´ıje zaveden´ıvˇetˇs´ıgranularity pˇrizas´ıl´an´ıchybov´ych zpr´av,pˇr´ıpadnˇe doplnˇen´ıchybov´ych str´aneki pro chyby, o kter´ych dosud nen´ıklient infor- mov´anv˚ubec.

5.4.4 Naˇc´ıt´an´ıkonfiguraˇcn´ıch soubor˚u Proxy server naˇc´ıt´aˇradukonfiguraˇcn´ıch soubor˚u.Jedn´ım z nich je i sou- bor definuj´ıc´ı akce pro vybran´eurl adresy. Tyto akce pak napˇr´ıklad akti- vuj´ıpˇreddefinovan´efiltry ˇcimˇen´ıparametry nav´azan´ych spojen´ı.Pro naˇc´ıt´an´ı tˇechto akc´ıje v Privoxy pouˇzitapromˇenn´atypu long, kde jsou jednotliv´ebity t´etopromˇenn´epˇriˇrazeny pˇr´ısluˇsn´eakci. Vzhledem k omezen´ed´elcepromˇenn´e typu long je nyn´ıpoˇcetakc´ızcela vyˇcerp´ana nov´eakce jiˇznelze pˇrid´avat. Z tohoto d˚uvodu by bylo vhodn´eupravit naˇc´ıt´an´ıakc´ız konfiguraˇcn´ıhosou- boru tak, aby nebyl jejich poˇcetnijak limitov´an.

5.4.5 Protokol HTTP/2.0 Nejnovˇejˇs´ıverze protokolu HTTP pˇrin´aˇs´ıˇraduzmˇenoproti pˇredchoz´ımverz´ım. Z tohoto d˚uvodu vyˇzadujepodpora HTTP/2.0 rozs´ahl´ezmˇeny na stranˇeproxy serveru. Vzhledem k v´yhod´amtohoto protokolu a jeho postupn´emu rozˇsiˇrov´an´ı v r´amciwebov´ekomunikace by vˇsakbylo velmi vhodn´e,aby jedn´ımz dalˇs´ıch rozˇs´ıˇren´ıPrivoxy byla i podpora tohoto protokolu.

71

Z´avˇer

C´ılemt´etodiplomov´epr´acebylo analyzovat v´yvoj ˇsifrovan´ehoHTTP v aktu´al- n´ıch webov´ych prohl´ıˇzeˇc´ıch bˇehemposledn´ıtˇr´ılet, a to vˇcetnˇezmˇen v pouˇz´ıva- n´ych certifik´atech. Souˇc´ast´ıanal´yzyje i zhodnocen´ıtohoto v´yvoje z pohledu problematiky filtrov´an´ıHTTPS komunikace pomoc´ıproxy serveru. Na z´akladˇe t´etoanal´yzypak mˇelb´ytvytvoˇrenn´avrha implementace ´uprav proxy ser- veru Privoxy, kter´eby modernizovaly pˇredchoz´ıimplementaci podpory pro- tokolu TLS a z´aroveˇnumoˇznily aplikovat funkcionality Privoxy na veˇskerou pˇren´aˇsenouHTTPS komunikaci. Pr´aceby rovnˇeˇzmˇelatestovat p˚uvodn´ıi mo- dernizovanou verzi Privoxy v aktu´aln´ıch webov´ych prohl´ıˇzeˇc´ıch a diskutovat dosaˇzen´ev´ysledky. Kapitola 1 popisuje nejd˚uleˇzitˇejˇs´ıaktualizace nejrozˇs´ıˇrenˇejˇs´ıch webov´ych prohl´ıˇzeˇc˚ubˇehemposledn´ıch tˇrech let. D˚urazbyl kladen zejm´enana zmˇeny t´ykaj´ıc´ıse protokolu HTTP a certifik´at˚u.Kapitola 2 se zab´yv´adopady tˇechto aktualizac´ına certifik´aty a proxy servery. Pops´any jsou zde nutn´ezmˇeny re- flektuj´ıc´ıaktualizace webov´ych prohl´ıˇzeˇc˚u.V kapitole 3 jsou navrˇzenanov´a rozˇs´ıˇren´ıa vylepˇsen´ınavazuj´ıc´ına pˇredchoz´ıverze Privoxy. Navrˇzen´arozˇs´ıˇren´ı mimo jin´ezav´ad´ıstrukturov´an´ızdrojov´ehok´odu,umoˇzˇnuj´ıfiltrov´an´ıveˇsker´e pˇren´aˇsen´ekomunikace, zjednoduˇsuj´ıproces sestaven´ızdrojov´ych k´od˚u,urych- luj´ızpracov´an´ıpoˇzadavk˚uklienta ˇcirozˇsiˇruj´ımoˇznostikonfigurace. Samotn´a implementace navrˇzen´ych rozˇs´ıˇren´ı je detailnˇepops´anav kapitole 4. Kapi- tola 5 se vˇenuje testov´an´ıv´ysledn´ehoˇreˇsen´ıa diskutuje dosaˇzen´ev´ysledky v porovn´an´ıs pˇredchoz´ımiverzemi Privoxy. V´ysledn´yproxy server umoˇzˇnuje´uspˇeˇsnˇefiltrovat veˇskerou pˇren´aˇsenou HTTPS komunikaci vˇcetnˇeHTTP hlaviˇcekpoˇzadavk˚ui odpovˇed´ıa to i pˇri pouˇzit´ı nadˇrazen´ehoproxy serveru. D´ıky implementovan´ymzmˇen´amje na rozd´ılod pˇredchoz´ıch verz´ımoˇzn´evyuˇz´ıtveˇsker´efunkcionality proxy serveru i na komunikaci s modern´ımiwebov´ymiprohl´ıˇzeˇci,aniˇzby byl uˇzivatel va- rov´anpˇredpotencion´aln´ım´utokem na spojen´ı.Metoda opakovan´ehopouˇz´ıv´an´ı a sd´ılen´ıvytvoˇren´ych spojen´ınav´ıcurychlila vyˇrizov´an´ıpoˇzadavk˚uklienta. Na testovan´emnoˇzinˇewebov´ych str´anekbylo dosaˇzenozrychlen´ı33.5 % oproti

73 Zav´ erˇ pˇredchoz´ı verzi, kter´aumoˇzˇnujepouze ˇc´asteˇcn´evyuˇzit´ı funkcionalit proxy serveru. Zavedena byla podpora zabezpeˇcen´eho spojen´ıpro konfiguraˇcn´ıroz- hran´ıproxy serveru a rozˇs´ıˇreny byly i moˇznostikonfigurace a to jak bˇehem sestavov´an´ı bin´arn´ıho souboru Privoxy, tak pˇrijeho vyuˇz´ıv´an´ı. Uˇzivatel si novˇem˚uˇze definovat ˇsifrovou sadu pro libovoln´ywebov´yserver. Z´aroveˇnsi m˚uˇzevybrat mezi novˇepouˇzitoukryptografickou knihovnu LibreSSL, p˚uvodn´ı knihovnou Mbed TLS, nebo sestaven´ıbez jak´ekoli kryptografick´eknihovny. Veˇsker´enov´efunkcionality byly implementov´any pro obˇetyto knihovny. D´ıky dalˇs´ımproveden´ym´uprav´ama zjednoduˇsen´ımzdrojov´ehok´odubyla odhalena a odstranˇenai jedna z chyb v p˚uvodn´ımzdrojov´emk´oduproxy serveru.

74 Literatura

[1] Svec,ˇ V.: Podpora pro filtrov´an´ı SSL/TLS komunikace v Privoxy. Ba- kal´aˇrsk´a pr´ace, Cesk´eˇ vysok´e uˇcen´ı technick´e v Praze, Fakulta in- formaˇcn´ıch technologi´ı,Praha, kvˇeten2017. [2] Mozilla and individual contributors: Evolution of HTTP. [online], listopad 2019, [cit. 14.2.2020]. Dostupn´ez: https://developer.mozilla.org/en- US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP [3] Satrapa, P.: Jak funguje nov´yprotokol HTTP/2. [online], bˇrezen2015, [cit. 9.3.2020]. Dostupn´ez: https://www.root.cz/clanky/jak-funguje- novy-protokol-http-2/ [4] Usage statistics of HTTP/2 for websites. [online], ´unor 2020, [cit. 10.2.2020]. Dostupn´ez: https://w3techs.com/technologies/details/ ce-http2 [5] B¨ock, J.: Provable secure RSA Signatures and their Implemen- tation. [online], kvˇeten 2011, [cit. 14.2.2020]. Dostupn´e z: https:// rsapss.hboeck.de/rsapss.pdf [6] Rescorla, E.: The Transport Layer Security (TLS) Protocol Ver- sion 1.3. [online], srpen 2018, [cit. 14.2.2020]. Dostupn´ez: https:// tools.ietf.org/html/rfc8446 [7] Chrome Platform Status. [online], [cit. 14.2.2020]. Dostupn´ez: https: //www.chromestatus.com/features [8] Rescorla, E.: The Transport Layer Security (TLS) Protocol Ver- sion 1.2. [online], srpen 2008, [cit. 28.2.2020]. Dostupn´ez: https:// tools.ietf.org/html/rfc5246 [9] Stevens, M.; Bursztein, E.; aj.: The first collision for full SHA-1. [on- line], 2017, [cit. 15.2.2020]. Dostupn´ez: https://eprint.iacr.org/2017/ 190.pdf

75 Literatura

[10] Krasnov, V.: It takes two to ChaCha (Poly). [online], duben 2016, [cit. 29.2.2020]. Dostupn´ez: https://blog.cloudflare.com/it-takes-two- to-chacha-poly/

[11] Mozilla and individual contributors: Set-Cookie. [online], bˇrezen2020, [cit. 12.3.2020]. Dostupn´ez: https://developer.mozilla.org/en-US/ docs/Web/HTTP/Headers/Set-Cookie

[12] Rescorla, E.: HTTP Over TLS. [online], kvˇeten2000, [cit. 20.2.2020]. Dostupn´ez: https://tools.ietf.org/html/rfc2818

[13] Makarov, L.: Say goodbye to URLs with embedded credentials. [online], du- ben 2017, [cit. 18.3.2020]. Dostupn´ez: https://medium.com/@lmakarov/ say-goodbye-to-urls-with-embedded-credentials-b051f6c7b6a3

[14] What is Certificate Transparency. [online], [cit. 14.2.2020]. Dostupn´ez: https://www.certificate-transparency.org/what-is-ct

[15] Laurie, B.; Langley, A.; Kasper, E.: Certificate Transparency. [online], ˇcerven 2013, [cit. 22.2.2020]. Dostupn´e z: https://tools.ietf.org/ html/rfc6962

[16] Sleevi, R.: Certificate Transparency Policy. [online], duben 2017, [cit. 16.3.2020]. Dostupn´ez: https://groups.google.com/a/chromium.org/ forum/#!msg/ct-policy/sz_3W_xKBNY/6jq2ghJXBAAJ

[17] Mozilla and individual contributors: Using the Notifications API. [online], ´unor 2020, [cit. 24.2.2020]. Dostupn´e z: https: //developer.mozilla.org/en-US/docs/Web/API/Notifications_ API/Using_the_Notifications_API

[18] McGrew, D. A.: An Interface and Algorithms for Authenticated En- cryption. [online], leden 2008, [cit. 29.2.2020]. Dostupn´e z: https:// tools.ietf.org/html/rfc5116

[19] Ghedini, A.; Vasiliev, V.: Transport Layer Security (TLS) Certifi- cate Compression draft-ietf-tls-certificate-compression-03. [online], duben 2018, [cit. 2.3.2020]. Dostupn´ez: https://tools.ietf.org/html/draft- ietf-tls-certificate-compression-03

[20] Kingston, J.: Restricting AppCache to Secure Contexts. [online], ´unor 2018, [cit. 14.2.2020]. Dostupn´e z: https://blog.mozilla.org/ security/2018/02/12/restricting-appcache-secure-contexts/

[21] Fielding, R. T.; Reschke, J. F.: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. [online], ˇcerven 2014, [cit. 21.2.2020]. Dostupn´e z: https://tools.ietf.org/html/rfc7231

76 Literatura

[22] Popov, A.; Nystroem, M.; Balfanz, D.; aj.: The Token Binding Protocol Version 1.0. [online], ˇr´ıjen 2018, [cit. 2.3.2020]. Dostupn´ez: https:// tools.ietf.org/html/rfc8471

[23] Popov, A.; Nystroem, M.; Balfanz, D.; aj.: Token Binding over HTTP. [online], ˇr´ıjen2018, [cit. 3.3.2020]. Dostupn´ez: https://tools.ietf.org/ html/rfc8473

[24] Harper, N.: Intent to Remove: Token Binding. [online], [cit. 24.4.2020]. Dostupn´e z: https://groups.google.com/a/chromium.org/forum/ #!topic/blink-dev/OkdLUyYmY1E/discussion

[25] O’Brien, D.; Sleevi, R.; Whalley, A.; aj.: Chrome’s Plan to Dis- trust Symantec Certificates. [online], z´aˇr´ı 2017, [cit. 15.3.2020]. Do- stupn´ez: https://security.googleblog.com/2017/09/chromes-plan- to-distrust-symantec.html

[26] Evans, C.; Palmer, C.; Sleevi, R.: Public Key Pinning Extension for HTTP. [online], duben 2015, [cit. 3.3.2020]. Dostupn´e z: https:// tools.ietf.org/html/rfc7469

[27] Yasskin, J.: Web Packaging draft-yasskin-dispatch-web-packaging-00. [on- line], ˇcerven 2017, [cit. 4.3.2020]. Dostupn´ez: https://tools.ietf.org/ id/draft-yasskin-dispatch-web-packaging-00.html

[28] Yasskin, J.: Mixed Content. [online], srpen 2016, [cit. 6.3.2020]. Dostupn´e z: https://www.w3.org/TR/mixed-content/

[29] Merewood, R.: SameSite cookies explained. [online], kvˇeten 2019, [cit. 6.3.2020]. Dostupn´e z: https://web.dev/samesite-cookies- explained/

[30] Dierks, T.; Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.1. [online], duben 2006, [cit. 8.3.2020]. Dostupn´ez: https: //tools.ietf.org/html/rfc4346

[31] Thomson, M.: Removing Old Versions of TLS. [online], ˇr´ıjen2018, [cit. 7.3.2020]. Dostupn´ez: https://blog.mozilla.org/security/2018/10/ 15/removing-old-versions-of-tls/

[32] Smotrankov, A.: How does TLS 1.3 protect against downgrade attacks? [online], [cit. 9.3.2020]. Dostupn´ez: https://blog.gypsyengineer.com/ en/security/how-does-tls-1-3-protect-against-downgrade- attacks.html

[33] Barnes, R.: Deprecating Non-Secure HTTP. [online], duben 2015, [cit. 11.3.2020]. Dostupn´e z: https://blog.mozilla.org/security/2015/ 04/30/deprecating-non-secure-http/

77 Literatura

[34] Mozilla Developer Network and individual contributors: PKI:CT. [online], prosinec 2014, [cit. 15.3.2020]. Dostupn´ez: https://wiki.mozilla.org/ PKI:CT

[35] MDN contributors: Certificate Transparency. [online], ˇcervence 2019, [cit. 17.3.2020]. Dostupn´ez: https://developer.mozilla.org/en-US/docs/ Web/Security/Certificate_Transparency

[36] Privoxy: Privoxy Frequently Asked Questions. [online], [cit. 21.3.2020]. Dostupn´ez: https://www.privoxy.org/faq/misc.html

[37] Morton, B.: What’s the Difference Between a Public and Private Trust Certificate? [online], bˇrezen 2019, [cit. 22.3.2020]. Dostupn´e z: https://www.entrustdatacard.com/blog/2019/march/difference- between-a-public-and-private-trust-certificate

[38] Campbell, B.: HTTPS Token Binding with TLS Terminating Reverse Proxies. [online], ˇcerven 2018, [cit. 23.3.2020]. Dostupn´e z: https:// tools.ietf.org/id/draft-ietf-tokbind-ttrp-05.html

[39] MDN contributors: HTTP Public Key Pinning (HPKP). [online], ´unor 2020, [cit. 25.3.2020]. Dostupn´ez: https://developer.mozilla.org/en- US/docs/Web/HTTP/Public_Key_Pinning

[40] Munshi, A.: How HTTP proxies read TLS encrypted traffic from browsers ? [online], ˇr´ıjen 2017, [cit. 25.3.2020]. Dostupn´e z: https://medium.com/@ethicalevil/how-http-proxies-read-tls- traffic-from-browsers-f15364e91226

[41] Privoxy: Privoxy 3.0.28 User Manual. [online], [cit. 4.2.2020]. Dostupn´e z: https://www.privoxy.org/user-manual/

[42] Privoxy: Announcing Privoxy 3.0.28 stable. [online], [cit. 4.4.2020]. Do- stupn´ez: https://www.privoxy.org/announce.txt

[43] Stevens, R.: Whats the difference between select() and poll()? [on- line], [cit. 4.4.2020]. Dostupn´ez: http://www.unixguide.net/network/ socketfaq/2.14.shtml

78 Prˇ´ıloha A

Seznam pouˇzit´ychzkratek

AEAD Authenticated Encryption with Additional Data

ALPN Application-Layer Protocol Negotiation

CA Certifikaˇcn´ıautorita

CRL Certificate revocation list

CSRF Cross-site request forgery

CT Certificate Transparency

ECDSA The Elliptic Curve Digital Signature Algorithm

EKM Exported Keying Material

HPKP HTTP Public Key Pinning

HSTS HTTP Strict Transport Security

HTTP Hyper–Text Transfer Protocol

HTTPS Hyper–Text Transfer Protocol Secure

IP Internet Protocol

MAC Message Authentication Code

MITM Man In The Middle

NIST National Institute of Standards and Technology

NTLM NT LAN Manager

OAEP Optimal Asymmetric Encryption Padding

PDF Portable Document Format

79 A. Seznam pouˇzitych´ zkratek

PKI Public Key Infrastructure

PSK Pre-shared key

PSS Probabilistic Signature Scheme

RFC Request for Comments

RTT Round-trip time

SCT Signed Certificate Timestamp

SPKI Subject Public Key Information

SSL Secure Sockets Layer

TCP Transmission Control Protocol

TLS Transport Layer Security

TPM Trusted Platform Module

TTRP TLS Terminating Reverse Proxy

URI Uniform Resource Identifier

URL Uniform Resource Locator

WWW World Wide Web

XSS Cross-site scripting

80 Prˇ´ıloha B

Uˇzivatelsk´apˇr´ıruˇcka

Pro instalaci a spuˇstˇen´ıproxy serveru Privoxy vˇcetnˇenovˇeimplementovan´ych rozˇs´ıˇren´ımus´ıuˇzivatel pˇripravit urˇcit´en´astroje a doplˇnky. Tato pˇr´ılohastruˇcnˇe popisuje postup pro instalaci Privoxy a jeho n´asledn´evyuˇzit´ı ve webov´em prohl´ıˇzeˇci.

B.1 Poˇzadavky pro instalaci

Pro sestaven´ı zdrojov´ehok´oduproxy serveru Privoxy vˇcetnˇeimplemento- van´ych rozˇs´ıˇren´ı jsou potˇreban´astroje autoconf, GNU make a kompil´ator jazyka C. Z´aroveˇnje potˇrebazvolit jednu ze dvou podporovan´ych kryptogra- fick´ych knihoven. Tedy bud’ knihovnu LibreSSL nebo Mbed TLS. Zkompilo- van´yzdrojov´yk´odknihovny je nezbytn´eum´ıstitdo sloˇzek libressl respektive mbedtls v koˇrenov´eadres´aˇriproxy serveru. Aby mohl proxy server filtrovat HTTPS komunikaci, je nezbytn´epˇripravit i vlastn´ıCA (vˇcetnˇejej´ıhoveˇrejn´ehoa soukrom´ehokl´ıˇce),soubor obsahuj´ıc´ı d˚uvˇeryhodn´eCA a adres´aˇrovou strukturu, ve kter´em˚uˇzeproxy server ukl´adat vytvoˇren´ecertifik´aty. Pˇr´ısluˇsn´eparametry je moˇzn´enastavit v konfiguraˇcn´ım souboru config.

B.2 Instalace

Pro sestaven´ızdrojov´ehok´oduproxy serveru vˇcetnˇeimplementovan´ych rozˇs´ı- ˇren´ı byly upraveny pˇr´ısluˇsn´ekonfiguraˇcn´ı soubory. Sestaven´ı projektu bylo ´uspˇeˇsnˇetestov´anos pouˇzit´ımn´astroj˚uCygwin64 Terminal, Windows Subsys- tem for Linux (WSL) – Ubuntu 18.04 LTS a v termin´aluoperaˇcn´ıhosyst´emu Linux Mint v19.3 x86. Pokud uˇzivatel pouˇz´ıv´ajeden z tˇechto n´astroj˚u,staˇc´ıpo- moc´ın´asleduj´ıc´ıch pˇr´ıkaz˚upˇripravit soubor makefile a s jeho pomoc´ın´aslednˇe sestavit bin´arn´ısoubor:

81 B. Uˇzivatelska´ prˇ´ıruckaˇ

autoheader&& autoconf&&./configure make

Vznikne tak bin´arn´ısoubor ke spuˇstˇen´ıproxy serveru Privoxy. Konkr´etn´ı kryptografickou knihovnu lze zvolit pomoc´ıparametr˚u --disable-libressl nebo --enable-mbedtls u configure skriptu. Testov´anobylo i sestaven´ızdrojov´ehok´odupomoc´ın´astroje MingW. Pro kompilaci knihovny LibreSSL pomoc´ıMingW lze pouˇz´ıttyto pˇr´ıkazy:

CC=i686-w64-mingw32-gcc CPPFLAGS=-D__MINGW_USE_VC2005_COMPAT ./configure--host=i686-w64-mingw32 make

K vygernerov´an´ı makefile pro sestaven´ı Privoxy pak slouˇz´ı n´asleduj´ıc´ı pˇr´ıkazy:

autoheader&& autoconf ./configure--host=i686-w64-mingw32--enable-mingw32 --disable-pthread

N´aslednˇeje nezbytn´eve vygenerovan´emsouboru GNUmakefile doplnit de- finici SSL LIBRE LIB a SSL MBEDTLS LIB o pˇrep´ınaˇc -lws2 32“. Pot´ejiˇzlze ” ´uspˇeˇsnˇepouˇz´ıtpˇr´ıkaz make k sestaven´ıbin´arn´ıhosouboru.

B.3 Nastaven´ıwebov´ehoprohl´ıˇzeˇce

Pro vyuˇzit´ıproxy serveru webov´ymprohl´ıˇzeˇcemje jeˇstˇenezbytn´enastavit ip adresu a port na kter´emproxy server naslouch´a.To je moˇzn´ev nastaven´ıch webov´ehoprohl´ıˇzeˇce,pˇr´ıpadnˇev nastaven´ıch operaˇcn´ıhosyst´emu. Pˇr´ısluˇsn´e parametry je rovnˇeˇzmoˇzn´eupravit v konfiguraˇcn´ımsouboru config.

B.4 Konfigurace proxy serveru

Moˇznostikonfigurace proxy serveru byly v t´etopr´acirozˇs´ıˇreny o definici vlastn´ı ˇsifrov´esady pro vybran´ewebov´eservery. Uˇzivatel m˚uˇzetuto sadu definovat pomoc´ıkl´ıˇcov´ehoslova set-cipher-list v souboru user.action. Parametr tohoto kl´ıˇcov´ehoslova definuje povolenou ˇsifrovou sadu a jeho struktura se m˚uˇzeliˇsitv z´avislostina pouˇzit´ekryptografick´eknihovnˇe.

• Knihovna LibreSSL Povolen´ıvˇsech ˇsifrov´ych sad, kter´enevyuˇz´ıvaj´ıvybran´ealgoritmy:

{+set-cipher-list{ALL:!aNULL:!eNULL:!MD5:!RC4}} url{www.privoxy.org}

82 B.4. Konfigurace proxy serveru

• Knihovna Mbed TLS Povolen´ıpouze jedin´eˇsifrov´esady:

{+set-cipher-list{TLS-RSA-PSK-WITH-RC4-128-SHA}} www.privoxy.org

83

Prˇ´ıloha C

Obsah pˇriloˇzen´ehoCD

readme.txt...... Struˇcn´ypopis obsahu CD builds original privoxy 3.0.28 win32.zip ...... Privoxy 3.0.28 implementation libressl win32.tar.gz..Implementace s LibreSSL source files basic configuration files.tar.gz ...... Konfiguraˇcn´ısoubory patch files.tar.gz...... Patch soubory git repository export.tar.gz...... Export Git repozit´aˇre implementation.tar.gz ...... Zdrojov´ek´odyimplementace thesis.tar.gz...... Zdrojov´aforma pr´aceve form´atuLATEX original source files mbedtls-2.16.6-gpl.tgz ...... Knihovna Mbed TLS libressl-3.1.1.tar.gz...... Knihovna LibreSSL privoxy-3.0.26-stable-src.tar.gz ...... Privoxy 3.0.26 privoxy-3.0.28-stable-src.tar.gz ...... Privoxy 3.0.28 text DP Vaclav Svec 2020.pdf...... Text pr´aceve form´atuPDF

85