공인 인증 기관이 침해되면 피해가 그 회사에 국한되지 않는다.

브라우저 신뢰 모델로 직행한다. 브라우저가 사실상 이렇게 말하고 있으니까: 이 신뢰 세트의 어떤 CA든 도메인을 보증하면 우리는 믿겠다. CA 하나를 침해하면 벤더의 명성만 훔치는 게 아니다. 다른 모두를 위한 믿을 만한 거짓을 찍어낼 능력을 얻는다.

DigiNotar가 그 추상적 문제를 끔찍하게 구체적으로 만들었다.

2011년 여름

DigiNotar는 모든 주요 브라우저가 신뢰하는 네덜란드 인증 기관이었다. 2011년 중반, 공격자가 회사를 침해하고 대량의 고가치 도메인에 대한 위조 인증서를 발급한 게 드러났다. Fox-IT의 사후 보고서는 심각하게 침해된 환경을 설명하고 500개 이상의 부정 인증서를 세었다. 가장 악명 높은 것은 *.google.com용이었다.

이건 탁상공론이 아니었다.

누군가 — 이란 정부로 널리 귀속되는 — 그 위조 Google 인증서를 써서 약 30만 개 IP 주소 — 거의 전부 이란 — 에서 나온 Google 트래픽을 가로챘다. 이메일, 검색 기록, 개인 통신의 실시간 중간자 감시. 완벽히 유효한 TLS 인증서로 보호되는. 자물쇠도 떠 있었다. 연결은 “안전”했다.

공격이 드러난 건 Chrome이 Google 도메인에 대해 기대하는 인증서를 고정(pinning)해 두었기 때문이다. 이란의 한 Chrome 사용자가 오류를 만났고 — 인증서가 Chrome이 Google용으로 예상한 CA에서 온 게 아니었다 — 그 내용을 Gmail 도움말 포럼에 올렸다. 브라우저 기능 하나가 국가 수준 감시 작전을 드러냈다. 그 고정이 없었다면 훨씬 오래 이어졌을 수 있다.

CA 신뢰의 작동 방식 (그리고 왜 취약한가)

브라우저는 루트 스토어를 탑재한다 — 신뢰하는 루트 인증서 목록이다. 예를 들어 Mozilla는 TLS용으로 루트 약 120개를 신뢰하는데, 그 주인은 수십 개 조직이고, 각자 중간 CA에 발급 권한을 위임할 수 있다. 이 목록으로 이어지는 어떤 CA든 인터넷의 어떤 도메인에 대해 인증서를 발급할 수 있다. 기술적 제한이 없다. 네덜란드의 작은 CA가 google.com에 인증서를 발급할 수 있고, 모든 브라우저가 수락한다.

신뢰 모델이 “클럽 멤버 전원 신뢰”다. 멤버 하나가 침해되면 전체 시스템이 취약하다. 침해된 CA의 고객뿐만 아니라 인터넷의 모든 도메인에 대해.

구조적 결함이다. 웹의 보안이 그 CA 전부 — 그리고 그들이 위임한 중간 CA 전부 — 가 항상 완벽한 운영 보안을 유지하는 데 달려 있다. CA 하나, 침해 한 번이면 어디든 어떤 사이트든 HTTPS를 훼손할 수 있다.

여파

DigiNotar는 몇 주 안에 죽었다. 브라우저가 공개 며칠 안에 모든 DigiNotar 인증서의 신뢰를 폐기했다. 회사가 파산 신청했다. 디지털 신원 시스템에 DigiNotar 인증서를 쓰던 네덜란드 정부가 모든 인증서를 긴급 마이그레이션해야 했다 — 정부 서비스 전반에 영향을 미치는 수 주간의 분투.

하지만 DigiNotar 사건은 회사 하나를 죽인 게 아니다. PKI 생태계 전체가 회피해오던 질문을 마주하게 강제했다: 부정 인증서가 공격에 사용되기 전에 어떻게 감지할 것인가?

Certificate Transparency가 모든 걸 바꿨다

