Ověření pojmenovaných entit na základě DNS - DNS-based Authentication of Named Entities

Internetová bezpečnost
protokoly
Správa klíčů
Aplikační vrstva
Domain Name System
Internetová vrstva

Ověření pojmenovaných entit na základě DNS (DÁN) je Internetová bezpečnost povolit protokol X.509 digitální certifikáty, běžně používané pro Zabezpečení transportní vrstvy (TLS) názvy domén použitím Rozšíření zabezpečení systému doménových jmen (DNSSEC).[1]

Navrhuje se v RFC  6698 jako způsob ověřování entit klienta a serveru TLS bez certifikační autority (CA ). Je aktualizován s provozními pokyny a pokyny k nasazení v RFC  7671. Specifické použití aplikace DANE je definováno v RFC  7672 pro SMTP a RFC  7673 pro použití DANE s Záznamy služeb (SRV).

Odůvodnění

Šifrování TLS / SSL je aktuálně založeno na certifikátech vydaných serverem certifikační autority (CA). V posledních několika letech utrpěla řada poskytovatelů CA vážné potíže narušení bezpečnosti, umožňující vydávání certifikátů pro známé domény těm, kteří tyto domény nevlastní. Důvěřovat velkému počtu certifikačních autorit může být problém, protože každý porušený certifikační úřad může vystavit certifikát pro libovolný název domény. DANE umožňuje správci názvu domény certifikovat klíče používané v klientech nebo serverech TLS dané domény jejich ukládáním do systému DNS (Domain Name System). Aby DANE fungoval, musí být záznamy DNS podepsány pomocí DNSSEC.

DANE navíc umožňuje vlastníkovi domény určit, která CA má povoleno vydávat certifikáty pro konkrétní prostředek, což řeší problém jakékoli CA, která je schopna vydávat certifikáty pro jakoukoli doménu.

DANE řeší podobné problémy jako:

Transparentnost certifikátu
Zajištění toho, aby podvodní CA nemohli vydávat certifikáty bez povolení držitele domény, aniž by byli detekováni
Autorizace certifikační autority DNS
Omezení, které CA mohou vydávat certifikáty pro danou doménu

Na rozdíl od DANE však mají tyto technologie širokou podporu prohlížečů.

Šifrování e-mailů

Až donedávna neexistoval široce implementovaný standard pro šifrovaný e-mail převod.[2] Odesílání e-mailů je bezpečnostní agnostik; tady není žádný URI schéma pro označení zabezpečeného SMTP.[3] V důsledku toho většina e-mailů doručovaných prostřednictvím protokolu TLS používá pouze oportunistické šifrování.[4] Protože DNSSEC poskytuje ověřené odmítnutí existence (umožňuje resolveru ověřit, že určitý název domény neexistuje), DANE umožňuje přírůstkový přechod na ověřený, šifrovaný SMTP bez jakýchkoli dalších externích mechanismů, jak je popsáno v RFC  7672. Záznam DANE označuje, že odesílatel musí používat TLS.[3]

Kromě toho existuje koncept pro použití DANE na S / MIME,[5] a RFC  7929 standardizuje vazby pro OpenPGP.[6]

Podpěra, podpora

Aplikace

  • Google Chrome nepodporuje DANE, protože Google Chrome si přeje vyloučit použití 1024bitové RSA v prohlížeči[7] (DNSSEC dříve používal 1024bitový kořen podepsaný RSA,[8] a mnoho zón je stále podepsáno 1024bitovým RSA). Podle Adama Langleyho byl kód napsán[9] a ačkoli dnes není v prohlížeči Chrome,[10] zůstává k dispozici ve formě doplňku.[11]
  • Mozilla Firefox (před verzí 57) má podporu prostřednictvím doplňku.[12]
  • GNU Privacy Guard Umožňuje načítání klíčů pomocí OpenPGP DANE (--auto-key-locate). Nová možnost — print-dane-records. (verze 2.1.9)[13]

Servery

Služby

Knihovny

TLSA RR

TLSA RR (záznam o prostředku) pro službu je umístěn pod názvem DNS, který určuje omezení certifikátu, která by měla být použita pro služby na určitém portu TCP nebo UDP. Alespoň jeden z TLSA RR musí poskytnout ověření (cestu) k certifikátu nabízenému službou na zadané adrese.

