it-swarm-eu.dev

Jaký mechanismus výměny klíčů by měl být použit v TLS?

Existuje mnoho mechanismů výměny klíčů, které lze použít v TLS. Mezi nimi jsou RSA, ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA a další. Které z nich jsou kryptograficky bezpečnější a lze je použít pro zabezpečení připojení k webové stránce?

31
Andrei Botalov

Výměnu klíčů můžete použít (jako součást sady šifry), pouze pokud se shoduje typ klíče serveru a certifikát. Chcete-li to vidět podrobně, pojďme se podívat na sady šifry definované v specifikace TLS 1.2 . Každá sada šifry definuje algoritmus výměny klíčů, jakož i následně používané algoritmy symetrického šifrování a kontroly integrity; soustředíme se zde na klíčovou část výměny.

  • RSA: výměna klíče funguje šifrováním náhodnou hodnotou (zvolenou klientem) veřejným klíčem serveru. To vyžaduje, aby veřejný klíč serveru byl klíčem RSA a , aby certifikát serveru nezakazoval šifrování (hlavně prostřednictvím rozšíření certifikátu „Key Usage“: pokud je toto rozšíření přítomno, musí obsahovat příznak „keyAgree“).

  • DH_RSA: výměna klíče je statický Diffie-Hellman : veřejný klíč serveru musí být klíč Diffie-Hellman; tento certifikát musí být navíc vydán certifikační autoritou, která sama používala klíč RSA (klíč CA je klíč, který byl použit k podpisu certifikátu serveru).

  • DH_DSS: jako DH_RSA, kromě toho, že CA použil klíč DSA.

  • DHE_RSA: výměna klíčů je pomíjivý Diffie-Hellman : server dynamicky generuje veřejný klíč DH a odešle jej klientovi; server také podepisuje to, co posílá. Pro DHE_RSA musí být veřejný klíč serveru typu RSA a jeho certifikát musí být vhodný pro podpisy (rozšíření o použití klíče, pokud existuje, musí zahrnovat příznak digitalSignature).

  • DHE_DSS: jako DHE_RSA s tou výjimkou, že serverový klíč má typ DSA.

  • DH_anon: neexistuje certifikát serveru. Server používá klíč Diffie-Hellman, který mohl být dynamicky vygenerován. Šifrovací sady „anon“ jsou náchylné k předstírání útoků (včetně, ale nejen) „Muž ve středu“ ), protože jim chybí jakákoli autentizace na serveru. Obecně byste neměli používat šifru „anon“.

Algoritmy výměny klíčů, které používají kryptografii eliptické křivky, jsou uvedeny v jiný RFC a navrhují následující:

  • ECDH_ECDSA: jako DH_DSA, ale s eliptickými křivkami: veřejný klíč serveru musí být klíčem ECDH v certifikátu vydaném CA, který sám používal veřejný klíč ECDSA.

  • ECDH_RSA: jako ECDH_ECDSA, ale vydávající CA má klíč RSA.

  • ECDHE_ECDSA: server odešle dynamicky generovaný EC Diffie-Hellman klíč a podepíše jej vlastním klíčem, který musí mít typ ECDSA. Toto je ekvivalentní DHE_DSS, ale s eliptickými křivkami pro část Diffie-Hellman i pro podpisovou část.

  • ECDHE_RSA: jako ECDHE_ECDSA, ale veřejný klíč serveru je klíč RSA, který se používá k podpisu dočasného eliptického křivky Diffie-Hellman.

  • ECDH_anon: sada „anonů“ s dynamickou eliptickou křivkou Diffie-Hellman.


Co si tedy vyberete pro web? Vaše hlavní omezení jsou:

  • Chcete šifrovací sadu, kterou podporuje většina klientů; v praxi to vylučuje kryptografii eliptických křivek (eliptické křivky jsou mocně chladné, ale v terénu ještě nejsou dobře podporovány - vezměte v úvahu, že podle gs.statcounter , od září 2011, 40% klientů systémy stále používají Windows XP a téměř 5% používá IE 7.0).

  • Chcete sadu šifrů, která je kompatibilní s typem klíče a certifikátu serveru. To zase záleží na tom, co CA přijme (CA, který vám certifikát prodal). 99,9% času, to znamená RSA. Každý dělá RSA. Diffie-Hellmanovy klíče v certifikátech a podpisy DSA byly dříve propagovány NIST (americká federální agentura USA, která se těmito záležitostmi zabývá), protože tam byl patent na RSA; ale tento patent vypršel v roce 2000. Diffie-Hellman (jako součást certifikátů) je specifikován ANSI X9.42 , což je standard, který není zdarma (takže vývojáři opensource free-time se zdráhají implementovat) a ne všechno jasné. Takže nikdo opravdu nepoužívá Diffie-Hellman v certifikátech. DSA je více podporován (jeho definující standard je zdarma a zcela čitelný), ale ne do té míry, že není neanecdotický ve srovnání s RSA.

  • Nechcete používat sadu „anon“, protože je to nezabezpečené proti aktivním útočníkům a většina klientských prohlížečů má ve výchozím nastavení sady „anon“ deaktivované.

Takže volba je v podstatě mezi „RSA“ a „DHE_RSA“. Ten může mít o něco vyšší výpočetní náklady, i když byste potřebovali alespoň několik stovek nových připojení za sekundu, abyste skutečně viděli rozdíl (trvám na „novém“: protože TLS zahrnuje zkrácený handshake, který může stavět na výměna klíčů předchozího spojení, ke skutečné výměně klíčů s asymetrickou kryptografií dojde pouze jednou za nový klientský prohlížeč v poslední minutě). V praxi tedy neexistuje žádný měřitelný rozdíl v zatížení CPU mezi RSA a DHE_RSA.

DHE_RSA nabízí něco známého jako Perfect Forward Secrecy , pompézní jméno pro následující vlastnost: pokud je váš server důkladně napaden, do okamžiku, kdy útočník získá kopii soukromého klíče serveru, pak také být schopen dešifrovat minulé relace TLS (které zaznamenal), pokud tyto relace používaly RSA, zatímco nebude moci tak učinit, pokud tyto relace použijí DHE_RSA. V praxi, pokud by útočník mohl ukrást váš soukromý klíč, pravděpodobně by si mohl přečíst číslo 10000 kreditních karet ve vaší databázi stránek, takže není příliš důvod, proč by měl dokonce obtěžovat nahrávání a dešifrování předchozích relací, protože by to přineslo pouze tucet navíc čísla nebo tak. PFS je matematicky elegantní, ale přetvořený. Pokud je to stále šikovná zkratka a může to udělat velký dojem na slabě smýšlející, jako součást promyšlené kampaně na styk s veřejností.


Shrnutí: použijte DHE_RSA.

62
Thomas Pornin