Spokojenost je ošidný pocit především na internetu.

BUDE TRANSFORMOVÁN Všechny datové pakety odesílané prostřednictvím internetu využívají od samého počátku ke svému přenosu model několika síťových vrstev. Nyní však stojíme před zásadní renovací těchto vrstev, jejímž cílem je rychlejší a bezpečnější web. APLIKAČNÍ VRSTVA Účelem aplikační vrstvy je umožnění vzájemné komunikace systémů. Protokol HTTP řídí komunikaci prohlížeče se serverem. HTTP PŘECHOD Z HTTP 1.1 NA HTTP 2.0 BEZPEČNOSTNÍ VRSTVA Secure Socket Layer se stará o zabezpečení komunikace pomocí SSL/TLS šifrování. SSL/TLS ŠIFROVÁNÍ CHRÁNÍCÍ PŘED NSA TRANSPORTNÍ VRSTVA Prostřednictvím protokolu TCP transportní vrstva určuje, jak budou odesílány datové pakety. TCP VYŠŠÍ RYCHLOST DÍKY UDP SÍŤOVÁ VRSTVA Všechna zařízení v internetu je možné propojit díky jejich IP adresám. IP PŘECHOD NA IPV6 BITVA o budoucnost internetu V příštím roce by se měl díky HTTP 2.0 web zrychlit a být bezpečnější pouze pokud však bude spolupracovat americká NSA. MARKUS MANDAU Spokojenost je ošidný pocit především na internetu. Poskytovatelé internetového připojení nás denně bombardují skvělými nabídkami, díky kterým budeme stahovat data z internetu rychlostí desítek megabitů za sekundu. Není divu, že vášniví surfaři snadno podlehnou, sáhnou hlouběji do kapes a za vyšší rychlost si připlatí. O své iluze ale rychle přijdou: stahování dat z různých souborových serverů je sice možná rychlejší, ale webové stránky se načítají úplně stejnou dobu jako přes starou ADSL přípojku. Nepomůže ani ještě rychlejší připojení, ani lepší hardware. Opravdovou brzdou při načítání stránek jsou totiž zastaralé internetové protokoly, kterými se řídí komunikace internetového prohlížeče a webového serveru. Pocházejí z doby, kdy se prostřednictvím internetu přenášely pouze jednoduché HTML stránky, snad jen s trochou fotek či grafiky. Současná komunikace v síti je však daleko náročnější. Je zcela běžné, že webové stránky obsahují stovky řádků skriptů a nahrávají své prvky z několika různých zdrojů. Kromě toho je často uživatel v neustálé interakci s webovou stránkou nebo je například používáno šifrování pro zachování soukromí komunikace. Nejlepším příkladem je HTTP, základní aplikační protokol, který řídí komunikaci internetového prohlížeče a webového serveru. Jeho v současnosti používaná verze 1.1 byla uvedena FOTO:DPA/PICTURE ALLIANCE; 123RF/ZENTILIA JÍZDNÍ ŘÁD PRO HTTP 2.0 Po dlouhých patnácti letech plánuje Internet Engineering Task Force (IETF) upgrade centrálního internetového protokolu HTTP. Nová pravidla pro datovou komunikaci chce IETF finalizovat do konce roku 2014. Pro celý internet pak nastane velká změna. Červen 1999 Uvedení HTTP 1.1 Březen 2012 První žádost o návrhy na HTTP 2.0 Září 2012 První návrh HTTP 2.0 Červenec 2013 První implementační plán HTTP 2.0 Srpen 2013 Počátek testovací fáze Listopad 2013 Přepracování modelu zabezpečení kvůli aféře špehování NSA Duben 2014 Přijímání posledních návrhů Listopad 2014 HTTP 2.0 bude zavedeno jako standard 2000 2012 2013 2014 2020 30 01/2014 CHIP.CZ

