Certificate Transparency: 모든 인증서가 공개인 이유

모든 공개 신뢰 TLS 인증서가 이제 공개 흔적을 남기도록 기대된다.

웹이 스스로에게 한 최고의 일 중 하나다.

Certificate Transparency 이전에는, 인증 기관이 도메인에 위조 인증서를 발급해도 누군가 사용 중 우연히 발견하거나 CA가 자백하지 않는 한 절대 모를 수 있었다. 전체 공개 PKI 생태계가 신뢰와 행운의 이상한 조합에 의존했다. CA가 비밀리에 인증서를 잘못 발급하면 탐지는 대부분 우연이었다.

2013년에 Google이 한 CA가 여러 Google 도메인에 비인가 인증서를 발급한 걸 발견했다. 기술적으로 유효했다 — 신뢰받는 CA가 서명한. 감시에 쓰일 수 있었다. Google이 인증서 고정을 배포해놓아서 잡았다. 그 고정이 없었으면 아무도 몰랐을 것이다.

뒤따른 질문은 당연했다: 아무도 잡지 못한 비인가 인증서가 얼마나 더 있는가?

답: 모든 것을 보이게 만들자

RFC 6962로 표준화되고 Google 엔지니어가 제안한 Certificate Transparency는 단순한 아이디어 위에 세워졌다: 모든 인증서 발급은 공개 행위여야 한다.

CA가 인증서를 발급 전이나 발급 중에 CT 로그에 제출한다. 로그는 공개 검색이 가능하다. 누구든 어떤 도메인에 발급된 모든 인증서를 조회할 수 있다. CA가 인가하지 않은 인증서를 발급하면 CT가 알아내는 방법이다.

시스템이 부정 발급을 방지하지는 않는다. 보이게 만든다. 이 구분이 중요하다. CT는 침해된 CA가 위조 인증서를 찍는 걸 막지 않는다. 위조 인증서가 숨을 수 없게 한다.

CT 로그의 작동 방식

CT 로그는 추가 전용 데이터 구조 — 구체적으로 머클 트리다. 인증서는 추가될 수 있지만 삭제하거나 수정할 수 없다. 트리 구조 덕분에 인증서가 로그에 있다는 걸 수학적으로 증명할 수 있고, 로그가 변조되지 않았다는 것도 증명할 수 있다.

CA가 인증서를 제출하면 로그가 SCT(Signed Certificate Timestamp) — 인증서가 기록됐다는 암호화 증명 — 을 돌려준다. SCT는 인증서 자체에 포함되거나 TLS 확장이나 OCSP stapling으로 전달된다.

브라우저가 SCT를 요구한다. Chrome은 인증서 유효 기간에 따라 독립 로그 2-3개의 SCT를 요구한다. SCT가 없는 인증서는 거부된다. 이게 집행 메커니즘이다 — 브라우저가 미기록 인증서를 신뢰하지 않으니 CA가 로깅을 건너뛸 수 없다.

복수의 독립 로그가 존재한다 — Google, Cloudflare, Let’s Encrypt, Sectigo 등이 운영한다. 복수 독립 로그의 SCT를 요구하면 단일 로그 운영자가 인증서의 가시성을 억제할 수 없다.

뭘 찾을 수 있나

CT 로그에는 모든 공개 신뢰 CA가 모든 도메인에 발급한 모든 인증서가 있다:

• 모든 서브도메인. CA가 internal.staging.corp.example.com에 인증서를 발급하면 CT 로그에 있다. 내부 인프라에 공개 CA를 쓰는 도메인 소유자가 의도치 않게 내부 네이밍 구조를 노출한다.

• 모든 발급자. 어떤 CA가 도메인에 인증서를 발급했는지, 언제인지 볼 수 있다. 처음 듣는 CA가 도메인에 인증서를 발급했으면 경고 신호다.

• 이력 기록. CT 로그는 추가 전용이라 수년간의 인증서 이력이 있다.

이게 CT가 보안 도구이면서 동시에 정찰 도구인 이유다. crt.sh 같은 서비스가 CT 로그 데이터에 무료 검색 접근을 제공한다. 보안팀은 비인가 인증서 모니터링에 쓰고, 공격자는 정찰용 서브도메인 발견에 쓴다.

이중 용도는 알려진 트레이드오프다. 보안 커뮤니티는 가시성 혜택이 서브도메인 노출 리스크보다 크다고 결정했다.

모니터링: 대부분의 도메인 소유자가 건너뛰는 부분

CT 로그는 도메인 소유자가 비인가 인증서를 모니터할 수 있게 한다. 누군가 인가하지 않은 CA에서 도메인에 인증서를 받으면 — 침해든, 소셜 엔지니어링이든, 도메인 검증 결함이든 — 인증서가 CT 로그에 나타난다.

모니터링 서비스가 존재한다. 무료 도구나 유료 서비스가 도메인의 새 인증서 발급을 알려준다.

대부분의 도메인 소유자가 CT 로그를 전혀 모니터하지 않는다. 로그가 존재하는지도 모른다. crt.sh를 들어본 적 없다. 비인가 인증서를 잡는 도구가 거기 있다. 대부분이 집어들지 않았다.

CT가 작동하는 이유

CT가 많은 인터넷 전체 보안 개선이 실패한 곳에서 성공한 건 Let’s Encrypt 플레이북을 따랐기 때문이다: 올바른 일을 자동으로 만들어라.

CA는 기록해야 한다. 브라우저는 SCT를 확인해야 한다. 도메인 소유자는 모니터할 수 있지만 꼭 안 해도 된다 — 집행이 이들의 관여 없이 일어난다. 대부분의 도메인 소유자가 CT 로그를 한 번도 안 봐도 시스템이 작동한다.

좋은 설계다. 모두가 참여해야 하는 보안은 확장이 안 된다. 기본으로 작동하고 원하는 사람에게 선택적 모니터링이 있는 보안은 실제로 배포된다.

CT가 신뢰 모델을 고치지는 않았다. 브라우저는 여전히 100개 넘는 CA를 신뢰한다. 어느 하나든 어떤 도메인에 인증서를 발급할 수 있다. 하지만 CT 덕분에 비밀리에는 못 한다. 신뢰 위에 세워진 시스템에서 투명성은 검증 다음으로 좋은 것이다.