Ne všechny protokoly zpracovávají shodné běžné jméno stejným způsobem. HTTP vyžaduje, aby se běžný název v certifikátu X.509 poskytovaném službou shodoval bez ohledu na to, zda TLSA prosazuje svou platnost. SMTP nevyžaduje shodu Common Name, pokud je hodnota použití certifikátu 3 (DANE-EE), ale jinak shodu Common Name vyžaduje. Je důležité ověřit, zda existují konkrétní pokyny pro používaný protokol.

RR datová pole

Samotný RR má 4 datová pole, která popisují, jakou úroveň ověření poskytuje vlastník domény.

Např. _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64 ==

Využití certifikátu

Hodnota využití certifikátu
Cesta PKIX
validace		Cíl RR
Důvěřujte kotvěKoncová entita
Požadované01
Není požadováno23

První pole za textem TLSA v DNS RR určuje, jak ověřit certifikát.

  • Hodnota 0 je pro to, co se běžně nazývá Omezení CA. (a PKIX-TA). Certifikát poskytnutý při vytváření TLS musí být vydán uvedenou kořenovou CA nebo některou z jejích zprostředkujících CA, s platnou certifikační cestou ke kořenové CA, které již aplikace provádějící ověření důvěřuje. Záznam může ukazovat pouze na zprostředkující certifikační autoritu, v takovém případě musí certifikát pro tuto službu přicházet prostřednictvím této certifikační autority, ale celý řetězec k důvěryhodné kořenové certifikační autoritě musí být stále platný.[A]
  • Hodnota 1 je pro to, co se běžně nazývá Omezení certifikátu služby (a PKIX-EE). Použitý certifikát musí přesně odpovídat záznamu TLSA a musí také předat PKIX ověření certifikační cesty důvěryhodnému kořenovému CA.
  • Hodnota 2 je pro to, co se běžně nazývá Důvěřujte ukotvení (a DANE-TA). Použitý certifikát má platnou certifikační cestu směřující zpět na zmínku o certifikátu v tomto záznamu, ale není nutné, aby předávala ověření certifikační cesty PKIX důvěryhodnému kořenovému CA.
  • Hodnota 3 je pro to, co se běžně nazývá Certifikát vydaný doménou (a DANE-EE). Služby používají certifikát podepsaný svým držitelem. Není podepsán nikým jiným a je to přesně tento záznam.

Volič

Při připojení ke službě a přijetí certifikátu určuje selektorové pole, které jeho části by měly být zkontrolovány.

  • Hodnota 0 znamená vybrat celý certifikát pro shodu.
  • Hodnota 1 znamená vybrat pouze veřejný klíč pro shodu certifikátu. Shoda s veřejným klíčem je často dostatečná, protože je pravděpodobné, že bude jedinečná.

Odpovídající typ

  • Typ 0 znamená, že celá vybraná informace je přítomna v souboru údaje o přidružení certifikátu.
  • Typ 1 znamená provést hash SHA-256 vybraných dat.
  • Typ 2 znamená udělat hash SHA-512 vybraných dat.

Údaje o přidružení certifikátu

Skutečná data, která mají být porovnána, vzhledem k nastavení ostatních polí. Toto je dlouhý "textový řetězec" hexadecimálních dat.

Příklady

Certifikát HTTPS pro www.ietf.org specifikuje kontrolu hash SHA-256 veřejného klíče poskytnutého certifikátu, ignoruje všechny CA.

_443._tcp.www.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Jejich poštovní služba má stejný přesný certifikát a TLSA.

ietf.org. MX 0 mail.ietf.org._25._tcp.mail.ietf.org. TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

Nakonec následující příklad dělá to samé jako ostatní, ale provádí výpočet hash přes celý certifikát.

_25._tcp.mail.alice.příklad. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

Standardy

  • RFC  6394 Použít případy a požadavky pro autentizaci pojmenovaných entit na základě DNS (DANE)
  • RFC  6698 Protokol autentizace pojmenovaných entit (DANE) Transport Layer Security (TLS) na základě DNS: TLSA
  • RFC  7218 Přidání zkratek ke zjednodušení konverzací o ověřování pojmenovaných entit na základě DNS (DANE)
  • RFC  7671 Protokol DANE (Authentication of Named Entities) založený na DNS: Aktualizace a provozní pokyny
  • RFC  7672 Zabezpečení SMTP prostřednictvím oportunistické autentizace pojmenovaných entit (DANE) na bázi DNS (TLS)
  • RFC  7673 Používání ověřování záznamů TLSA založených na DNS pomocí DNS (DANE) se záznamy SRV
  • RFC  7929 Ověření DNS na základě pojmenovaných entit (DANE) pro OpenPGP

