명명된 개체의 DNS 기반 인증

DNS-based Authentication of Named Entities

DNS 기반 명명된 개체 인증(DANE)은 도메인 이름 시스템 보안 확장(DNSSEC)을 사용하여 TLS(Transport Layer Security)에 일반적으로 사용되는 X.509 디지털 인증서도메인 이름에 바인딩할 수 있도록 하는 인터넷 보안 프로토콜입니다.[1]

에서 제안합니다. 인증 기관(CA) 없이 TLS 클라이언트 및 서버 엔티티를 인증하기 위한 방법으로서 RFC6698. RFC7671의 운영 및 배포 지침으로 업데이트됩니다. DANE의 응용 프로그램별 사용은 SMTP의 경우 RFC7672, SRV(DANE with Service) 레코드의 경우 RFC7673에 정의되어 있습니다.

근거

TLS/SSL 암호화는 현재 CA(Certificate Authority)에서 발행한 인증서를 기반으로 합니다. 지난 몇 년 동안 많은 CA 공급자들이 심각한 보안 위반을 겪었고, 이러한 도메인을 소유하지 않은 사람들에게 잘 알려진 도메인에 대한 인증서를 발급할 수 있게 되었습니다. 많은 수의 CA를 신뢰하는 것은 문제가 될 수 있습니다. 왜냐하면 위반된 CA는 모든 도메인 이름에 대해 인증서를 발급할 수 있기 때문입니다. DANE을 사용하면 도메인 이름의 관리자가 도메인 이름 시스템(DNS)에 저장하여 해당 도메인의 TLS 클라이언트 또는 서버에서 사용되는 키를 인증할 수 있습니다. DANE은 보안 모델이 작동하려면 DNS 레코드를 DNSSEC와 서명해야 합니다.

또한 DANE을 사용하면 도메인 소유자가 특정 리소스에 대해 인증서를 발급할 수 있는 CA를 지정할 수 있으므로 모든 CA가 모든 도메인에 대해 인증서를 발급할 수 있는 문제를 해결할 수 있습니다.

DANE은 다음과 같은 유사한 문제를 해결합니다.

인증서 투명성
탐지되지 않은 상태에서 도메인 보유자의 허가 없이는 악성 CA가 인증서를 발급할 수 없도록 보장합니다.
DNS 인증 기관 인증
지정된 도메인에 대해 인증서를 발급할 수 있는 CA 제한

그러나 DANE과는 달리 이러한 기술은 브라우저의 광범위한 지원을 받습니다.

전자 메일 암호화

최근까지 암호화된 이메일 전송에 대한 표준이 널리 구현되지 않았습니다.[2] 이메일을 보내는 것은 보안에 구애받지 않으며, 보안 SMTP를 지정하는 URI 체계가 없습니다.[3] 따라서 TLS를 통해 전송되는 대부분의 이메일은 기회주의적 암호화만 사용합니다.[4] DNSSEC이 인증된 존재 거부를 제공하기 때문에(리졸버가 특정 도메인 이름이 존재하지 않음을 확인할 수 있도록) DANE을 사용하면 RFC 7672에서 설명한 대로 다른 외부 메커니즘 없이 검증된 암호화된 SMTP로 점진적으로 전환할 수 있습니다. DANE 레코드는 송신자가 TLS를 사용해야 함을 나타냅니다.[3]

또한, RFC 8162는 DANE을 S/MIME에 적용하기 위해 존재하며,[5] RFC 7929OpenPGP에 대한 바인딩을 표준화합니다.[6]

지지하다

적용들

  • 구글 크롬은 브라우저[7] 내에서 1024비트 RSA를 사용하지 않기를 원하기 때문에 DANE을 지원하지 않습니다(DNSSEC은 이전에 1024비트 RSA 서명 루트를 사용했으며,[8] 현대의 기본값은 256비트 ECDSA이지만[9] 여전히 많은 영역이 1024비트 RSA로 서명되어 있습니다). Adam Langley에 따르면 코드는 작성되었으며[10] 현재 Chrome에는 없지만 [11]추가 형식으로 사용할 수 있다고 합니다.[12]
  • Mozilla Firefox는 DANE을 지원하지 않습니다. DNSSEC 및 DANE 주제에 대한 티켓의 반응을 기반으로 현재 Mozilla 개발자는 Firefox의 범위를 벗어난 것으로 간주하지만 추가 지원을 사용할 수 있습니다.[13][14][15]
  • GNU Privacy Guard OpenPGP DANE(--auto-key-locate)을 통해 키를 가져올 수 있습니다. 새 옵션 --export-options export-dane. (버전 2.1.14)[16]
  • Cheogram Android는 DANE을 통해 확인할 수 있으며 DANE이 사용되었는지 여부를[17] 표시합니다.

서버

서비스

라이브러리

TLSARR