답은 Certificate Transparency(CT)였다. Google 엔지니어들이 제안하고 2013년 RFC 6962로 발표된 CT는 인증서를 발급 시점(또는 그 직전)에 공개 감사 가능한 추가 전용 로그에 올린다. 프로토콜 자체가 기록을 강제하지는 않는다. 강제하는 건 브라우저다.

핵심 속성: 추가 전용. 인증서는 로그에 추가될 수 있지만 삭제하거나 수정할 수 없다. 로그는 머클 트리 — 블록체인 뒤의 같은 데이터 구조 — 라서 변조가 암호학적으로 감지 가능하다.

Chrome(2018년부터)과 Apple 플랫폼은 인증서에 SCT(Signed Certificate Timestamp) — 인증서가 CT 로그에 제출됐다는 증명 — 가 있어야 받아준다. Chrome은 인증서 유효 기간에 따라 독립 로그 2~3개의 SCT를 요구한다. SCT가 없는 인증서는 거부된다.

DigiNotar가 오늘 일어났다면 위조 *.google.com 인증서는 Chrome이나 Safari에서 통하려면 로그에 올라가야 한다 — 즉 공개된다, 대개 몇 시간 안에. 모니터링 서비스가 플래그한다. Google이 본다. 공격 창이 “수 주간의 미탐지 감시”에서 “누군가 발견하기까지 수 시간”으로 줄어든다.

CT가 CA 침해를 불가능하게 만들지는 않았다. CA 침해를 보이게 만들었다.

바뀌지 않은 것

여전히 100개 넘는 루트와 그 아래 중간 CA들을 신뢰한다. 어느 하나든 어떤 도메인에 인증서를 발급할 수 있다. CT가 부정 발급을 감지 가능하게 만들었지만 방지하지는 않는다. 인증서는 존재하고, 기록되고, 그다음 누군가 알아채고 대응해야 한다.

대응 시간이 중요하다. 발급부터 탐지까지 몇 시간 사이에도 위조 인증서는 실제 피해를 낼 수 있다. CT는 그 창을 좁혔다. 닫지는 못했다.

CAA 레코드: 덜 쓰이는 방어

도메인 소유자가 어떤 CA가 자기 도메인에 인증서를 발급할 수 있는지 제한하는 메커니즘이 하나 있다. DNS에 게시하는 CAA(Certification Authority Authorization) 레코드. “이 CA만 이 도메인에 인증서를 발급할 수 있다”고 말한다.

2017년부터 CA는 발급 전에 CAA 레코드를 확인해야 한다. CAA 레코드가 “Let’s Encrypt만”이라고 하면, 침해된 CA가 인증서를 발급하려 할 때 CAA 제한을 보고 거부해야 한다.

해야 한다. 집행이 CA 측에 있다. 완전히 침해된 CA — 공격자가 발급 파이프라인에 접근한 — 는 CAA를 전혀 확인하지 않을 수 있다. 실수하는 정직한 CA에는 통하는 방어지만, 통째로 넘어간 CA 앞에서는 힘이 약하다.

CAA 채택은 아직 낮다. 대부분의 도메인이 게시하지 않는다. 5분이면 추가하는 DNS 레코드이고 CA 침해 노출을 줄여준다. 비용 대비 효과가 훌륭하다. 채택은 처참하다.

교훈

DigiNotar는 웹의 신뢰 모델에 오차 여유가 없다는 걸 증명했다. CA 하나, 침해 하나로 정부가 모든 시민에게 어떤 웹사이트든 사칭할 수 있다. 해결책 — Certificate Transparency — 은 올바른 엔지니어링 대응이었다. 하지만 기저 아키텍처는 바뀌지 않았다. 여전히 많은 CA를 신뢰하고, 그중 어느 하나든 다음 DigiNotar가 될 수 있다.

할 수 있는 최선: CAA 레코드를 게시하고, 도메인의 CT 로그를 모니터하고, 브라우저의 자물쇠가 루트 스토어에서 가장 약한 CA만큼만 신뢰할 수 있다는 걸 이해하는 것이다.