요약

  • Let's Encrypt는 2020년 2월 29일, 인증서 발급 소프트웨어인 Boulder에서 다수의 도메인 이름이 포함된 인증서 요청에 대해 DNS 인증 기관 인증(CAA) 레코드를 재확인하는 방식에 결함이 있었음을 공개했다. 조직은 문제 확인 후 몇 분 만에 발급을 중단했고, 수정 사항 배포 후 발급을 재개했다고 밝혔다 [1].
  • CAA는 도메인 이름 소유자가 해당 도메인에 대해 인증서를 발급할 수 있는 인증 기관을 지정할 수 있게 하는 DNS 리소스 레코드다. RFC 8659는 CAA를 선택적 브랜드 표시가 아니라 의도하지 않은 인증서 오발급에 대한 추가 통제 장치로 규정한다 [2].
  • 책임성 쟁점은 Let's Encrypt가 CAA를 일반적으로 지원하는지 여부가 아니었다. 재사용된 검증 집합의 모든 대상 이름이 발급에 충분히 가까운 시점에 필요한 새로운 인증 확인을 받았는지, 그리고 영향을 받은 가입자가 폐기 전에 인증서를 교체할 수 있었는지 여부였다 [1].
  • BTW 디렉터리의 별개 운영 선례는 Let's Encrypt 인증서 신뢰 범위를주체:internet-society에 연결한다. 이 글의 직접적인 공개 주제는 Let's Encrypt와 공식 Let's Encrypt 소개 페이지가 설명하는 Internet Security Research Group 서비스로 유지된다 [3].
  • 실무적 통제 교훈은 DNS 정책, CA 소프트웨어, 가입자 자동화, 공개 폐기 커뮤니케이션이 하나의 체인으로 감사 가능해야 한다는 것이다. 검증 주체는 CA의 내부 로그를 열람할 수 없으므로, 공개 사후 분석 근거와 결정적 재발 방지 통제가 신뢰 경계의 일부가 된다.

무슨 일이 있었나

Let's Encrypt의 인시던트 공지는 2020년 2월 29일 발급에 사용하는 CA 소프트웨어인 Boulder에서 발견된 결함을 설명했다. Boulder는 평소 가입자의 도메인 이름 제어를 검증할 때 CAA 레코드를 확인한다. 일부 검증 결과는 초기 확인 후 일정 기간 재사용 가능하므로, 인증 기관은 인증서 발급 직전에 CAA를 다시 확인해야 할 수 있다. Let's Encrypt는 해당 규칙상 검증이 8시간보다 오래된 경우 발급 전 8시간 이내에 CAA 확인을 요구했다고 밝혔다 [1].

장애 양상은 구체적이었다. CAA 재확인이 필요한 여러 도메인 이름이 포함된 요청에서 Boulder는 하나의 도메인 이름을 선택해 반복 확인했고, 관련된 각 이름을 개별적으로 확인하지 않았다. 그 결과 요청에 포함된 하나 이상의 이름이 의도된 새로운 DNS 인증 확인을 받지 못한 채 인증서 요청이 발급까지 통과할 수 있었다. Let's Encrypt는 03:08 UTC에 버그를 확인했고, 03:10 UTC에 발급을 중단했으며, 05:22 UTC에 수정 사항을 배포한 뒤 발급을 재개했다고 밝혔다 [1].

이 타임라인이 중요한 이유는 인증 기관의 책임성이 코드를 고쳤다는 진술만으로 입증되지 않기 때문이다. 시스템은 또한 필요한 재확인 없이 발급되었을 가능성이 있는 인증서를 식별하고, 가입자에게 통지하고, 교체를 가능하게 하고, 폐기를 수행해야 했다. 이 인시던트 스레드는 이후 가입자에게 폐기가 시작되기 전에 영향받은 인증서를 갱신·교체하도록 안내했다. 따라서 공개 기록에는 결함 식별, 발급 수정, 인증서 수명 주기 정리라는 세 가지 운영 단계가 포함되었다 [1].

CAA가 서류 항목이 아니라 DNS 통제 장치인 이유

RFC 8659는 DNS CAA 리소스 레코드를 도메인 이름 소유자가 해당 도메인에 대해 인증서를 발급할 수 있는 인증 기관을 지정하는 방법으로 정의한다. 같은 표준은 CAA가 공개 CA에 의도하지 않은 인증서 오발급을 줄이기 위한 추가 통제를 제공한다고 말한다 [2]. 실무에서 이는 CAA가 도메인 운영자의 DNS 상태와 CA의 발급 결정 사이의 경계임을 의미한다.

Daniel Kade의 리스크·책임성 관점에서 중요한 점은 인증서 브랜드가 아니라 운영 권한 체인이다. 도메인 소유자가 DNS에 CAA를 게시한다. 재귀 및 권한 DNS 인프라가 CA가 보는 레코드 상태를 반환한다. CA 소프트웨어가 발급 규칙에 따라 그 상태를 해석한다. 가입자 자동화는 갱신이 대규모로 동작하기를 기대한다. 검증 주체는 공개 인증서가 요구되는 통제 아래 발급되었음을 신뢰한다. 이 체인의 한 고리가 모호한 "검증 통과" 라벨로 압축되면 근거 경계가 너무 느슨해진다.

2020년 버그는 바로 그 느슨함을 드러냈다. 도메인 제어 검증과 CAA 인증은 관련은 있지만 같은 검사가 아니다. 가입자가 여전히 도메인을 제어하는 동안 도메인의 CAA 정책이 변경되었을 수 있고, 시간에 따라 DNS 응답이 달라졌을 수 있으며, 다중 이름 인증서 요청의 한 이름이 별도의 확인을 필요로 할 수 있다. 책임성은 이 구분을 보존하는 로그와 테스트를 요구한다.

