Paperis 아티클
웹 PKI의 신뢰는 가장 약한 고리로 결정된다. 브라우저가 신뢰하는 수백 개 인증기관 중 어느 하나라도 임의 도메인의 인증서를 발급할 수 있고, 실제로 하나로 충분했다. 그래서 해법이 '더 믿을 만한 기관'이 아니라 '모든 발급을 공개 추가전용 로그에 적고 누구나 감시하게 만드는 것'이 됐다 — 블록체인 없이, 그리고 이미 전 세계에 배포된 채로. 포함 증명·일관성 증명·SCT·모니터·감사자가 무엇을 보장하는지, 그리고 확인 장치를 놓는 것과 실제로 확인되는 것이 왜 다른 일인지.
이 글은 AI가 연구 논문을 바탕으로 작성한 교육·정보 제공용 콘텐츠이며, 전문가의 조언을 대체하지 않습니다. 오류를 발견하셨나요? 알려주세요
© 2026 네오쿤스(Paperis) · 링크 공유는 환영합니다. 전문 전재·재배포는 사전 허가가 필요합니다.
이 시리즈는 줄곧 하나를 물어 왔다. 중개자를 믿지 않고도 무언가를 확인할 수 있는가.
지금까지의 답은 대체로 "가능은 한데, 아직 거기까지는"이었다. 합의는 이론이 단단해도 실제 층위마다 권력이 다시 모였고, 공개하지 않고 증명하는 도구는 아름답지만 그 자체가 또 하나의 블랙박스가 될 수 있었고, 투표에서는 확인 가능성과 비밀이 정면으로 충돌했다. 근사한 설계가 실험실을 나오지 못하거나, 나오더라도 작은 규모에 머물렀다.
그런데 "믿지 말고 확인하라"를 블록체인 없이, 이미 전 세계 웹에 배포해 놓은 물건이 하나 있다. 이름은 인증서 투명성(Certificate Transparency, 이하 CT)이다. 오늘 당신이 연 거의 모든 HTTPS 사이트 뒤에서 이미 돌아가고 있고, 당신은 그것이 있다는 사실조차 몰랐을 것이다.
이 글은 그 물건이 무엇을 성취했고 무엇을 성취하지 못했는지를 다룬다. 결론을 미리 말해 둔다. 확인 장치를 놓는 것과 실제로 확인되는 것은 다른 일이다. CT는 앞의 절반을 놀랄 만큼 성공적으로 해냈고, 뒤의 절반은 아직 논쟁 중이다.
근거에 대해 한 가지 미리 밝혀 둔다. 이 글이 인용하는 arXiv 문헌은 공개 서버에 올라온 판본이며, 학술지·학회 게재 여부는 확인하지 않았다 — 공개돼 있다는 사실 자체는 동료심사 여부를 말해 주지 않는다. 심사를 거친 지면에 실린 것, 워킹페이퍼, 프리프린트 서버 판본은 인용마다 구분해 적었고, 특히 하중이 큰 주장에는 인용 옆에 등급을 함께 붙였다.
주소창에 자물쇠가 뜨면 두 가지를 뜻한다고 배운다. 통신이 암호화됐다는 것, 그리고 상대가 진짜 그 사이트라는 것.
앞의 절반은 대체로 맞다. 까다로운 것은 뒤의 절반이다.
웹의 무결성과 신뢰는 X.509 인증서라는 문서 위에 서 있다 (arXiv:2407.02287). 이 문서는 인증기관(Certificate Authority, 이하 CA)이라 불리는 제3자가 "이 도메인 이름은 이 공개키의 주인이 맞다"고 서명해 준 증서다. 브라우저와 운영체제는 신뢰할 CA들의 목록 — 뿌리 저장소 — 을 들고 다니고, 그 목록 안 기관이 서명한 인증서면 자물쇠를 띄운다. 오늘날 인터넷의 수많은 응용이 이 구조 위에서 종단간 보안을 얻는다 (arXiv:2401.18053).
그러니 통념의 정확한 형태는 이것이다. "믿을 만한 기관을 잘 골라 두면 된다."
이 통념은 나쁘지 않은 출발점이다. 다만 이 시스템에서 "잘 골라 둔다"가 무슨 뜻인지가 문제다.
결함은 개별 기관의 품질이 아니라 구조에 있다.
오늘의 웹 PKI에서는 모든 CA가 동등하게 신뢰되고, 보안은 가장 약한 고리로 정의된다 (arXiv:2108.08581 — 공개 서버 판본, 게재 여부 미확인). 이 한 문장이 이 글 전체의 출발점이다.
무슨 뜻인지 구체적으로 보자. 소프트웨어 제품들은 서로 다른 뿌리 저장소를 유지하는데, 각각이 보통 수백 개의 신뢰된 뿌리를 담고 있고, 그 각각이 어떤 도메인에 대해서든 "신뢰되는" 인증서를 발급할 수 있다 (arXiv:2001.04319 — 공개 서버 판본, 게재 여부 미확인). 뿌리 CA는 중간 CA에 권한을 위임할 수도 있어서, 최종 사용자가 어떤 기관이 정말 신뢰할 만한지 가려내는 일은 사실상 불가능하다 (DOI: 10.1142/s0218126623501037 — 공학 일반 학술지 게재).
즉 당신이 어느 CA에서 인증서를 받았는지는 당신의 안전을 결정하지 못한다. 다른 누군가가 당신의 도메인 이름으로 인증서를 받아 낼 수 있느냐가 결정한다. 그리고 그 "누군가"의 후보는 목록 안의 모든 기관이다.
CT의 설계 배경을 정리한 한 실무 문헌은 사건 하나를 이렇게 기록한다. 어떤 인증기관에서 최소 531건의 부정 인증서가 발급됐고, 그 기관은 자기 시스템의 침해를 한 달 넘게 알고 있었으며, 오발급된 인증서의 전체 기록조차 갖고 있지 않았다. 그래서 최종 집계는 영영 알 수 없다 (DOI: 10.1145/2668152.2668154 — 학술지가 아니라 실무 매거진 기고).
같은 사건을 정책·규제 관점에서 분석한 연구는 다른 각도로 요약한다. 당시 54개 관할권에 흩어진 650개의 인증기관 중 단 하나에 대한 성공적 공격만으로 임의의 웹사이트나 서비스에 대한 거짓 인증서를 만들 수 있었다. 그리고 그 침해가 알려지지 않은 채로 있던 90일 동안 브라우저들은 그 기관의 인증서를 계속 신뢰했고, 그 사이 약 30만 명의 통신이 가로채였다. 저자들의 표현으로, 각 CA가 생태계 전체 보안의 단일 실패점이다 (DOI: 10.2139/ssrn.2031409 — SSRN 워킹페이퍼, 동료심사 여부 미확인).
이 글은 그 사건의 배후나 소재지를 다루지 않는다. 중요한 것은 무엇이 어떻게 가능했는가뿐이고, 그 답은 위 문장에 이미 다 들어 있다. 하나가 흔들리면 전부가 흔들린다.
문헌은 이 구조적 성격을 여러 방향에서 확인한다.
신뢰 모형의 결함이 기술만이 아니라 법·경제·조직에 걸쳐 있다는 분석이 있고 (DOI: 10.2139/ssrn.2249042 — SSRN 워킹페이퍼, 동료심사 여부 미확인), 생태계를 갱신 조사한 연구는 더 아프게 적는다. 보편적 암호화를 향해 큰 걸음을 내디뎠지만 그것은 통신 상대 인증의 신뢰를 대가로 한 것이었고, 참여자들 사이의 어긋난 인센티브에 뿌리를 둔 문제가 체계적으로 남아 있으며, 제안된 보안 확장들이 그 인센티브를 제대로 재정렬하지 못한다는 것이다 (arXiv:1801.00933 — 공개 서버 판본, 게재 여부 미확인).
무엇보다 브라우저에게 주어진 선택지가 너무 거칠다. 오늘의 웹 PKI에서 클라이언트가 할 수 있는 것은 의심스러운 CA를 완전히 불신하는 것뿐이고, 그렇게 하면 그 기관이 발급한 멀쩡한 인증서들까지 한꺼번에 거부되는 부수 피해가 난다 (arXiv:2108.08581). 신뢰가 이진값이면 대응도 이진값이 된다.
여기서 방향이 꺾인다. 그리고 이 꺾임이 이 시리즈에서 우리가 계속 찾던 그것이다.
CT의 목표는 단순하다. 발급된 모든 인증서를 공개 로그에 저장하고, 오발급 가능성이 있는 인증서의 존재를 누구나 확인할 수 있게 하는 것 (DOI: 10.56553/popets-2022-0075). 로그는 공개적이고, 감사 가능하며, 추가전용(append-only) 방식으로 인증서를 보관한다 (arXiv:2001.04319). 추가전용이란 뒤에 붙이는 것만 되고, 이미 적힌 것을 고치거나 지우는 건 안 된다는 뜻이다.
이 전환의 성격을 가장 정확히 적은 문장은 어느 프라이버시 학회 논문에 있다. 주요 브라우저들이 CA 생태계의 가장 약한 고리 보안을 극복하기 위해 CT 로깅을 추가로 의무화하기 시작했다는 것이다 (DOI: 10.2478/popets-2021-0024).
읽는 방식을 바꿔 보자. 답은 "더 믿을 만한 기관을 고르자"가 아니었다. "누가 무엇을 발급했는지 전부 적어 놓고, 아무나 읽게 하자"였다. 기관의 자격을 심사하는 대신 기관의 행동을 기록으로 남긴 것이다.
그리고 이 설계가 약속하는 것을 과장하지 않는 문장이 하나 있다. 어느 논문은 이렇게 쓴다 — 공개 검증 가능한 CT 로그에 대한 신뢰는 암호·gossip·감사·모니터링을 통해 줄어든다 (arXiv:1711.03952 — 공개 서버 판본, 게재 여부 미확인).
없어진다가 아니라 줄어든다. 이 단어 선택이 이 글의 전부다.
CT 로그는 머클 트리 위에 서 있다. 데이터를 해시로 두 개씩 묶어 올라가며 꼭대기에 하나의 값(루트)을 만드는 자료구조다. 이 시리즈에서 이미 여러 번 스쳤으니, 여기서는 CT에 필요한 두 가지만 본다.
CT 프로토콜을 머클 트리까지 정밀하게 모형화해 최초로 형식 검증한 연구는 그 두 가지를 이렇게 부른다 — 데이터가 거기 있다는 것의 간결한 증명과 트리가 확장됐다는 것의 간결한 증명 (arXiv:2303.04500 — 공개 서버 판본, 게재 여부 미확인).
두 번째가 핵심이다. 로그 운영자를 정직하다고 믿을 필요가 없다. 거짓말하면 들킨다만 있으면 된다. 이것이 "신뢰를 줄인다"는 말의 정확한 의미다. 신뢰의 양을 줄이는 게 아니라, 신뢰의 종류를 바꾸는 것이다. "이 사람은 나쁜 짓을 안 할 것이다"에서 "이 사람이 나쁜 짓을 하면 남는다"로.
이 성질은 사실 CT만의 것이 아니다. 보안 상대 타임스탬프와 보안 추가전용 로그는 역사적으로 거의 독립된 두 연구 계보였는데, 한 체계화 논문은 둘이 같은 동전의 양면 — 접두 관계의 인증이라고 정리하고, 자기들이 아는 모든 해시 기반 타임스탬프·로그 설계를 포괄하는 그래프 종류를 정의한다 (arXiv:2308.13836). "과거는 현재의 접두사여야 한다"는 요구가 이 계열 전체의 공통 뼈대라는 뜻이다.
증명 크기는 인증서 수에 로그 비례한다. 이걸 상수 크기로 줄이려는 암호학적 시도도 있다 (arXiv:1704.04937).
로그에 인증서를 제출하면 로그는 SCT(Signed Certificate Timestamp, 서명된 인증서 타임스탬프)를 돌려준다. "이 인증서를 정해진 시간 안에 로그에 넣겠다"고 로그가 서명해 준 약속표다.
이 표가 CT를 실제로 배포 가능하게 만들었다. 브라우저는 SCT가 붙지 않은 인증서를 거부하기만 하면 되고, 그러면 CA들은 로그에 넣지 않을 도리가 없어진다. 세상의 모든 CA를 설득할 필요도, 새 프로토콜을 표준화할 필요도 없었다. 브라우저 정책 한 줄로 전 세계 발급이 로그로 흘러들어 오게 만든 것이다.
여기에 이 글의 핵심 균열이 있다. 표는 약속이지 증거가 아니다. 인증서가 실제로 로그에 들어갔는지는 나중에 포함 증명을 받아 확인해야 한다. 그 확인 작업의 이름이 SCT 감사이고, 아래에서 다시 만난다.
CT는 감시 노동을 둘로 나눈다.
모니터는 로그의 모든 항목을 하나도 빠짐없이 관찰하면서 자기가 관심 있는 수상한 인증서를 찾는다. 도메인 소유자라면 "내 도메인 이름이 붙은 인증서가 나왔는데 내가 신청한 게 아니다"를 찾는 일이다. 누구나 모니터를 돌릴 수 있다. 다만 지속적 운영과 로그 사본이 필요하다 (arXiv:1711.03952).
그리고 여기서 익숙한 일이 벌어진다. 부담이 크니 대행업이 생긴다. 신뢰받는 제3자가 모니터를 돌려 주고 등록한 사람에게 "foo.com 인증서가 나오면 알려 줘" 식의 선택적 알림을 보내 주는 서비스형 모니터링이다. 신뢰를 없애려고 만든 시스템 안에 신뢰받는 제3자가 다시 들어선 것이다. 그래서 그 알림이 정확한지(빠뜨린 게 없는지) 검증할 수 있게 하는 확장이 제안됐다 — 대행자에게 두는 신뢰를 다시 줄이려는 시도다 (arXiv:1711.03952).
감사자는 다른 일을 한다. 로그가 일관되고 정직하게 행동하는지를 확인한다. 로그 기반 접근이 오래도록 결여했던 요소가 정확히 이것이다 — 클라이언트가 로그의 일관성과 정직성을 검증할 방법 (arXiv:1511.01514).
여기서 중요한 구분을 하나 해 두자. CT는 오발급을 막지 않는다. 드러낼 뿐이다.
막는 쪽 장치는 따로 있다. CAA는 도메인 소유자가 DNS에 "내 도메인의 인증서는 이 CA만 발급할 수 있다"고 적어 두는 안전장치다. 그런데 CAA의 개념과 운영상의 결함이 오발급 방지 효과를 훼손한다는 지적이 있다 (arXiv:2411.07702).
400만 개 인기 도메인을 실측한 연구는 더 구체적이다. CAA는 거의 전적으로 DNSSEC이 없는 곳에 배포되고, 반대로 DNSSEC으로 보호되는 서비스명은 인증서 방어에 DNS를 쓰지 않는 경향을 보인다. 형식적으로는 대체로 올바르게 배포됐지만 CAA 문자열이 CA를 선별적으로 구분하지 못하고, 수많은 도메인이 자기 CAA가 허용한 범위를 벗어난 인증서를 갖고 있다. DANE의 TLSA 레코드는 반복적으로 관리가 부실했고 때로 DNSSEC 없이 존재했다 (arXiv:2407.02287).
장치를 놓는 것과 그 장치가 실제로 일하는 것은 다르다. 이 문장은 지금부터 CT 자신에게 되돌아온다.
이 주제에서 가장 불편한 실측이 여기 있다.
CT의 핵심 요구는 "주어진 인증서가 실제로 하나 이상의 로그 안에 있다"는 것이다. 그런데 이 문제를 체계화한 프라이버시 학회 논문은 그 배포 시점의 상태를 이렇게 적는다 — 대부분의 개별 클라이언트는 자기가 본 인증서가 로그에 있는지 확인하지 않는다 (DOI: 10.56553/popets-2022-0075).
이유는 게으름이 아니다. 프라이버시다. 클라이언트가 포함 증명을 로그에 직접 요청하면 어떤 인증서인지가 그대로 드러나고, 그건 그 사용자가 어디를 방문했는지를 드러내는 것과 같다. 즉 확인하려면 프라이버시를 내주어야 한다는 구조다.
그래서 프라이버시를 지키면서 감사하는 기법들이 여러 갈래로 제안됐다. 브라우저가 사용자 프라이버시를 침해하지 않고 CT 로그를 감사하게 하는 방식 (DOI: 10.1515/popets-2017-0052), 강한 익명성을 갖는 오블리비어스 파일 공유 시스템을 써서 질의를 감추는 방식 (arXiv:1905.09478) 등이다.
그런데 같은 체계화 논문이 제안들을 훑고 나서 지적하는 가장 뼈아픈 한계는 다른 데 있다. 대부분의 제안이 클라이언트와 로그 사이의 상호작용에만 집중하고, 클라이언트가 "로그에 없는 인증서를 봤다"는 사실을 어떻게 비공개로 신고할 것인가는 열어 둔다는 것이다 (DOI: 10.56553/popets-2022-0075).
확인해서 이상을 발견해도 말할 방법이 없으면, 확인은 절반만 끝난 것이다.
CT는 이론상 로그를 신뢰할 필요가 없다. 그런데 그 전제는 조건 하나에 기댄다. 모든 클라이언트가 같은 로그를 보고 암호학적으로 검증한다는 것.
그래서 실무적으로는 gossip — 서로 본 것을 대조해 보는 절차 — 이 어떤 형태로든 필요하다. 그리고 이것이 CT의 가장 오래된 미해결 문제다. 여러 주요 브라우저 벤더가 CT를 채택했음에도 널리 배포된 gossip 메커니즘은 없다 (arXiv:1806.08817 — 공개 서버 판본, 게재 여부 미확인).
왜 문제인가. 로그가 표적에게만 다른 버전을 보여 줄 수 있다면 — split-view(또는 split-world) — 로그 기반 PKI의 보장이 무너진다. 표적은 자기가 보는 로그 안에서 아무 이상도 발견하지 못하고, 나머지 세상은 표적이 무엇을 보고 있는지 모른다. 로그 기반 PKI 개선안들이 여전히 이 공격에 취약하다는 지적은 여러 곳에서 반복된다 (arXiv:1806.03914, DOI: 10.1002/dac.4503).
첫 gossip 프로토콜을 제안한 연구부터 이 문제가 프라이버시·효율·배포가능성 때문에 어렵다고 명시했다 (arXiv:1511.01514). 이후 제안들은 창의적이다. 네트워크 장비(라우터·스위치)가 평문으로 오가는 CT 자료를 수동적으로 관찰·집계해 경로 밖에서 주기적으로 로그 일관성을 검증하게 하는 방식 — gossip을 네트워크가 서비스로 제공하는 것 — 이 제안됐고, 3,500개 자율 시스템과 IPv4 공간의 40%를 대표하는 20일치 측정으로 평가됐다 (arXiv:1806.08817).
그런데 더 근본적인 지적이 있다. 대부분의 제안이 전역 감사자 집합의 존재를 가정하고, 그들이 자기 역할을 제대로 수행하리라고 맹목적으로 믿어야 목표한 투명성이 성립한다는 것이다. 그래서 사용자가 스스로 감사할 수 있게 하는 gossip 프로토콜과 검증 가능한 레지스트리가 제안됐다 (arXiv:2011.04551 — 공개 서버 판본, 게재 여부 미확인).
신뢰를 없앤 자리에 다시 신뢰가 들어선다. 이 패턴은 이 시리즈에서 이미 여러 번 봤다.
CT는 분산된 로그들 위에 서는데, 그 로그들의 정확성이 아직 충분히 보호되지 않는다. 정확히 말하면 이렇다 — CA와 그에 대응하는 로그를 함께 장악한 은밀한 공격자는 여전히 들키지 않고 부정 인증서를 발급할 수 있다 (DOI: 10.2478/popets-2021-0066).
그 대응으로 제안된 것이 로그들의 협업이다. 로그 풀에서 무작위로 선택된 하나가 인증서를 포함시키고 나머지가 그 발급 과정을 목격·증언하게 하면, 신뢰받는 제3자 없이도 로그가 로그를 감사할 수 있다. 그러면 공격자는 참여하는 증인 하나하나를 전부 장악해야 한다 (DOI: 10.2478/popets-2021-0066).
그리고 잘 알려지지 않은 사실이 하나 있다. 로그도 자기 뿌리 목록을 유지한다. CT 도입으로 신뢰 지형이 바뀌면서 로그들은 각자 신뢰하는 뿌리 목록을 갖게 됐고, 그 뿌리로 이어지는 인증서만 기록한다. 이 새로운 지형을 최초로 특성화한 연구는 로그들의 뿌리 저장소를 서로, 그리고 주요 소프트웨어 벤더의 것과 비교하면서 뿌리 저장소 관리 부실이 로그 부정행위와 연결될 수 있음을 보인다 (arXiv:2001.04319 — 공개 서버 판본).
한 익명 브라우징 네트워크에 CT를 얹는 설계를 제안한 논문은 문제를 한 문장으로 못 박는다. 현재 CT 배포에는 로그 운영자가 규칙대로 행동하는지 검증할 강한 메커니즘이 없다 (DOI: 10.2478/popets-2021-0024). 같은 논문은 현재 배포된 CT 강제가 상당 부분 맹목적 신뢰(blind trust)에 기반한다고 표현하고, 확률적으로 CA·로그의 부정 증거를 탐지·공개하는 설계를 제시한다.
대안 설계는 많다. 원장을 붙여 split-view를 제거하자는 제안 (arXiv:1806.03914), 검증 가능한 신뢰 당사자를 둔 대체 PKI (DOI: 10.1155/2018/8527010), 클라이언트 측에서 돌아가는 탈중앙 감사 (DOI: 10.3390/cryptography5020014), 서버가 스스로 인증서 치환 공격을 탐지하고 발원지를 추정하는 방식 (DOI: 10.1049/iet-ifs.2016.0611).
그런데 마지막 논문이 스스로 적는 한 줄이 이 목록 전체의 운명을 설명한다 — 이 문제를 풀겠다는 해법이 여럿 제안됐지만, 복잡성과 배포가능성 문제로 어느 것도 아직 널리 채택되지 않았다 (DOI: 10.1049/iet-ifs.2016.0611).
CT가 이긴 이유가 여기서 역으로 드러난다. CT는 가장 우아한 설계여서 이긴 게 아니라, 브라우저 정책 하나로 강제할 수 있을 만큼 배포 비용이 낮아서 이겼다.
CT 로그의 인증서 수는 지수적으로 증가했고 사이트의 CT 지원도 꾸준히 늘었다. 그런데 바로 그 성공이 새 문제를 만든다. 모든 인증서가 CT 로그에 보인다는 사실 자체가 정보 유출이다.
이걸 실험으로 확인한 연구가 있다. 저자들은 CT 허니팟을 만들었다. 인증서를 발급받되 그 이름을 아무 데도 알리지 않고, 누가 찾아오는지 지켜보는 것이다. 결과는 이렇다 — 인증서 발급 후 불과 몇 분 만에 CT 로그 데이터가 스캐닝 캠페인의 표적 선정에 쓰이고 있었다. 나아가 저자들은 CT에 기록된 방대한 도메인에서 새 서브도메인을 학습·검증하는 방법론까지 제시한다 (arXiv:1809.08325 — 공개 서버 판본, 게재 여부 미확인).
조직 내부용으로만 쓰려던 이름이 인증서를 받는 순간 전 세계에 공표된다. vpn-test.내회사.com 같은 이름이 어떤 정보를 흘리는지는 굳이 설명할 필요가 없을 것이다.
그래서 비공개 서브도메인을 지원하도록 CT를 확장하려는 제안이 나왔다 (DOI: 10.1515/popets-2017-0052). 그리고 이 대가는 앞의 ①번과 같은 뿌리에서 나온다. 확인은 공개를 요구하고, 공개는 대가를 요구한다. 확인하는 쪽(클라이언트)의 프라이버시와 확인당하는 쪽(도메인 소유자)의 프라이버시가 둘 다 값을 치른다.
CT는 발급을 막지 않는다. 그리고 CT가 아예 덮지 않는 영역이 하나 크게 남아 있다.
폐기(revocation) — 이미 발급된 인증서를 "이제 믿지 말라"고 취소하는 일이다. 어떤 인증서가 잘못 발급됐음을 CT가 드러내 줘도, 그것을 무효로 만들고 그 사실을 전 세계 브라우저에 전달하는 것은 별개의 문제다.
그리고 여기가 비어 있다. 인증서 발급에 대한 CT에 상응하는, 모든 폐기의 투명하고 불변인 이력을 제공하는 절차는 채택된 바 없다 (arXiv:2102.04288 — 공개 서버 판본, 게재 여부 미확인). 같은 연구는 100만 건 이상의 폐기된 인증서에 대해 만료 시점부터 상태가 사라질 때까지의 이력을 최초로 종단 추적했고 — 그중 77만 3천 건은 한 인증기관이 한꺼번에 폐기한 것이다 — 폐기 상태가 얼마나 단명한지, 기관마다 관행이 얼마나 다른지를 정량화한다.
폐기가 어려운 것은 새 이야기가 아니다. 폐기 스킴들의 트레이드오프를 분류·분석한 작업은 20년도 더 됐고 (DOI: 10.1145/956981.956991), 최근의 종합 조사도 주요 폐기 스킴들이 프라이버시와 확장성 등 여러 측면에서 한계를 보여 왔다고 정리한다 (DOI: 10.1145/3785653).
여기에 사정이 하나 더 겹친다. 폐기 스킴들이 지연·가용성·프라이버시 문제를 안고 있는데, TLS에 네이티브 위임 메커니즘이 없다는 점이 문제를 키운다. 그래서 도메인 소유자들이 제3자에게 자기 개인키를 공유하는 위험한 관행으로 점점 내몰린다 (arXiv:1906.10775 — 공개 서버 판본, 게재 여부 미확인). 확인 가능성을 아무리 잘 설계해도, 열쇠가 몇 개나 복제돼 있는지를 아무도 모르면 소용이 줄어든다.
폐기에도 투명성을 붙이려는 제안은 있다. 포스트인증서는 인증서 소유자가 발급 CA를 우회해 기존 CT 로그에 직접 제출함으로써 스스로 폐기 절차를 개시하게 한다. CA는 CT 로그를 감시하다가 포스트인증서를 발견하면 폐기를 진행해야 한다. 기존 CT 로그를 그대로 재활용하므로 배포 비용이 낮다는 것이 저자들의 주장이다 (arXiv:2203.02280).
마지막 고리는 사람이다. 그리고 이 고리가 가장 약하다.
결함 있는 TLS 인증서는 인터넷에서 드물지 않고, 대부분은 오설정이나 의도적 배포 같은 양성 원인을 갖는다. 그래서 판단이 흐려진다. 산업 IT 콘퍼런스 참가자 75명이 서로 다른 인증서 검증 오류를 조사하는 과정을 관찰한 연구는 세 가지를 보고한다. IT 종사자들의 견해는 매우 미묘하고 신뢰 판단이 이분법과는 거리가 멀다는 것, 자체 서명 인증서와 이름 제약 인증서가 과신되는 경향을 보인다는 것(후자는 이해도도 낮았다), 그리고 희망적인 대목 — 기존 오류 메시지의 아주 작은 변경만으로도 자원 사용·이해·신뢰 판단이 긍정적으로 개선됐다는 것이다 (arXiv:2207.11610 — 공개 서버 판본, 게재 여부 미확인).
마지막 항목이 중요하다. "사람들이 확인하지 않는다"는 하늘에서 떨어진 상수가 아니라 설계로 움직일 수 있는 변수다.
CA를 만드는 쪽도 검사 대상이다. ACME 기반 오픈소스 CA 구현 네 종의 개발자 작성 테스트를 분석한 연구는 프로토콜 커버리지가 제한적이며(프로토콜 연산 39.5%·오류 25.6%) 프로토콜 버그가 고쳐질 때 회귀 테스트가 거의 추가되지 않는다고 보고하고, 명세에서 행동 모형을 끌어내는 상태 인지 테스트 생성기로 각각 100%까지 끌어올리며 미보고 버그 3건을 찾는다 (DOI: 10.36227/techrxiv.176972158.85579194/v1 — 프리프린트 서버 판본, 게재 여부 미확인). 인증서를 검증하는 구현들 역시 표준 문서에서 규칙을 뽑아 차등 테스트해야 할 만큼 잠재 결함이 있다 (DOI: 10.1145/3355048).
비판만 하고 끝나면 이 글은 반쪽이다. CT는 조용히 아주 큰 것을 하나 해냈다.
공개 기록이 생기자, 설계자가 예상하지 않은 감시자들이 나타났다.
CT 로그를 실시간으로 읽어 준비 중인 피싱 사이트를 인증서 발급 단계에서 잡아내려는 분류 파이프라인이 만들어졌다. 기존 차단 목록 방식은 공격자에게 "기회의 창"을 남기는데, 사이트가 만들어지는 순간을 로그로 포착해 그 창을 줄이자는 발상이다 (arXiv:2106.12343). 표준 준수 검사만으로는 걸러지지 않는 이상 인증서를 찾아내는 탐지 기법이 CT 로그 표본으로 검증됐고 (arXiv:2405.05206), CT 스트림을 브라우저 렌더링·의미 분석과 결합해 새 사이트를 실시간 분류하는 시스템은 23.83시간 동안 851만 건의 X.509 기록을 처리했다고 보고한다 (DOI: 10.47813/2782-5280-2026-5-3-1001-1014 — 소규모 지역 학술지 게재). TLS 인증서를 검증 가능한 신호로 삼아 네트워크상의 DNS 조작을 탐지한 연구는, 기존의 일관성 기반 휴리스틱이 72.45%의 오탐을 냈음을 보인다 (arXiv:2305.08189).
이 목록의 공통점은 하나다. 전부 로그가 공개돼 있기 때문에 가능했고, CT 설계자들이 의도한 용도가 아니다. 공개된 기록은 그것을 만든 사람이 상상한 것보다 더 많은 일을 한다.
로그 기반 투명성 기술 전반을 체계화한 논문은 이 지점을 정확히 짚는다. 투명성의 목적과 유용성과 함정을 정리하면서, 투명성이 시스템에 이의를 제기하고 운영자에게 책임을 묻는 외부 메커니즘과 어떻게 연결되는지를 함께 다룬다 (arXiv:2305.01378). 로그는 그 외부 메커니즘의 입력일 뿐이다. 로그 자체는 아무에게도 책임을 묻지 않는다.
제도 쪽 성취도 있다. 인증서 생산자와 브라우저 벤더가 함께 발급 기준선을, 그리고 CT 자체를 개발하고 집행하는 비정부 포럼이 존재한다. 2013~2022년 회의록 369건, 123개 조직 553명의 참석 기록, 192건의 투표를 분석한 거버넌스 연구는 이 협력이 왜 안정적으로 유지되는지를 참여자들의 인센티브 구조로 설명한다 (DOI: 10.2139/ssrn.4528663 — SSRN 워킹페이퍼, 동료심사 여부 미확인). 확인 가능성이 관행이 되려면 그 관행을 유지하는 제도가 있어야 한다는 뜻이다.
물론 남는 걱정도 있다. 두 정치·경제권의 도메인 인증서를 조사한 최근 연구는 양쪽 모두 75% 이상이 단일 국가에 기반을 둔 CA에서 발급된다고 보고하며, 그 의존도가 디지털 주권 측면의 위험이 될 수 있다고 본다 (arXiv:2504.16897). 신뢰를 기록으로 바꿨어도, 발급 자체는 여전히 좁은 곳에 모여 있다.
세 문장으로 정리한다.
첫째, 이 문제는 "누구를 믿을 것인가"로 풀리지 않는다. 모든 CA가 동등하게 신뢰되는 구조에서 보안은 가장 약한 고리로 정의된다. 뿌리 목록 안 수백 개 중 어느 하나만 흔들려도 임의 도메인의 인증서가 만들어지고, 실제로 하나가 흔들렸을 때 그 하나만으로 충분했다.
둘째, 그래서 해법이 기관 선택에서 기록 공개로 옮겨 갔다. 모든 발급을 추가전용 로그에 적고, 포함 증명과 일관성 증명으로 "거짓말하면 들킨다"를 만들고, SCT라는 약속표로 브라우저가 그것을 강제하게 하고, 모니터와 감사자에게 읽게 한다. 원장도 합의 알고리즘도 필요 없었고, 이건 이미 전 세계에 배포돼 있다.
셋째, 그런데 적히는 것만으로는 아무 일도 일어나지 않는다. 그 배포 시점의 실측에 따르면 대부분의 클라이언트는 자기가 본 인증서가 로그에 있는지 확인하지 않았다. 모두가 같은 로그를 보고 있는지 맞춰 보는 gossip은 널리 배포되지 않았다. 로그 운영자가 규칙대로 행동하는지 검증할 강한 메커니즘도 없다. 확인 장치는 놓였고, 확인은 아직 부분적으로만 일어난다.
정직하게 남겨 둘 것들이 더 있다. CT는 발급을 막지 않는다 — 드러낼 뿐이다. 폐기에는 아직 CT에 상응하는 투명성이 없다. 공개 로그는 지키는 사람에게도 열려 있지만 표적을 찾는 사람에게도 똑같이 열려 있고, 그 시차는 몇 분이었다. 그리고 이 글의 모든 수치는 각 연구가 각자의 시점에 각자의 방법으로 관측한 값이다 — 이 분야에서 엇갈리는 측정 결과들이 실제 배포의 차이가 아니라 측정 설정의 차이에 뿌리를 둔다는 지적이 이미 나와 있다 (arXiv:2401.18053 — 공개 서버 판본, 게재 여부 미확인). 오늘의 배포 상태는 이 글이 쓰인 뒤에도 계속 움직인다.
그러니 이 시리즈의 질문에 CT가 주는 답은 이렇다.
무엇을 믿어야 하는가 — 로그 운영자가 규칙을 지킨다는 것, 그리고 누군가 그 로그를 실제로 읽고 있다는 것. 무엇을 확인할 수 있는가 — 어떤 인증서가 발급됐다는 사실, 그리고 로그가 자기 과거를 고치지 않았다는 사실.
앞의 목록이 뒤의 목록보다 짧아졌다. 그게 CT가 한 일이다. 그리고 앞의 목록이 아직 비지 않았다는 것 — 그게 아직 남은 일이다.
확인 가능성은 장치가 아니다. 누군가 실제로 읽을 때만 성립하는 관행이다.