공인 인증 기관이 침해되면 피해가 그 회사에 국한되지 않는다.
브라우저 신뢰 모델로 직행한다. 브라우저가 사실상 이렇게 말하고 있으니까: 이 신뢰 세트의 어떤 CA든 도메인을 보증하면 우리는 믿겠다. CA 하나를 침해하면 벤더의 명성만 훔치는 게 아니다. 다른 모두를 위한 믿을 만한 거짓을 찍어낼 능력을 얻는다.
DigiNotar가 그 추상적 문제를 끔찍하게 구체적으로 만들었다.
2011년 여름
DigiNotar는 모든 주요 브라우저가 신뢰하는 네덜란드 인증 기관이었다. 2011년 중반, 공격자가 회사를 침해하고 대량의 고가치 도메인에 대한 위조 인증서를 발급한 게 드러났다. Fox-IT의 사후 보고서는 심각하게 침해된 환경을 설명하고 500개 이상의 부정 인증서를 세었다. 가장 악명 높은 것은 *.google.com용이었다.
학술적 실수가 아니었다.
누군가 — 이란 정부로 널리 귀속되는 — 그 위조 Google 인증서를 써서 약 30만 이란 사용자의 Gmail 트래픽을 가로챘다. 이메일, 검색 기록, 개인 통신의 실시간 중간자 감시. 완벽히 유효한 TLS 인증서로 보호되는. 자물쇠는 초록색이었다. 연결은 “안전”했다.
Chrome이 Google 도메인에 인증서 고정을 배포해놓지 않았다면 발견되지 않았을 수 있다. Chrome이 인증서가 예상 CA에서 온 게 아닌 걸 알아차렸다. 브라우저 기능 하나가 국가 수준 감시 작전을 잡았다.
CA 신뢰의 작동 방식 (그리고 왜 취약한가)
브라우저는 루트 스토어를 탑재한다 — 약 100-150개의 신뢰하는 인증 기관 목록. 그 목록의 어떤 CA든 인터넷의 어떤 도메인에 대해 인증서를 발급할 수 있다. 기술적 제한이 없다. 네덜란드의 작은 CA가 google.com에 인증서를 발급할 수 있고, 모든 브라우저가 수락한다.
신뢰 모델이 “클럽 멤버 전원 신뢰”다. 멤버 하나가 침해되면 전체 시스템이 취약하다. 침해된 CA의 고객뿐만 아니라 인터넷의 모든 도메인에 대해.
구조적 결함이다. 웹의 보안이 100개 넘는 CA 전부가 항상 완벽한 운영 보안을 유지하는 데 달려 있다. CA 하나, 침해 한 번이면 어디든 어떤 사이트든 HTTPS를 훼손할 수 있다.
여파
DigiNotar는 몇 주 안에 죽었다. 브라우저가 공개 며칠 안에 모든 DigiNotar 인증서의 신뢰를 폐기했다. 회사가 파산 신청했다. 디지털 신원 시스템에 DigiNotar 인증서를 쓰던 네덜란드 정부가 모든 인증서를 긴급 마이그레이션해야 했다 — 정부 서비스 전반에 영향을 미치는 수 주간의 분투.
하지만 DigiNotar 사건은 회사 하나를 죽인 게 아니다. PKI 생태계 전체가 회피해오던 질문을 마주하게 강제했다: 부정 인증서가 공격에 사용되기 전에 어떻게 감지할 것인가?
Certificate Transparency가 모든 걸 바꿨다
답은 Certificate Transparency(CT)였다. Google 엔지니어가 제안하고 RFC 6962로 표준화한 CT는 모든 공개 신뢰 인증서가 발급 전(또는 직후) 공개 감사 가능한 추가 전용 로그에 기록되도록 요구한다.
핵심 속성: 추가 전용. 인증서는 로그에 추가될 수 있지만 삭제하거나 수정할 수 없다. 로그는 머클 트리 — 블록체인 뒤의 같은 데이터 구조 — 라서 변조가 암호학적으로 감지 가능하다.
브라우저는 이제 SCT(Signed Certificate Timestamp) — 인증서가 CT 로그에 제출됐다는 증명 — 를 요구한다. Chrome은 인증서 유효 기간에 따라 독립 로그 2-3개의 SCT를 요구한다. SCT가 없는 인증서는 거부된다.
DigiNotar가 오늘 일어났다면 위조 *.google.com 인증서가 몇 시간 안에 CT 로그에 나타날 것이다. 모니터링 서비스가 플래그한다. Google이 본다. 공격 창이 “수 주간의 미탐지 감시”에서 “누군가 발견하기까지 수 시간”으로 줄어든다.
CT가 CA 침해를 불가능하게 만들지는 않았다. CA 침해를 보이게 만들었다.
바뀌지 않은 것
여전히 100개 넘는 CA를 신뢰한다. 어느 하나든 어떤 도메인에 인증서를 발급할 수 있다. CT가 부정 발급을 감지 가능하게 만들었지만 방지하지는 않는다.
CAA 레코드: 덜 쓰이는 방어
도메인 소유자가 어떤 CA가 자기 도메인에 인증서를 발급할 수 있는지 제한하는 메커니즘이 하나 있다. DNS에 게시하는 CAA(Certification Authority Authorization) 레코드. “이 CA만 이 도메인에 인증서를 발급할 수 있다”고 말한다.
2017년부터 CA는 발급 전에 CAA 레코드를 확인해야 한다. CAA 레코드가 “Let’s Encrypt만”이라고 하면, 침해된 CA가 인증서를 발급하려 할 때 CAA 제한을 보고 거부해야 한다.
해야 한다. 집행이 CA 측에 있다. 완전히 침해된 CA — 공격자가 발급 파이프라인에 접근한 — 는 CAA를 전혀 확인하지 않을 수 있다.
CAA 채택은 아직 낮다. 대부분의 도메인이 게시하지 않는다. 5분이면 추가하는 DNS 레코드이고 CA 침해 노출을 줄여준다. 비용 대비 효과가 훌륭하다. 채택은 처참하다.
교훈
DigiNotar는 웹의 신뢰 모델에 오차 여유가 없다는 걸 증명했다. CA 하나, 침해 하나로 정부가 모든 시민에게 어떤 웹사이트든 사칭할 수 있다. 해결책 — Certificate Transparency — 은 올바른 엔지니어링 대응이었다. 하지만 기저 아키텍처는 바뀌지 않았다. 여전히 많은 CA를 신뢰하고, 그중 어느 하나든 다음 DigiNotar가 될 수 있다.
할 수 있는 최선: CAA 레코드를 게시하고, 도메인의 CT 로그를 모니터하고, 브라우저의 자물쇠가 루트 스토어에서 가장 약한 CA만큼만 신뢰할 수 있다는 걸 이해하는 것이다.