나는 단지 궁금했다. 우리는 많은 SSL 인증서를 사용합니다. 요즘에는 거의 독점적으로 letencrypt (감사합니다!)를 사용합니다. 이러한 인증서의 결론은 인증서에서 도메인 이름의 소유권 증명이 도메인에서 DNS 레코드 나 웹 사이트를 조작 할 수 있다는 것입니다. DNS 증거는 DNS에 TXT 레코드로 일부 키 (letencrypt가 제공함)를 추가하여 제공됩니다.

따라서 도메인의 DNS 레코드를 변경할 수 있다는 충분한 증거가 있다면 DNS의 지문으로 자체 서명 된 인증서를 사용하지 않는 이유는 무엇입니까?

이것이 DNS 기반 letencrypt (및 기타 CA)의 절차와 정확히 같은 양의 신뢰를 제공한다고합니다.

1. 자체 서명 된 CA를 작성하십시오 (다양한 방법의 단계를 따르십시오).
2. 일부 도메인에 대한 인증서 생성
3. 1 단계의 CA로 2 단계의 인증서에 서명하십시오. 이제 신뢰할 수없는 CA가 서명 한 기본 인증서가 있습니다.
4. TXT (또는 전용) 레코드를 각 도메인의 DNS에 추가하여 다음과 같이 명시합니다.이 도메인에이 CA의 인증서를 서명했습니다. 'CA =-핑거 핀트'
5. 브라우저는 인증서를 다운로드하고 CA / CA 인증서의 지문을 지정된 도메인의 DNS 데이터와 비교하여 인증서를 확인합니다.

이를 통해 기본 SSL 인증서와 동일한 트러스트 수준의 타사 간섭없이 신뢰할 수있는 자체 서명 된 인증서를 만들 수 있습니다. DNS에 액세스 할 수 있으면 인증서가 유효합니다. 암호화와 같은 DNSSEC를 추가하여 CA 레코드와 SOA 레코드를 해시하여 DNS 레코드 변경시 신뢰가 사라지는 것을 확인할 수도 있습니다.

이것은 이전에 고려 되었습니까?

옐머

이를 가능하게하는 기본 인프라가 존재하며 이름 기반 엔티티의 DNS 기반 인증 (DANE)이라고하며 RFC6698에 지정되어 있습니다 . TLSA체인에있는 엔드 엔터티 또는 해당 CA 중 하나의 인증서 또는 공개 키를 지정 하는 리소스 레코드 를 통해 작동 합니다 (실제로 4 가지 유형이 있습니다. 자세한 내용은 RFC 참조).

양자

그러나 DANE는 아직 널리 채택되지 않았습니다. 베리사인은 모니터 DNSSEC 및 DANE 채택 하고 시간이 지남에 따라 성장을 추적 :

비교를 위해 VeriSign에 따르면 약 270 만 개의 DNS 영역이 존재하므로 모든 영역의 1 % 이상이 하나 이상의 TLSA 레코드를 가지고 있음을 의미합니다.

나는 왜 DANE인가에 대한 정답을 줄 수는 없지만 내 추측은 다음과 같습니다.

DANE는 CRL (Certificate Revocation List) 및 OCSP (Online Certificate Status Protocol)와 같은 문제가 있습니다. 제시된 인증서의 유효성을 확인하려면 타사에 문의해야합니다. Hanno Böck 은 좋은 개요를 제공하는데 , 이것이 실제로 큰 문제인 이유입니다. 그것은 당신이 제 3 자에게 연락 할 수 없을 때해야 할 일의 문제로 요약됩니다. 브라우저 공급 업체 는이 경우 소프트 실패 (일명 허가)를 선택했습니다. 이로 인해 모든 것이 무의미 해지고 Chrome은 궁극적으로 2012 년에 OCSP를 사용 중지하기로 결정했습니다.

DNSSEC

틀림없이 DNS는 CA의 CRL 및 OCSP 서버보다 훨씬 더 나은 가용성을 제공하지만 여전히 오프라인 확인이 불가능합니다. 또한 DANE는 DNSSEC와 함께 사용해야합니다. 일반 DNS는 인증되지 않은 UDP를 통해 작동하므로 위조, MITM 공격 등이 발생하기 쉽습니다. DNSSEC를 채택하는 것이 DANE를 채택하는 것보다 훨씬 낫지 만 여전히 보편적 인 것은 아닙니다.

그리고 DNSSEC을 사용하면 소프트 실패 문제가 다시 발생합니다. 내가 아는 한, 주요 서버 / 클라이언트 운영 체제는 기본적으로 유효성 검증 DNSSEC 분석기를 제공하지 않습니다.

그러면 취소 문제도 있습니다. DNSSEC에는 해지 메커니즘이 없으며 짧은 활성 키를 대신 사용합니다.

소프트웨어 지원

모든 참여 소프트웨어는 DANE 지원을 구현해야합니다.

이론적으로는 이것이 암호화 라이브러리의 역할이 될 것이며 응용 프로그램 개발자는 많은 일을 할 필요가 없지만 실제로는 암호화 라이브러리가 기본 요소 만 제공하고 응용 프로그램은 많은 구성과 설정을 수행해야합니다. (불행히도 문제를 일으키는 많은 방법이 있습니다).

예를 들어 주요 웹 서버 (예 : Apache 또는 nginx)가 DANE를 구현했거나이를 수행 할 계획이 있음을 모르겠습니다. 웹 서버는 웹 기술을 기반으로 점점 더 많은 것들이 구축되기 때문에 웹 서버가 특히 중요합니다.

