TLSA 레코드 생성기 (DANE)와 검사기

TLSA 레코드는 인증서나 공개키를 DNS에 고정합니다. 그것이 DANE입니다. 수백 개 인증 기관 가운데 어쩌다 내 이름에 서명해 준 곳을 믿는 대신, 클라이언트가 DNSSEC으로 레코드를 가져와 인증서가 그것과 일치하도록 요구합니다. 이 페이지는 인증서를 받아 셀렉터와 매칭 종류의 모든 조합에 대한 연관 데이터를 계산하고, 소유자 이름과 함께 레코드를 내보내며, 실제로 가장 많이 쓰이는 기능으로 이미 게시한 레코드가 지금 서비스 중인 것과 여전히 맞는지 알려 줍니다.

숫자 세 개가 레코드의 의미를 정합니다. 용도는 인증서가 누구의 권위에 기대는지 말합니다. 0과 1은 PKIX로, 레코드와 일치하는 것에 더해 공개 CA 체계로도 검증되어야 하므로 자체 서명 인증서는 실패합니다. 2와 3은 DANE이고 스스로 섭니다. 셀렉터는 무엇을 일치시키는지 — 인증서 전체인지 SubjectPublicKeyInfo만인지 — 를 말합니다. 매칭 종류는 어떻게 일치시키는지, 즉 SHA-256인지 SHA-512인지 바이트 자체인지를 말합니다.

거의 모든 배포에서 답은 3 1 1이고, 이유는 암호학이 아니라 운영입니다. 셀렉터 1은 인증서가 아니라 공개키를 일치시키므로, 같은 키를 재사용한 갱신은 같은 연관 데이터를 만들고 DNS 레코드를 바꿀 필요가 없습니다. 셀렉터 0은 인증서를 일치시키므로 날짜만 바뀐 갱신에도 레코드가 무효가 되는데, 오래된 레코드는 보호 없는 상태로 내려앉지 않습니다. DANE을 아는 클라이언트는 연결을 거부합니다. DANE 장애는 대부분 정확히 이것입니다.

SubjectPublicKeyInfo를 꺼내는 일은 도구가 은근히 틀릴 수 있는 단계인데, 고정된 위치에 있지 않기 때문입니다. 인증서는 SEQUENCE이고 그 첫 원소가 TBSCertificate이며, 그것 역시 SEQUENCE로서 선택적 명시 버전 다음에 일련번호, 서명 알고리즘, 발급자, 유효 기간, 주체가 오고 그다음이 공개키입니다. 버전은 선택적이고 기본값이 v1이라 키는 그 다음 여섯 번째 필드이거나 처음부터 여섯 번째입니다. 그래서 이 페이지는 바이트를 세지 않고 구조를 걸어가며, RSA와 P-256·P-384, Ed25519에 대해 openssl 명령줄과 대조해 검증했습니다.

TLSA가 수고할 값이 있는 곳은 SMTP입니다. RFC 7672는 보내는 메일 서버가 TLS를 강제할지와 어떤 인증서를 받아들일지 결정하는 방식으로 DANE을 정하고, 실제로 널리 배포되어 있습니다. 브라우저 주소창에 해당하는 것이 SMTP에는 없으므로, 받는 서버를 인증할 수 있게 해 주는 것이 이것입니다. HTTPS에서는 주요 브라우저가 DANE 검증을 출시한 적이 없어서, HTTPS TLSA 레코드는 강제하는 것이 아니라 의도를 문서화하는 것입니다.

이 페이지가 검사하지 않는 것은 인증서 밖의 모든 것입니다. DNS를 조회하지 않으므로 레코드가 게시되었는지, 존이 서명되었는지, 부모가 DS를 가지고 있는지 알려 줄 수 없습니다. DNSSEC 없이는 TLSA 레코드는 공격자가 고쳐 쓸 수 있는 조언일 뿐입니다. 인증서 날짜도 검사하지 않습니다. 둘 다 계산이 아니라 배포에 속하는 문제입니다.