서비스에 대한 TLSARR(Resource Record)은 특정 TCP 또는 UDP 포트의 서비스에 대해 인증서 제약 조건을 적용해야 함을 지정하는 DNS 이름에 있습니다. TLSA RR 중 하나 이상이 지정된 주소에서 서비스에서 제공하는 인증서에 대한 유효성 검사(경로)를 제공해야 합니다.

모든 프로토콜이 공통 이름 일치를 동일한 방식으로 처리하는 것은 아닙니다. HTTP를 사용하려면 TLSA가 유효성을 주장하는 것과 관계없이 서비스에서 제공하는 X.509 인증서의 Common Name이 일치해야 합니다. 인증서 사용 값이 3(DANE-EE)인 경우 SMTP는 공통 이름 일치를 필요로 하지 않지만, 그렇지 않은 경우에는 공통 이름 일치를 필요로 합니다. 사용 중인 프로토콜에 대한 구체적인 지침이 있는지 확인하는 것이 중요합니다.

RR 데이터 필드

RR 자체에는 도메인 소유자가 제공하는 검증 수준을 설명하는 4개의 데이터 필드가 있습니다.

예. _25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF

인증서사용량

인증서사용가액
PKIX 경로
확인
RR대상
신탁앵커 종단실체
필수의 0 1
필요 없음 2 3

DNS RR의 TLSA 텍스트 다음에 있는 첫 번째 필드는 인증서를 확인하는 방법을 지정합니다.

  • 값이 0이면 일반적으로 CA 제약 조건(및 PKIX-TA)이라고 하는 것입니다. TLS를 설정할 때 제공되는 인증서는 목록에 있는 root-CA 또는 해당 중간 CA 중 하나에서 발급해야 하며, 검증을 수행하는 응용 프로그램에서 이미 신뢰한 root-CA에 대한 유효한 인증 경로가 있어야 합니다. 레코드는 중간 CA를 가리킬 수 있으며, 이 경우 이 서비스에 대한 인증서는 이 CA를 통해 와야 하지만 신뢰할 수 있는 루트 CA에 대한 전체 체인은 여전히 유효해야 합니다.[a]
  • 값 1은 일반적으로 서비스 인증서 제약 조건(및 PKIX-EE)에 대한 것입니다. 사용된 인증서는 TLSA 레코드와 일치해야 하며 PKIX 인증 경로 유효성 검사도 신뢰할 수 있는 루트 CA로 통과해야 합니다.
  • 값 2는 일반적으로 신뢰 앵커 주장(및 DANE-TA)이라고 하는 것에 대한 것입니다. TLSA 레코드는 루트 CA의 인증서 또는 서비스에서 사용 중인 인증서의 중간 CA 중 하나와 일치합니다. 인증 경로는 일치하는 인증서까지 유효해야 하지만 신뢰할 수 있는 루트 CA는 필요하지 않습니다.
  • 값 3은 일반적으로 도메인 발급 인증서(및 DANE-EE)라고 불리는 것에 대한 것입니다. TLSA 레코드는 사용된 인증서 자체와 일치합니다. 사용한 인증서는 다른 당사자가 서명할 필요가 없습니다. 이 기능은 자체 서명된 인증서뿐만 아니라 검증자가 신뢰할 수 있는 루트 인증서 목록을 가지고 있지 않은 경우에도 유용합니다.

셀렉터

서비스에 연결하고 인증서를 받을 때 선택기 필드는 해당 서비스의 어떤 부분을 확인해야 하는지 지정합니다.

  • 값이 0이면 일치할 전체 인증서를 선택하는 것을 의미합니다.
  • 1의 값은 인증서 일치를 위해 공개 키만 선택하는 것을 의미합니다. 공개 키를 일치시키면 일반적으로 고유할 가능성이 높기 때문에 충분합니다.

매칭유형

  • 0의 유형은 선택한 전체 정보가 인증서 연결 데이터에 있음을 의미합니다.
  • 1의 유형은 선택한 데이터의 SHA-256 해시를 수행하는 것을 의미합니다.
  • 2의 유형은 선택한 데이터의 SHA-512 해시를 수행하는 것을 의미합니다.

인증서연동자료

다른 필드의 설정이 주어지면 일치시킬 실제 데이터입니다. 16진수 데이터의 긴 "텍스트 문자열"입니다.

www.ietf.org 에 대한 TLSA 레코드는 CA를 무시하고 제공된 인증서의 공개 키의 SHA-256 해시를 확인하도록 지정합니다.

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

그들의 우편 서비스에는 동일한 인증서와 TLSA가 있습니다.

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

마지막으로 다음 예제는 다른 예제와 동일하게 수행하지만 전체 인증서에 대해 해시 계산을 수행합니다.

_25._tcp.메일.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9 

