Co je to RFC 9421

Jedná se o způsob, jakým podepisovat a ověřovat HTTP požadavky.

Běžným standardem v ověřování je hlavička Authorization, kde můžeme mít jakýkoliv token.

V rámci nového standardu RFC 9421 je možné podepisovat jednotlivé komponenty požadavku. Celý standard se odráží na dvou nových hlavičkách v požadavku, Signature a Signature-Input. V rámci Signature-Input hlavičky definujeme jednotlivé komponenty, které vstupují do podpisu. Tyto komponenty jsou pak podepsány privátním klíčem, čímž vzniká samotný podpis. Ten se následně posílá v hlavičce Signature. Server pak podpis pomocí veřejného klíče ověřuje. Neověřuje přitom pouze samotný podpis, podle standardu je kontrolována také struktura podpisu, jeho platnost a další parametry.

Co se historie týče, jedná se o starší koncept. První zmínky se začaly objevovat v roce 2013 s dalšími iteracemi v následujících letech. Jako oficiální standard pod číslem 9421 byl uznán v roce 2024.

Podpora v prohlížečích

Podpora v prohlížečích je poměrně rozdílná. Zatímco v novějších prohlížečích na bázi Chromium funguje bez problému, Firefox a Safari tyto hlavičky pro automatický podpis nativně nepodporují. Je třeba brát v potaz také Electron a podobné multiplatformní frameworky, které využívají Chromium. Ne každá verze frameworku Electron totiž obsahuje nejnovější verzi Chromium.

Proč existující přístupy nestačí?

Většina moderních API dnes spoléhá na hlavičku Authorization: Bearer <JWT>. Tento přístup je skvělý pro autentizaci (ověření identity odesílatele a jeho oprávnění), ale v momentě, kdy požadavek putuje sítí, naráží na dva zásadní bezpečnostní limity:

1. nijak nechrání integritu celého HTTP balíčku,
2. sám o sobě nebrání opakovanému odeslání stejné zprávy.

Úprava dat během přenosu

Samotný JWT token nijak neověřuje obsah zbytku HTTP požadavku. Pokud by útočník dokázal komunikaci odchytit a modifikovat (např. přes kompromitovanou proxy nebo v rámci lokální sítě), může vzít legitimní a platný JWT token, ale kompletně přepsat tělo požadavku - například změnit cenu produktu na 1.

Pro server bude takový požadavek stále validní. Ověří podpis v JWT, potvrdí identitu uživatele a objednávku zpracuje, ovšem s podvrženými daty.

Opakování požadavku

I v případě, že je komunikace plně šifrovaná pomocí HTTPS a útočník do dat nevidí, může způsobit škody pouhým zaznamenáním a opětovným odesláním síťového balíčku.

Uživatel klikne na tlačítko Dokončit objednávku. Útočník tento zašifrovaný požadavek zachytí a v nezměněné podobě ho pošle na API server ještě pětkrát. Server v každém z nich uvidí platný token před vypršením expirace a vytvoří pět identických objednávek namísto jedné.

Jak tyto zranitelnosti řeší RFC 9421?

Tento standard funguje jako doplňková vrstva ochrany, která se zaměřuje na integritu a nepopíratelnost zpráv:

1. Garance integrity: Do podpisové základny se zahrnou konkrétní komponenty, jako je @path nebo hlavička s kryptografickým hashem těla zprávy (Content-Digest). Pokud útočník změní jakoukoliv hodnotu v payloadu, hash přestane odpovídat, podpis se stane neplatným a server požadavek okamžitě odmítne.
2. Ochrana proti replay útokům: Součástí metadat podpisu (@signature-params) je časové razítko created a unikátní identifikátor nonce. Server kontroluje, zda požadavek není příliš starý a zda toto ID již nezpracoval. Pokud by se útočník pokusil časové razítko v hlavičce přepsat, zneplatní tím samotný kryptografický podpis.

Nutné detaily

Co přesně v požadavku podepisujeme?

Komponenty jsou konkrétní kousky HTTP požadavku, ze kterých poskládáme textový řetězec a ten následně digitálně podepíšeme. Nemusíme (a často ani nechceme) podepisovat celý požadavek, ale jen data, u kterých chceme mít jistotu, že je nikdo po cestě nezměnil.

Standard RFC 9421 tyto komponenty dělí na dvě části:

1. HTTP pole: Klasické hlavičky (např. content-type, host, authorization). Pozor, podle specifikace se pro účely podpisu píší vždy malými písmeny!
2. Odvozené komponenty: Speciální hodnoty, které začínají zavináčem (@method, @path, @query). Tyto hodnoty se v požadavku nenacházejí jako samostatné hlavičky, ale server si je sám odvodí z kontextu (např. z metody POST nebo URL adresy).

Symetrický vs. asymetrický podpis

Standard RFC 9421 je flexibilní a podporuje oba základní kryptografické přístupy. Výběr závisí primárně na architektuře systému.

Symetrický podpis (HMAC)

Při symetrickém přístupu sdílí klient i server jedno společné tajemství (tzv. shared secret). Klient tímto klíčem vygeneruje podpis (např. pomocí algoritmu hmac-sha256) a server stejným klíčem ověří, zda podpis sedí.

• Výhody: Výpočetně velmi rychlé a implementačně jednoduché.
• Nevýhody: Obě strany musí klíč znát. Pokud útočník zkompromituje server, získá klíč, kterým může podpisy i sám generovat.
• Použití: Ideální pro interní architekturu, například pro komunikaci mezi microservices v uzavřené síti, kde je distribuce tajných klíčů plně pod kontrolou.

Asymetrický podpis (Ed25519, ECDSA)

Asymetrický přístup využívá dvojici klíčů - privátní a veřejný. Klient podepisuje komponenty svým privátním klíčem, který nikdy nikomu neposílá ani nesdílí. Serveru (nebo komukoliv jinému) stačí k ověření pouze veřejný klíč klienta.

• Výhody: Vysoká bezpečnost a princip tzv. nepopíratelnosti (non-repudiation). I když někdo kompromituje ověřovací server, získá pouze veřejný klíč, se kterým nový platný podpis nevygeneruje.
• Nevýhody: Vyšší výpočetní náročnost oproti HMAC.
• Použití: Kritické pro veřejná API, integrace s třetími stranami nebo webhooky (např. platební brány), kde nelze s klientem bezpečně sdílet jedno společné tajemství.