POROVNÁNÍ HTTP 1.1 A 2.0 Nová verze HTTP 2.0 bude zpětně kompatibilní s verzí 1.1, bude však založena na nových technologiích. S ohledem na aféru Edwarda Snowdena, který vynesl tajné materiály NSA, jsme se zaměřili především na hledisko zabezpečení. HTTP 1.1 HTTP 2.0 ŠIFROVÁNÍ (HTTPS) volitelné povinné (návrh) ŠIFROVACÍ TECHNOLOGIE obsahuje i kompromitované metody (RC4,Dual_EC_DRBG) sází na nové, bezpečné metody (např. Perfect Forward Secrery) KVALITA ŠIFROVÁNÍ určováno serverem určováno klientem (návrh) KOMPRESE HLAVIČEK MULTIPLEXOVÁNÍ (paralelní zpracování více dotazů/odpovědí) FULL-DUPLEX (současný přenos dat v obou směrech) PRIORITIZACE DATOVÝCH PAKETŮ PUSH ZPRÁVY ZE SERVERU SPOJENÍ PŘI NAHRÁVÁNÍ STRÁNKY více jedno ANO NE Spolehnout se můžete jedině na silné šifrování. Informátor EDWARD SNOWDEN v odpovědi na otázku, jak je možné se bránit před špehováním NSA na internetu. již v roce 1999 a od té doby jen minimálně optimalizována. Základní nedostatky tohoto protokolu přetrvávají už přes deset let. Také proto nemůže tento protokol plně využít možnosti dnešního širokopásmového internetového připojení. A co víc, kvůli vysoké vlastní režii (tzv. overhead) generuje HTTP 1.1 i značný objem zbytečných datových přenosů. Proto není divu, že se Internet Engineering Task Force (IETF), organizace zodpovědná za další technický rozvoj internetu, poslední dva roky intenzivně věnuje vylepšení zásadního komunikačního protokolu. Plán nasazení HTTP 2.0 je nyní hotový: internetoví specialisté jej chtějí uvést do konce roku 2014. První návrh implementace byl připraven v červenci 2013 a v srpnu téhož roku se začalo s testováním. Konkurenční návrhy pro HTTP 2.0 V roce 2012 představily společnosti Google a Microsoft vlastní návrhy na vylepšení protokolu HTTP. Googlem vyvinutý protokol SPDY (vyslovuje se jako speedy ) konkuruje variantě HTTP Speed+Mobility, se kterou přišel Microsoft. Samozřejmě není náhodou, že oba návrhy řeší především problém nedostatečné rychlosti HTTP 1.1. I z technického hlediska jsou obě řešení od internetových gigantů velmi podobná a liší se v zásadě jen tím, zda má být provoz přes HTTP 2.0 automaticky šifrovaný. Protokol SPDY byl nakonec IETF použit jako základ nového standardu HTTP 2.0, avšak bez povinného šifrování, které Google navrhoval. Tento ústupek učinilo IETF především kvůli mobilním zařízením, která by na šifrování musela vynakládat značný výpočetní výkon, což by mělo negativní vliv na výdrž jejich akumulátoru. Povinné šifrování by znamenalo komplikaci i pro provozovatele menších webů, kteří by museli platit za bezpečnostní certifikáty. Cesta k zavedení HTTP 2.0 se zdála hladká až do okamžiku skandálního odhalení praktik amerického Národního bezpečnostního úřadu (NSA) Edwardem Snowdenem. V září 2013 vyšlo totiž najevo, že NSA je schopna ve velkém měřítku odposlouchávat šifrovanou internetovou komunikaci vedenou přes HTTPS. Bruce Schneier, uznávaný expert na šif- 01/2014 CHIP.CZ rování, dokonce prohlásil, že NSA zničila důvěryhodnost internetu. Pozornost při vývoji HTTP 2.0 se následně zaměřila na bezpečnost, tedy téma, které se v té době již považovalo za vyřešené. V souvislosti s informacemi zveřejněnými Snowdenem zvažuje IETF všechna bezpečnostní hlediska nové verze protokolu HTTP a přijímá další návrhy, jak zajistit spolehlivost webového šifrování v HTTP 2.0. Současná verze šifrování HTTPS používá k sestavení zabezpečeného připojení protokoly SSL a TLS. Asymetrické šifrování pracuje se systémem veřejného a privátního klíče, kdy webový server nejdříve pošle prohlížeči certifikovaný veřejný klíč. Na základě certifikátu prohlížeč ověří, zda je klíč pravý, vytvoří tzv. Session key pro symetrické šifrování datového provozu a odešle jej serveru. Server pak použije svůj privátní klíč k extrahování klíče pro symetrické šifrování z této zprávy. Výsledkem je, že server i prohlížeč mají k dispozici stejný Session key a mohou tak šifrovat svoji vzájemnou komunikaci. Zadní vrátka NSA Mocná instituce, jako je NSA, sledující veškerý internetový provoz, může však zdánlivě bezpečnou komunikaci přes HTTPS dešifrovat. Stačí jí k tomu privátní klíč serveru, který může získat například na základě soudního příkazu nebo třeba promocí hackingu. Právě proto byla pro protokol HTTP 2.0 a související protokol TLS 1.3, který je vyvíjen současně, navržena nová metoda generování šifrovacích klíčů. U Perfect Forward Secrery (PFS) se nepoužívá žádná přímá výměna klíčů, které by mohly být zneužity, ale namísto toho si prohlížeč a server vymění více zpráv, přičemž používají šifrování založené na metodě Diffie-Hellman a vytvoří si symetrický klíč, který však není zasílán po webu. Tento klíč je platný pouze pro jedno konkrétní spojení a po jeho ukončení je smazán. I šifrovací postupy pro vytváření klíčů v rámci PFS však musejí být dostatečně bezpečné. Jak se bohužel ukázalo, právě NSA v minulosti aktivně spolupracovala na vývoji metody PFS, což vyvolává podezření, že do ní zanesla zadní vrátka, 31