표준

  • RFC 6394 DANE(DNS-Based Authentication of Named Entity) 사용 사례 및 요구사항
  • RFC 6698 DANE(Desn-Based Authentication of Named Entity) TLS(Transport Layer Security) 프로토콜: TLSA
  • RFC 7218 DANE(DNS-Based Authentication of Named Entity)에 대한 대화를 단순화하기 위한 약어 추가
  • RFC 7671 DANE(DNS-Based Authentication of Named Entities) 프로토콜: 업데이트 및 운영 지침
  • RFC 7672 DANE(Dransport Layer Security)를 통한 기회주의적 DNS 기반 인증을 통한 SMTP 보안
  • RFC 7673 DANE(DNS-Based Authentication of Named Entity) TLSA 레코드와 SRV 레코드를 사용하는 방법
  • RFC 7929 DNS 기반 OpenPGP용 DANE 바인딩 인증
  • RFC 4255 안전한 SSH(Secure Shell) 키 핑거프린트 게시를 위한 DNS 사용
  • RFC 8162 보안 DNS를 사용하여 S/MIME용 도메인 이름에 인증서 연결
  • 초안: DANE 시맨틱스와 IPsec을 이용한 기회주의적 암호화: IPSECA[26]

참고 항목

메모들

  1. ^ 이 방법이 유용한 예로는 루트 CA를 완전히 신뢰하지 않는 경우가 있습니다. 그러나 많은 응용 프로그램이 여전히 이 CA를 사용하고 있으며, 특정 중간 CA를 신뢰하므로 중간 CA를 나열하고 전체 신뢰 경로를 확인할 수 있습니다.

참고문헌

  1. ^ Samad, Muhammad Alif Adha Bin (October 6, 2011). "DANE: Taking TLS Authentication to the Next Level Using DNSSEC". IETF Journal. Retrieved August 5, 2018.
  2. ^ "Postfix TLS Support - Secure server certificate verification". Postfix.org. Retrieved 2015-12-30.
  3. ^ a b Dukhovni; Hardaker (2013-07-28). DANE for SMTP (PDF). IETF 87 Proceedings. IETF.
  4. ^ Filippo Valsorda (2015-03-31). "The sad state of SMTP encryption". Retrieved 2015-12-30.
  5. ^ Hoffman, P. (May 2017). Using Secure DNS to Associate Certificates with Domain Names For S/MIME. IETF. doi:10.17487/RFC8162. RFC 8162. Retrieved 2022-03-30.
  6. ^ Wouters, P. (August 2016). DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. IETF. doi:10.17487/RFC7929. RFC 7929. Retrieved 2016-09-14.
  7. ^ Langley, Adam (2015-01-17). "ImperialViolet - Why not DANE in browsers". www.imperialviolet.org. Retrieved 2017-03-24.[자체published]
  8. ^ Duane Wessels, Verisign (2016-05-16). "Increasing the Strength Zone Signing Key for the Root Zone". Verisign.com. Retrieved 2016-12-29.
  9. ^ "Bind9 DNSSEC Guide". bind9.readthedocs.io. Retrieved 2021-08-22.
  10. ^ Adam Langley (2012-10-20). "DANE stapled certificates". ImperialViolet. Retrieved 2014-04-16.[자체published]
  11. ^ Adam Langley (2011-06-16). "DNSSEC authenticated HTTPS in Chrome". ImperialViolet. Retrieved 2014-04-16.[자체published]
  12. ^ Google Chrome에 DNSSEC 지원을 추가하는 방법
  13. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=672600
  14. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=1479423
  15. ^ https://addons.mozilla.org/en-US/firefox/addon/dnssec-dane-validator/
  16. ^ "GnuPG - Release Notes". gnupg.org. 12 June 2021. Retrieved 2021-08-27.[자체published]
  17. ^ "cheogram-android 2.13.0-1". Retrieved 2021-02-11.
  18. ^ "Postfix TLS Support - DANE". Postfix.org. Retrieved 2014-04-16.
  19. ^ "PowerMTA 5.0 Release". SparkPost.com. Retrieved 2020-04-26.
  20. ^ "Exim 4.91 spec: Encrypted SMTP connections using TLS/SSL / 15. DANE". exim.org. Retrieved 2018-07-05.
  21. ^ "mod_s2s_auth_dane_in". prosody.im. Retrieved 2024-02-11.
  22. ^ Scaturro, Michael (2014-08-24). "Protect your email the German way". The Guardian. Retrieved 2018-04-29. ... Last May, [Posteo] became the world's first email provider to adopt DNS-based Authentication of Named Entities (Dane) on its servers. ...
  23. ^ DANE Everywhere?! Let's Make the Internet a Private Place Again, tutanota.de, retrieved 2015-12-17[자체published]
  24. ^ Richard Levitte (2016-01-07). "DANE CHANGES". GitHub. Retrieved 2016-01-13.[자체published]
  25. ^ "Verifying a certificate using DANE (DNSSEC)". Gnu.org.[자체published]
  26. ^ Osterweil, Eric; Wiley, Glen; Okubo, Tomofumi; Lavu, Ramana; Mohaisen, Aziz (6 July 2015). "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA". Internet Engineering Task Force.

외부 링크