Viz také

Poznámky

  1. ^ Neobvyklý příklad, kde by to mohlo být užitečné, by bylo, pokud úplně nedůvěřujete kořenovému CA, ale mnoho aplikací jej stále používá a vy důvěřujete konkrétnímu zprostředkujícímu CA, takže vypsáte střední a stále se naplníte ověření cesty důvěryhodnosti.

Reference

  1. ^ Barnes, Richard (6. října 2011). „DANE: Posunutí ověřování TLS na další úroveň pomocí DNSSEC“. Deník IETF. Citováno 5. srpna 2018.
  2. ^ „Podpora TLS Postfixu - Zabezpečené ověření certifikátu serveru“. Postfix.org. Citováno 2015-12-30.
  3. ^ A b Dukhovni; Hardaker (2013-07-28). DANE pro SMTP (PDF). Sborník IETF 87. IETF.
  4. ^ Filippo Valsorda (2015-03-31). „Smutný stav šifrování SMTP“. Citováno 2015-12-30.
  5. ^ Používání zabezpečeného DNS k přidružení certifikátů k doménovým jménům pro S / MIME. IETF. 2015-08-27. I-D draft-ietf-dane-smime-09.
  6. ^ Wouters, P. (srpen 2016). Ověření DNS na základě pojmenovaných entit (DANE) pro OpenPGP. IETF. doi:10.17487 / RFC7929. RFC 7929. Citováno 2016-09-14.
  7. ^ Langley, Adam (2015-01-17). „ImperialViolet - Proč NEPOUŽÍVAT v prohlížečích“. www.imperialviolet.org. Citováno 2017-03-24.[samostatně publikovaný zdroj ]
  8. ^ Duane Wessels, Verisign (2016-05-16). „Zvýšení podpisového klíče zóny síly pro kořenovou zónu“. Verisign.com. Citováno 2016-12-29.
  9. ^ Adam Langley (2012-10-20). „DANE sešívané certifikáty“. ImperialViolet. Citováno 2014-04-16.[samostatně publikovaný zdroj ]
  10. ^ Adam Langley (2011-06-16). „DNSSEC ověřený HTTPS v prohlížeči Chrome“. ImperialViolet. Citováno 2014-04-16.[samostatně publikovaný zdroj ]
  11. ^ Jak přidat podporu DNSSEC do Google Chrome
  12. ^ „DNSSEC / TLSA Validator“. Archivovány od originál dne 02.06.2018. Citováno 2014-04-30.
  13. ^ „Vydán GnuPG 2.1.9“. gnupg.org. Citováno 2015-10-10.[samostatně publikovaný zdroj ]
  14. ^ „Podpora Postfix TLS - DANE“. Postfix.org. Citováno 2014-04-16.
  15. ^ „Verze PowerMTA 5.0“. SparkPost.com. Citováno 2020-04-26.
  16. ^ Jakob Schlyter, Kirei AB. "DÁN" (PDF). RTR-GmbH. Citováno 2015-12-17.
  17. ^ „Podpora Halon DANE“. Halon Security AB. Citováno 2015-12-17.[samostatně publikovaný zdroj ]
  18. ^ "Specifikace Exim 4.91: Šifrovaná připojení SMTP pomocí TLS / SSL / 15. DANE". exim.org. Citováno 2018-07-05.
  19. ^ Scaturro, Michael (2014-08-24). „Chraňte svůj e-mail německy“. Opatrovník. Citováno 2018-04-29. ... V květnu se společnost [Posteo] stala prvním poskytovatelem e-mailů na světě, který na svých serverech přijal ověřování pojmenovaných entit (Dane) pomocí DNS. ...
  20. ^ DANE všude ?! Udělejme z internetu opět soukromé místo, tutanota.de, vyvoláno 2015-12-17[samostatně publikovaný zdroj ]
  21. ^ Richard Levitte (01.01.2016). „DANE CHANGES“. Citováno 2016-01-13.[samostatně publikovaný zdroj ]
  22. ^ „Ověření certifikátu pomocí DANE (DNSSEC)“. Gnu.org.[samostatně publikovaný zdroj ]

externí odkazy