Signed HTTP Exchanges (SXG) se jako návrh standardu objevil na půdě IETF před několika málo dny. Popisuje, jak může web server svou odpověď poslat včetně elektronického podpisu. Tím vznikne ucelený dokument, který je pak možné přenášet na různá místa a zachovat jeho autentičnost. Zatím jde o velký experiment, proto je jeho podpora na různých stranách omezená.
Cílem je umožnit tvůrcům obsahu, aby tímto způsobem přerušili pevnou vazbu zdroj – obsah. Původní dokument se pak může šířit různými cestami a být doručován například pomocí kešovacího serveru nebo být umístěn na různých záložních serverech. Stále půjde o stejný dokument zajištěný původním podpisem.
Výhodou takového postupu navíc je, že je odolný proti útokům na samotný přenosový protokol. Informaci o autenticitě nese samotný dokument bez ohledu na to, jakými cestami jej klient získal. Útočníkovi tak nepomůže například downgrade attack, při kterém klienta donutí přejít z HTTPS na HTTP.
Princip v kostce: tvůrce vytvoří dokument, klient si jej pak stáhne z libovolného zdroje a bude k němu přistupovat, jako by přicházel z původního serveru.
Podpis v HTTP hlavičce
Signed HTTP Exchange je součástí většího rozpracovaného standardu Web Packages (IETF draft), který umožňuje balení stránek do kompaktního formátu. Takto je možné distribuovat obsah v nezměněném formátu. Podle návrhu může server ke své odpovědi přibalit také elektronický podpis v podobě HTTP hlavičky.
Hlavička má přesně definovaný formát a kromě samotného podpisu také obsahuje informace o expiraci podpisu, použitém veřejném klíči či dalších hlavičkách důležitých pro integritu dokumentu. Dotaz na obsah https://example.com/resource.html tak může vést k následující hlavičce:
Signature: sig1; sig=*MEUCIQDXlI2gN3RNBlgFiuRNFpZXcDIaUpX6HIEwcZEc0cZYLAIga9DsVOMM+g5YpwEBdGW3sS+bvnmAJJiSMwhuBdqp5UY=*; integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; cert-url="https://example.com/oldcerts"; cert-sha256=*W7uB969dFW3Mb5ZefPS9Tq5ZbH5iSmOILpjv2qEArmI=*; date=1511128380; expires=1511733180, sig2; sig=*MEQCIGjZRqTRf9iKNkGFyzRMTFgwf/BrY2ZNIP/dykhUV0aYAiBTXg+8wujoT4n/W+cNgb7pGqQvIUGYZ8u8HZJ5YH26Qg=*; integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; cert-url="https://example.com/newcerts"; cert-sha256=*J/lEm9kNRODdCmINbvitpvdYKNQ+YgBj99DlYp4fEXw=*; date=1511128380; expires=1511733180, srisig; sig=*lGZVaJJM5f2oGczFlLmBdKTDL+QADza4BgeO494ggACYJOvrof6uh5OJCcwKrk7DK+LBch0jssDYPp5CLc1SDA=* integrity="digest/mi-sha256"; validity-url="https://example.com/resource.validity.1511128380"; ed25519key=*zsSevyFsxyZHiUluVBDd4eypdRLTqyWRVOJuuKUz+A8=* date=1511128380; expires=1511733180, thirdpartysig; sig=*MEYCIQCNxJzn6Rh2fNxsobktir8TkiaJYQFhWTuWI1i4PewQaQIhAMs2TVjc4rTshDtXbgQEOwgj2mRXALhfXPztXgPupii+=*; integrity="digest/mi-sha256"; validity-url="https://thirdparty.example.com/resource.validity.1511161860"; cert-url="https://thirdparty.example.com/certs"; cert-sha256=*UeOwUPkvxlGRTyvHcsMUN0A2oNsZbU8EUvg8A9ZAnNc=*; date=1511133060; expires=1511478660,
Vidíte, že podpisů může být více a mohou používat veřejné klíče z různých certifikátů. Ty ovšem musí obsahovat rozšíření CanSignHttpExchanges, které zatím nabízí jen autorita Digicert. SXG tedy nevyzkoušíte s libovolným certifikátem, protože bez tohoto příznaku jej budou prohlížeče považovat za nevalidní.
Hlavičky i data samotná jsou zabalena v datovém formátu CBOR (Concise Binary Object Representation) podle RFC 7049. Ten je příbuzný formátu JSON, ale je úspornější. Výsledný datový balíček je opatřen zmíněným podpisem.
Pokud máte zájem s SXG experimentovat, můžete prozkoumat experimentální nástroje, které jsou k dispozici na GitHubu. Svou implementaci už nasadil také Cloudflare, který o ní má na svém webu rozsáhlý článek.
Co s tím udělá prohlížeč
Tradičně se při získávání obsahu musí prohlížeč spolehnout na původní zdroj – tedy na URL v adresním řádku. Uživatel se přesvědčí, že je na správné adrese, prohlížeč naváže šifrované spojení ověřené platným důvěryhodným HTTPS spojením a uživatel má jistotu, že zobrazuje obsah vydaný původním zdrojem.
Při použití SXG ale prohlížeč může být nasměrován na úplně jiný server, na kterém je stejný obsah. Za normálních okolností tento server nedokáže původní obsah servírovat z původní domény, takže vazba na vydavatele se ztrácí. V případě SXG je ale vazba pevně zachována pomocí elektronického podpisu, takže prohlížeč může k takto ověřenému obsahu přistupovat, jako by pocházel z původního zdroje.
Prohlížeč tak po načtení stránky například v adresním řádku zobrazí původní adresu. Stejně tak se bude chovat ke všem bezpečnostním opatřením, odesílaným hlavičkám nebo třeba cookies. Ty bude možné zpracovávat bez omezení běžným způsobem.
Chrome a Opera už umí
Vývojáři nedávno potřebný kód zavedli do jádra Blink na všech platformách. Chrome potřebné vlastnosti přidal do aktuální verze 71. Podporu obsahuje také prohlížeč Opera, ale to je zatím vše. Vývojáři prohlížeče Edge zatím s implementací váhají a vyčkávají na stabilizaci standardu a další dění.
Mozilla současnou podobu standardu považuje za škodlivou a nelíbí se jí stav, kdy klient zobrazí obsah, aniž by přitom kontaktoval původní zdroj. Zároveň upozorňuje na to, že distribuující server má přístup k obsahu. Vývojáři si jsou ale vědomi toho, že existují případy, kdy dává nasazení podobné technologie smysl.
Chrome ve verzi 71 už ale umí SXG využít, můžete vyzkoušet experiment na Androidu. Do vyhledávacího pole vložte „christmas greens“ a dostanete se na mobilní AMP stránku, která bude mít v adresním řádku původní URL a ne tu od kešovacího serveru Google.
Demo využívající SXG a AMP v Chrome 71 na Androidu
Podepsaný obsah
Původně je tato technika navrhována jako doplněk k distribuci obsahu pomocí CDN nebo třeba AMP (viz seriál na Lupě). Princip SXG jde ale výrazně dále. Umožňuje třetí straně předat informaci o autentičnosti získaného dokumentu.
Za normálních okolností totiž klientova důvěra závisí na HTTPS spojení, které se serverem navázal. Nedokáže však už později nikomu dalšímu sdělit, že daný obsah pocházel z původního zdroje. To je problém například u archivování informací z webu. Pokud dokument sám ponese důvěryhodný podpis, bude jeho původ moci kdokoliv ověřit.
V budoucnu by to mohlo přinést spoustu zajímavých možností jako je výměna obsahu mezi uživateli, jednodušší čtení offline nebo třeba bezproblémovější distribuci obsahu pomocí záložních či archivačních serverů.
