TLS a jeho neduhy
Transport Layer Security (TLS) je komunikační protokol, který je následovníkem staršího protokolu Secure Sockets Layer (SSL). TLS zajišťuje jak šifrování komunikace, tak i autentizaci jedné či obou stran. Přestože TLS řeší některé problémy a nedostatky SSL, některé věci řešit nemůže už z principu jeho návrhu.
Jedním z takových problémů nastává při využití možnosti ověřovat totožnost klienta (což se – mimo jiné i z tohoto důvodu – zatím používá zřídka, standardně se ověřuje jen server). Model PKI (Public Key Infrastructure – infrastruktura veřejného klíče) totiž počítá primárně s tím, že nějaká certifikační autorita vystaví/podepíše certifikát k veřejnému klíči, jeho soukromý klíč drží uživatel.
Problém je, že získání osobního certifikátu není úplně jednoduché, bývá to zpoplatněno a v certifikátu jsou pak obsaženy osobní údaje, což může omezovat ochotu uživatelů tyto certifikáty používat k ověřování své totožnosti (server mnohdy tyto údaje nepotřebuje – stačí mu jen vědět, že se připojil oprávněný majitel uživatelského účtu).
Vzniká TLS-OBC a následně TLS Channel ID
K řešení tohoto problému začalo už v roce 2011 u firmy Google vznikat rozšíření nazvané TLS Origin-Bound Certificates (TLS-OBC), tedy certifikáty vázané na zdroj; myšlen je samozřejmě informační zdroj (čili server). Tvůrci to zamýšleli tak, aby se z rozšíření stal obecný otevřený standard, sepsali proto jeho specifikaci do draftu RFC, který byl následně aktualizován. Tento draft ovšem zůstal draftem, expiroval a na protokolu se dále pracovalo, než vznikl nový draft, tentokrát už pod názvem TLS Channel ID.
Princip je ten, že si klient generuje dvojici klíčů (soukromý a veřejný) pro každý server, na který se připojuje. Učiní tak až v okamžiku, kdy to poprvé potřebuje – což je logické, ale je potřeba si uvědomit, že se tím připojení poněkud zdrží, v závislosti na množství dostupné entropie. Veřejný klíč je považován za identifikátor kanálu (Channel ID).
Klíč jsou založeny na eliptických křivkách, specifikace počítá s křivkou P-256 schválenou v rámci FIPS 186-3.
Během sestavování TLS relace mezi klientem a serverem (handshaking) klient ve zprávě ClientHello pošle typ rozšíření channel_id. Po potvrzení serverem klient zkontroluje, že server nabízí dostatečně silné šifry (min. 80 bitů, což je v dnešní době požadavek velmi mírný) a pošle zprávu EncryptedExtensions.
V této zprávě je obsažen parametr Q z veřejného klíče a podpis speciálního řetězce (doplněného úvodními zprávami klienta a serveru) soukromým klíčem. Protože by se po prvotním vygenerování už neměly klíče měnit, identifikátor kanálu „přežije“ do dalších relací a lze ho tedy využívat jako perzistentní identifikaci.
Protokol nijak neřeší, jakým způsobem klient a server s identifikátorem naloží, tedy jak ho využijí k ověřování totožnosti klienta/uživatele. Například se může po přihlášení uživatele (nějakým z běžných způsobů, včetně vícefaktorových) vytvořit cookie a spojit na straně serveru s identifikátorem kanálu. Při každém požadavku se pak ověří, jestli identifikátor souhlasí. Podobně lze postupovat i pro tokeny OAuth a další metody.
Token Binding Protocol
Posledním „výkřikem“ v této oblasti je Token Binding Protocol (TBP), na němž se intenzivně pracuje od roku 2014 a aktuálně se nachází ve fázi 11. draftu RFC. Ten vychází z Channel ID a řeší záležitost komplexně, právě i včetně autentizačních tokenů. Podíváme se na něj v samostatném článku.
