210. DANE (DNS-Based Authentication of Named Entities)

⚠️ 이 문서는 웹/이메일 통신 시 암호화(HTTPS/TLS)에 사용되는 디지털 인증서를 기존의 상업적 인증기관(CA) 시스템에만 전적으로 의존하는 대신, 도메인의 소유자가 직접 DNS(도메인 네임 시스템)를 통해 자신의 인증서 정보를 검증 가능하게 배포하는 DANE 프로토콜과 TLSA 레코드를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 브라우저나 메일 서버가 접속하려는 사이트의 인증서가 "진짜 이 사이트 주인이 발급받은 것이 맞는지"를, 해킹 위험이 있는 CA를 맹신하지 않고 해당 도메인의 DNS에 기록된 지문(Fingerprint)과 직접 대조하여 크로스체크하는 보안 기술이다.
  2. 가치: 부패하거나 해킹당한 인증기관(CA)이 구글이나 네이버를 사칭한 '가짜 인증서'를 몰래 발급하여 중간자 공격(MitM)을 시도하더라도, DNS에 등록된 원본 지문과 다르기 때문에 접속을 원천 차단할 수 있다.
  3. 기술 체계: 이를 구현하기 위해 DNSSEC(DNS 데이터 위변조 방지)가 반드시 선행되어야 하며, DNS 설정에 TLSA라는 특수 레코드를 추가하여 인증서의 해시값을 기록해 둔다. (특히 이메일 SMTP 암호화 강제에 널리 쓰임)

Ⅰ. 기존 CA 인증 체계의 약점과 단일 장애점(SPOF)

현재의 인터넷 보안은 수백 개의 인증기관(CA) 중 하나라도 뚫리면 무너지는 구조다.

  1. CA (Certificate Authority)의 신뢰 모델:
    • 우리는 네이버에 접속할 때, 브라우저가 네이버의 인증서를 보고 "아, 디지서트(DigiCert)라는 믿을만한 CA가 도장을 찍어줬으니 진짜 네이버구나" 하고 암호화 통신을 시작한다.
  2. CA 해킹 사건 (DigiNotar 사태 등):
    • 2011년 해커가 네덜란드의 CA인 디지노타르(DigiNotar)를 해킹해 구글(Google.com)의 가짜 인증서를 무단 발급했다. 브라우저는 이 가짜 인증서를 '합법적인 CA가 발급한 진짜'로 오인하여 이란 사용자의 지메일을 중간에서 모두 감청당했다.
  3. 신뢰의 딜레마:
    • 전 세계 수백 개의 CA 중 단 한 곳만 매수되거나 해킹당해도, 전 세계 모든 도메인의 가짜 인증서를 만들어낼 수 있는 치명적인 약점(약한 고리)이 존재한다.

📢 섹션 요약 비유: 우리가 여권을 믿는 이유는 '정부(CA)'가 발행했기 때문인데, 만약 수백 개의 동사무소 중 한 곳의 직원이 뇌물을 받고 내 이름의 가짜 여권을 만들어주면, 전 세계 공항이 그 가짜 여권을 진짜로 믿고 통과시켜 버리는 시스템적 허점과 같습니다.

Ⅱ. DANE과 TLSA 레코드: DNS를 통한 교차 검증

DANE은 CA를 못 믿겠으니, 도메인 주인이 직접 자기 인증서의 모양을 공표하자는 아이디어다.

  1. TLSA 레코드:
    • 도메인 주인은 인증서를 발급받은 뒤, 그 인증서의 해시값(지문)을 추출하여 자신의 DNS 서버에 TLSA 레코드라는 형태로 등록해 둔다.
    • 예: _443._tcp.www.example.com. IN TLSA 3 0 1 (해시값)
  2. DANE의 2중 검증 프로세스:
    • ┌─────────────────────────────────────────────────────────┐ │ 1. [클라이언트]가 https://example.com 에 접속 시도. │ │ 2. 서버가 1차로 [CA가 발급한 인증서]를 클라이언트에게 줌. │ │ 3. [클라이언트]는 DNS 서버에 2차로 [TLSA 레코드]를 질의함. │ │ 4. 서버가 준 인증서의 해시값과 DNS의 TLSA 해시값이 │ │ 일치하는지 대조 (DANE 검증). 일치할 때만 접속 허용.│ └─────────────────────────────────────────────────────────┘
  3. 인증서 고정 (Certificate Pinning):
    • 해커가 가짜 인증서를 내밀더라도, DNS에 등록된 진짜 해시값과 다르기 때문에 브라우저나 메일 서버는 이 접속을 즉시 끊어버린다.

📢 섹션 요약 비유: 누군가 내 여권(인증서)을 들고 공항에 왔을 때 정부 도장만 믿는 게 아니라, 공항 직원이 진짜 내 가족(DNS)에게 전화를 걸어 "이 여권에 찍힌 얼굴 특징(해시값)이 당신 아들 맞소?"라고 한 번 더 확인하여 위조 여권을 원천 차단하는 방식입니다.

Ⅲ. 전제 조건: DNSSEC의 필수성과 이메일 보안 응용

DANE은 강력하지만 치명적인 전제 조건이 있다. "DNS 자체는 안전한가?"

  1. DNSSEC의 필수 동반:
    • 해커가 CA도 속이고 DNS 응답(TLSA 레코드) 자체도 중간에서 위조(DNS Spoofing)해 버리면 DANE은 소용이 없다.
    • 따라서 DANE이 동작하려면, DNS 응답 데이터 자체가 위변조되지 않았음을 암호학적으로 보증하는 **DNSSEC(DNS Security Extensions)**이 반드시 100% 적용되어 있어야 한다.
  2. SMTP 이메일 암호화에서의 맹활약:
    • 브라우저(웹)에서는 DANE 지원이 아직 완벽하지 않지만(크롬/엣지 제한적), 이메일 서버 간 통신(SMTP)에서는 매우 중요하다.
    • 이메일 서버가 상대방 서버로 메일을 보낼 때, 상대가 암호화(STARTTLS)를 지원하는 진짜 서버인지 DANE으로 검증하여, 해커의 서버로 이메일이 평문 유출되는(Downgrade Attack) 것을 강력하게 막아준다.

📢 섹션 요약 비유: 가족에게 확인 전화를 거는 방법(DANE)은 완벽해 보이지만, 해커가 전화선 자체를 가로채서 가짜 가족 행세(DNS 스푸핑)를 하면 망합니다. 그래서 가족과 통화할 때 반드시 미리 정해둔 비밀 암호(DNSSEC)를 먼저 대야만 진짜 가족의 답변으로 인정하는 2중 안전장치가 꼭 필요합니다.