디렉터리와 주제 경계

현재 운영 디렉터리에는 공개된internet-society주체가 있고, Internet Security Research Group이나 Let's Encrypt에 대한 별개의 공개 주체는 없다. 그렇다고 주체를 새로 만들거나 인시던트의 라벨을 바꿀 이유는 없다. 이 글의 근거 주제는 Let's Encrypt와 공식 Let's Encrypt 소개 페이지가 설명하는 ISRG 서비스다 [3]. 디렉터리 연결은 이전 Daniel Kade의 Let's Encrypt 인증서 신뢰 글에서 이미 운영 중인 Internet Society 선례를 사용하며, 본문은 직접 주제를 명확히 유지하고 Internet Society가 2020년 Boulder 엔지니어링 결정을 내렸다고 주장하지 않는다.

이 구분은 출처 충실성을 위해 필요하다. 디렉터리 행은 운영 연결 표면일 뿐이다. 인시던트 사실은 여전히 이를 공개한 조직과 해당 통제를 정의한 표준 문서에 귀속되어야 한다. 가져오기 또는 소유자 게이트가 게시 전에 직접적인 ISRG 주체를 요구한다면, 이 후보는 잘못된 조직으로 강제 통과되지 말고 실패로 닫혀야 한다.

책임성 근거가 보여야 할 것

이 부류의 문제에 대한 방어 가능한 종결은 최소 여섯 가지 질문에 답해야 한다.

첫째, 요청에서 어떤 이름이 새로운 CAA 재확인을 필요로 했고 그 이유는 무엇인가? 답은 사후 수작업 스프레드시트가 아니라 검증 연령, 발급 시각, 인증서의 주체 대체 이름에서 도출 가능해야 한다.

둘째, CA는 어떤 DNS 응답에 의존했는가? CAA는 DNS 레코드이므로 근거 경계에는 쿼리 시점, 리졸버 동작, 보존된 경우 권한 응답, 타임아웃 또는 SERVFAIL 사례에 대한 오류 처리가 포함되어야 한다.

셋째, 어떤 소프트웨어 경로가 결정을 내렸는가? 사후 분석은 코드가 관련된 모든 이름을 반복했는지, 테스트가 다중 이름 요청을 다루었는지, 같은 부류의 버그가 재발하면 재발 방지 통제가 실패로 작동하는지 보여야 한다.

넷째, 어떤 인증서가 잠재적으로 영향을 받았는가? 영향 집합은 독립적으로 경계를 정할 수 없는 추정이 아니라 발급 데이터에 대한 재현 가능한 쿼리여야 한다.

다섯째, 가입자에게 어떻게 통지했고 교체를 어떻게 추적했는가? 폐기는 눈에 보이는 최종 단계일 뿐이다. 운영 리스크는 가입자가 통지를 받는 시점과 갱신에 성공하는 시점, 그리고 기존 인증서가 무효화되는 시점 사이의 간격이다.

여섯째, 모니터링에서 무엇이 바뀌었는가? 일회성 수정은 발급 로직, CAA 조회 수, 인증서 이름 수가 어긋날 때 경보를 울리는 영구 검사보다 약하다.

Let's Encrypt를 넘어 중요한 이유

대형 인증 기관은 작은 검증 가정이 많은 가입자에 빠르게 영향을 미칠 수 있는 규모로 운영된다. 자동화는 보안 모델의 일부다. 수작업 오류를 줄이고 HTTPS 배포를 쉽게 만든다. 그러나 자동화는 잘못된 통제가 중단될 때까지 기계 속도로 반복될 수 있음을 의미한다. 그래서 책임성 계층은 의도에 대한 신뢰에 의존할 수 없고, 어떤 코드가 실행되었는지, 어떤 DNS 상태가 참조되었는지, 어떤 수명 주기 조치가 이어졌는지 보여주는 근거에 의존해야 한다.

같은 교훈은 등록 기관, DNS 운영자, 호스팅 제공업체, 관리형 인증서 플랫폼에도 적용된다. 고객이 인증서를 요청하고, DNS 레코드를 교체하고, 영역을 위임하고, TLS 갱신을 자동화할 수 있게 하는 조직은 조치 시점에 사용한 권한에 대한 기록이 필요하다. 검증 시점에는 옳았지만 발급 시점에 낡은 통제는 현재의 인증이 아니다.

지금 주목할 것

장기 신호는 발급 제품이 더 자동화될수록 인증 기관과 호스팅 플랫폼이 CAA 동작을 테스트 가능하게 유지하는지 여부다. 운영자는 검증 재사용, 다중 이름 인증서 요청, 리졸버 장애, 긴급 폐기, 계정 수준 인증, ACME 클라이언트 동작, 가입자 통지 기간을 언급하는 인시던트에 주목해야 한다. 이 용어들은 각각 통제가 조용히 이미 충족된 것으로 취급되는 경계를 표시할 수 있다.

저위험 시나리오는 명확하다. 모든 이름이 현재 정책 아래 재확인되고, CAA가 승인하지 않으면 발급이 차단되며, 영향받은 인증서가 식별 가능하고, 가입자가 중단 없이 갱신할 수 있으며, 폐기가 공개 근거와 함께 완료된다. 고위험 시나리오 역시 명확하다. 검증, 인증, 발급, 폐기가 하나의 불투명한 상태로 병합되어 사용자는 내부 통제가 작동했다는 신뢰만 남게 된다.

출처

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/