CRL, OCSP 및 OCSP Stapling을 비교할 때 DANE 채택 사례가 어떻게 진행되는지 추론 할 수 있습니다. OpenSSL, libnss, GnuTLS 등을 사용하는 일부 응용 프로그램 만 이러한 기능을 지원합니다. Apache 또는 nginx와 같은 주요 소프트웨어가이를 지원하는 데 시간이 걸리고 Hanno Böck의 기사를 다시 참조하면 문제가 발생하여 구현에 결함이 있습니다. Postfix 또는 Dovecot와 같은 다른 주요 소프트웨어 프로젝트 는 OCSP를 지원하지 않습니다CRL 기능이 매우 제한되어 있으며 기본적으로 파일 시스템의 파일을 가리 킵니다 (필수적으로 정기적으로 다시 읽을 필요는 없으므로 서버를 수동으로 다시로드해야 함). 이들은 TLS를 자주 사용하는 프로젝트라는 점을 명심하십시오. 그런 다음 PostgreSQL / MySQL과 같이 TLS가 훨씬 덜 일반적인 것들을 살펴보고 CRL을 최대한 제공 할 수 있습니다.

그래서 나는 현대 웹 서버조차 그것을 구현하지 않았으며 대부분의 다른 소프트웨어는 OCSP와 CRL을 구현하지 않았으며 5 년 엔터프라이즈 응용 프로그램이나 어플라이언스와 행운을 빕니다.

잠재적 인 응용

그렇다면 실제로 DANE를 어디에서 사용할 수 있습니까? 현재로서는 일반 인터넷이 아닙니다. 서버와 클라이언트를 제어하는 ​​경우 옵션 일 수 있지만이 경우 종종 공개 키 고정에 의존 할 수 있습니다.

메일 공간에서 SMTP에 가장 긴 종류의 인증 된 전송 암호화가 없기 때문에 DANE가 약간의 관심을 끌고 있습니다. SMTP 서버는 때때로 서로간에 TLS를 사용했지만 인증서의 이름이 실제로 일치하는지 확인하지 않았으므로 이제 DANE를 통해이를 확인하기 시작했습니다.

다양한 유형의 인증서 유효성 검사 절차

일반적인 CA 서명 인증서에는 여러 가지 수준의 인증서 유효성 검사가 있습니다.

• 도메인 유효성 검사 (DV)
  도메인 이름 소유권 만 확인되고 인증서에서 도메인 이름 만 "제목"으로 표시됩니다.
• OV (조직 검증)
  도메인 이름과 소유자 이름이 확인되고 도메인 이름과 소유자 이름이 인증서에서 "제목"으로 표시됩니다.
• EV (Extended Validation)
  소유자 엔티티, 도메인 이름 및 소유자 이름에 대한보다 엄격한 유효성 검사는 인증서에서 "주제"로 표시되며 소유자 이름이있는 녹색 막대

귀하가 설명하고 대체를 제안하는 프로세스는 최하위 수준의 도메인 검증 (DV)에만 적용됩니다.

DV는 LetsEncrypt가 수행 한 작업과 같이 검증이 비교적 자동화하기 쉬운 수준이며, DNS가 트러스트 앵커의 유일한 소스로 사용 된 경우 DNS가 제공 할 수있는 것과 비슷한 수준의 신뢰를 제공합니다 (UI 관련 사항, 인증서 신뢰할 수 있지만 검증되지 않은 추가 데이터를 포함해야합니다).

명명 된 엔터티의 DNS 기반 인증 (DANE)

DANE 는 DNSSEC (DNS 데이터 인증이 중요하기 때문에) 위에 구축되어 DNS의 TLS 클라이언트에 대한 트러스트 앵커 정보를 게시합니다.

그것은 사용 TLSARR 타입과 인증서 또는 공개 키 (중 하나를 식별하는 데 사용할 수있는 선택 또는도 (성공 정규 인증서 체인 유효성 검사를 필요로하지 않고, 최종 엔티티 또는 CA 중 하나의를) 인증서 사용을 )하는 방법과 CERT / key 데이터는 레코드에 표시됩니다 ( 일치 유형 ).

TLSA기록 소유자 이름이 포트와 프로토콜 (예를 나타내는 접두사를 가지고 _443._tcp)와 RData에가를 표시 cert usage, selector및 matching typeCERT는 이외에 모드 / 키 데이터가 일치합니다. 이러한 매개 변수의 세부 사항은 RFC6698의 섹션 2.1을 참조하십시오 .

TLSA이 같은 예를 들어보기를위한 기록 할 수 있습니다

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

DANE 인식 ​​클라이언트는 사용 모드를 사용 2하거나 3(TLSA 트러스트 앵커 만 사용함을 나타냄) 일반적으로 신뢰할 수있는 CA가 서명하지 않았지만 TLSA레코드 와 일치하는 인증서를 수락합니다 .
이것은 개념적으로 질문에서 제안한 것과 동일합니다.

캐치? DANE 인식 ​​클라이언트는 현재 존재하지 않거나 거의 존재하지 않습니다. 한 가지 문제는 DNSSEC 자체가 DANE를 시작하는 데 필요한 것만 큼 널리 배포되지 않은 것입니다 (특히 클라이언트 컴퓨터의 유효성 검사). DANE가 인증 된 DNS 데이터에 의존하는 최초의 잠재적 인 새로운 유스 케이스 중 하나라는 점을 고려하면 약간의 닭과 계란 문제 일 수 있습니다.

DNSSEC 및 DANE validation을 추가 하는 브라우저 플러그인 이 있습니다.이 시점에서 주류 근처에는 그다지 많지 않습니다. 또한 기본적으로 지원되는 것이 아니라 플러그인이기 때문에 일반적인 용도로 사용하는 것보다 개념 증명의 역할을합니다.

할 수있었습니다. 고려되었습니다. 여전히 일어날 수 있지만 많은 움직임이 없었습니다.