Q R LATENCE JE DŮLEŽITĚJŠÍ NEŽ ŠÍŘKA PÁSMA Od rychlosti 4 Mb/s se už webové stránky nebudou nahrávat svižněji. Daleko důležitější proto je, jak efektivně bude server poskytovat data. Eliptická křivka: Náhodná čísla, použitá k šifrování na webu, jsou vypočítávána na základě dvou propojených bodů. P R = P + Q Čas nahrávání (ms) 3 500 3 000 2 500 2 000 DOBA POTŘEBNÁ K NAČTENÍ STRÁNKY V ZÁVISLOSTI NA RYCHLOSTI PŘIPOJENÍ 1 500 ŠIFROVÁNÍ VYBÍRÁ SERVER Při použití HTTPS rozhoduje o použitém protokolu server. Prakticky všechny servery přitom umí komunikovat přes děravé SSL 3.0 nebo TLS 1.0, pouze některé však zvládnou komunikovat přes bezpečnější TLS 1.1 nebo TLS 1.2. Bezpečnější SSL V2.0 = 26,9 % = 99,7 % SSL V3.0 TLS V1.0 = 99,3 % TLS V1.1 = 15,4 % TLS V1.2 = 17,8 % 1 000 Čas nahrávání (ms) 3 500 3 000 2 500 2 000 1 500 1 000 1 2 3 4 5 6 7 8 9 10 Šířka pásma Mb/s DOBA POTŘEBNÁ K NAČTENÍ STRÁNKY V ZÁVISLOSTI NA LATENCI (REAKČNÍ DOBĚ) SERVERU 200 180 160 140 120 100 80 60 40 20 Latence (ms) prostřednictvím kterých může získat přístup k šifrovanému obsahu komunikace. Podobně bylo kompromitováno i šifrování založené na generování náhodných čísel pomocí eliptických křivek Dual_EC_DRBG. Hodnoty ležící na těchto křivkách byly využívány ke generování náhodných čísel pro páry asymetrických klíčů. Podezření dopadlo i na další křivky, které byly uvolněny americkým úřadem pro standardizaci (NIST). Simon Josefsson proto navrhl IETF jinou eliptickou křivku 25519, která nepochází od NIST. Pokud by byla použita pro TLS 1.3, mohla by se zadní vrátka nasazená NSA zase uzavřít. Nová verze TLS ale sama o sobě nestačí: existuje totiž podezření, že i šifrovací metoda RC4, která je rovněž používána v HTTPS, byla NSA upravena tak, aby bezpečnostní úřad získal přístup k šifrovanému obsahu. RC4 je součástí aktivních bezpečnostních protokolů SSL 2.0 a TLS 1.2 a je použito přibližně v polovině šifrovaného webového provozu. Výsledkem je, že s RC4 již není možné počítat pro TLS 1.3. V současné implementaci bezpečnostní vrstvy rozhoduje server, který bezpečnostní protokol bude použit. Zatímco aktuální verze internetových prohlížečů Chrome a Internet Explorer mají implementovanou novější verzi TLS 1.2, většina webových serverů používá zastaralé metody SSL 3.0 nebo TLS 1.0. Není přitom žádným tajemstvím, že obě tyto technologie mají bezpečnostní díry, které mohou útočníci využít. Proto chce jeden z návrhů na vylepšení HTTP 2.0 situaci obrátit: v budoucnosti by to měl být právě internetový prohlížeč uživatele, kdo rozhodne, který bezpečnostní protokol bude při přenosu dat použit. To by nakonec znamenalo, že by sám uživatel mohl rozhodnout, jak bezpečné jeho HTTPS spojení bude. Ucpání děr v SSL/TLS Současné typy útoků na TLS spočívají v tom, že jsou odesílané pakety zachyceny a/nebo zmanipulovány. Významnou roli přitom hraje Message Authentication Code (MAC), který je přenášen s každým paketem při komunikaci využívající Session key. MAC je tvořen z hash hodnoty datových paketů a ze Session key. Příjemci paketů pomáhá MAC určit, zda pocházejí od správného odesílatele. V současné době využívají protokoly TLS i SSL postup MAC then encrypt, což znamená, že je ke generování MAC použita hash hodnota nezašifrovaného paketu. Jako bezpečnější je proto v návrhu na upgrade TLS použit opačný postup Encrypt then MAC. Generování MAC z hash hodnoty zašifrovaného paketu podstatně ztíží útočníkům práci. Jestli však všechna tato opatření budou dostatečnou ochranou před špehováním tajných služeb, to není zatím vůbec jisté. Opravují totiž pouze v současnosti známé problémy a bezpečnostní díry. V každém případě se do hry vrátilo téma povinného šifrování HTTP 2.0, které bude v rámci IETF jistě ještě hodně diskutováno. Zvýšení výkonu Jestliže se na něčem všichni členové IETF shodnou, pak je to nutnost nasazení technologií, které odstraní výkonnostní problémy HTTP 1.1. Základem je protokol SPDY od Googlu, který v jeho aktuální verzi 3 již podporují všechny moderní prohlížeče, jako je Chrome, Internet Explorer, Firefox a Opera. Chybí pouze Safari od Applu. SPDY řeší strukturální nedostatky HTTP 1.1, kvůli kterým musí server vytvořit samostatné TCP spojení pro každý jednotlivý element webu. Kvůli tomu je spuštěno hned několik paralelních spojení, což opět 32 01/2014 CHIP.CZ

PLACENÁ INZERCE

SPDY: Aktuální prohlížeče, jako třeba Google Chrome, mají již tento protokol, který se stal základem pro HTTP 2.0, implementovaný. PAKETOVÉ PROTOKOLY TCP A UDP HTTP 1.1 používá pomalejší TCP s kontrolou doručení paketů. Jelikož HTTP 2.0 převezme některé úlohy TCP, mohl by být teoreticky použit rychlejší protokol UDP. TCP UDP KONTROLA ZTRÁTY PAKETŮ URČOVÁNÍ POŘADÍ PAKETŮ DETEKCE CHYB OPRAVA CHYB VELIKOST HLAVIČKY 20 60 bajtů 8 bajtů LATENCE (RYCHLOST REAKCE) pomalá rychlá VLASTNÍ REŽIE (OVERHEAD) velká malá IPV6 Další významnou změnou, která se v současnosti na internetu odehrává, je přechod na novou verzi komunikačního protokolu IPv6. Přechod z IPv4 je nezbytný především z důvodu obrovského nárůstu počtu zařízení připojených k internetu, kterým je třeba přidělovat nové IP adresy. Adresní prostor IPv4 je oproti IPv6 výrazně omezený, proto již v některých regionech došlo k vyčerpání dostupných IP adres. Protokol IPv6 je také vhodnější pro vyšší přenosové rychlosti a související moderní síťové služby, jako jsou videokonference nebo streamování videa. Současné operační systémy, počítače i domácí routery uživatelů internetu jsou na IPv6 již připraveny, hlavní roli při rozšiřování nového internetového protokolu ovšem budou hrát poskytovatelé internetového připojení, kteří musí investovat do upgradu svých technologií. V současné době je podíl komunikace po IPv6 v celosvětovém internetu naprosto minimální. Podle statistik Googlu dosáhnul v září 2013 hranice 2 %, což ovšem znamená meziroční nárůst na více než dvojnásobek. Nejvíce provozu po IPv6 proudí ve Švýcarsku (9 %), v Rumunsku (8 %) a ve Francii (5 %). V České republice využívá IPv6 přibližně 1,5 % internetové komunikace. Nasazování IPv6 má i své odpůrce, kteří poukazují na zbytečně veliký rozsah IPv6 adres a s tím související problémy se správou, stejně jako na nedořešené otázky bezpečnosti a odolnosti proti útokům hackerů. ZDROJ: MICROSOFT vede ke zbytečnému datovému provozu a potenciálně také k tzv. Head-of-Line-Blocking efektu. Při Head-of-Line-Blockingu dojde k pozastavení zpracování datových paketů, jelikož pakety přicházejí vždy v takovém pořadí, v jakém jsou požadovány, bez ohledu na to, zda je požadavek chybný nebo jestli jeho zpracování trvá příliš dlouho. A co víc, HTTP spojení přichází vždy ze strany klienta. Proto se musí prohlížeč neustále dotazovat, zda se obsah webové stránky nezměnil. Samotný server nemůže poslat žádné aktualizace. Na druhou stranu, pokud je jednou navázáno HTTP 2.0 spojení, mohou internetový prohlížeč i server nezávisle na sobě otevřít své vlastní streamy pro zasílání datových paketů. V případě multiplexování se to děje paralelně a ve stejném čase. V porovnání s HTTP 1.1 může verze 2.0 umožnit paralelní přenosy v rámci jediného TCP spojení. To zcela zásadně redukuje nároky na výkon serveru během nahrávání stránek, kdy navíc server musí odbavit mnoho současných požadavků internetových prohlížečů. Jednotlivé rámce mohou být navíc označeny různou prioritou, takže může server nebo prohlížeč příslušným způsobem upravit pořadí jejich dekódování. Díky tomu už Head-of-Line-Blocking vůbec nehrozí. A co víc, server s HTTP 2.0 může posílat internetovému prohlížeči Push zprávy. V HTTP 2.0 je optimalizována také hlavička paketů, která je ve verzi 1.1 přenášena v textové formě a bez komprese. HTTP 1.1 hlavičky jsou kvůli tomu zbytečně dlouhé a před zpracováním je třeba je převést do binárního kódu. HTTP 2.0 hlavičky paketů komprimuje a rovnou je posílá v binárním kódu. Tím se zmenší především velikost prvního rámce datového paketu, který pak může být zpracován podstatně rychleji. Výsledkem je nižší latence, tedy kratší doba odezvy. Mnoho funkcí HTTP 1.1 a TCP je vzájemně provázáno, jako to ukazuje příklad paralelizace, kdy protokol TCP nabízí funkce, které v HTTP chybí. TCP se stará o to, aby byly ztráty během datových přenosů detekovány a opraveny a rovněž určuje pořadí paketů. Tyto kontrolní funkce však opět zvyšují velikost TCP hlavičky a s tím i latenci spojení. Další prodlevy způsobuje i způsob navázání spojení přes TCP, které využívá třístupňový Handshake. Některé z úloh, které řeší protokol TCP, však zároveň brzdí HTTP 2.0, respektive HTTP 2.0 je nově přebírá. Namísto řazení datových paketů podle TCP určuje nově pořadí jejich zpracování prioritizace rámců. Google proto doporučuje použití rychlejšího, avšak nespolehlivého UDP (User Datagram Protocol) jako transportního protokolu s drobnou modifikací: Google QUIC (Quick UDP Internet Connections) je sice založen na UDP, ale rozšířen o vestavěnou opravu chyb. Opravné bloky, zasílané prostřednictvím QUIC, dělají z rozpoznávání chyb v TCP přebytečnou funkci. TCP také může opustit princip navazování spojení pomocí komplikované procedury Handshake, jelikož HTTP 2.0 vytvoří stream mezi serverem a internetovým prohlížečem, prostřednictvím kterého probíhá vzájemná komunikace. Z dlouhodobého hlediska nechce Google TCP zcela nahradit, ale integrovat do něj funkce z QUIC. Přechod přitom může být podobně hladký a jednoduchý jako v případě upgradu z HTTP 1.1 na 2.0. Internetový prohlížeč prostě dostane novou aktualizaci, jejíž součástí bude i podpora HTTP 2.0. Prohlížeč se pak bude webových serverů automaticky ptát, zda podporují HTTP 2.0. Pokud ano, můžete vyrazit plnou parou vpřed, vstříc internetu budoucnosti. V opačném případě využije komunikace protokol HTTP 1.1. AUTOR@CHIP.CZ 34 01/2014 CHIP.CZ