Paperis 아티클

주소창의 자물쇠는 무엇을 보증하나 — '믿을 기관'을 고르는 대신, 모든 발급을 공개 장부에 적기로 한 웹

브라우저가 똑같이 믿는 수백 개 인증기관 가운데 하나만 뚫려도 충분했습니다. 웹은 기관을 고르는 대신 모든 발급을 공개 로그에 적기로 했고, 그 기록을 실제로 확인하는 일은 아직 일부만 일어납니다.

논쟁AI 생성컴퓨터과학·AI · 2026년 10월 9일

내 분야 논문을 오디오로

관심 분야·저널을 고르면 Paperis가 핵심 논문을 요약하고 음성으로 변환해 드려요. 출퇴근길에 들어보세요.

Paperis 무료로 시작하기 →

주소창의 자물쇠는 무엇을 보증하나 — '믿을 기관'을 고르는 대신, 모든 발급을 공개 장부에 적기로 한 웹

중개자 없이 확인한다는 물음, 그리고 이미 돌아가는 장치 하나

이 시리즈는 줄곧 한 가지를 물어 왔습니다. 중개자를 믿지 않고도 무언가를 확인할 수 있는가.

지금까지의 답은 대체로 「가능은 하지만 아직 거기까지는 아니다」였습니다. 「블록체인은 정말 탈중앙인가」에서는 합의의 이론이 단단해도 실제로는 층마다 권력이 다시 모였습니다. 「영지식 증명」에서는 내용을 공개하지 않고 증명하는 도구 가운데 가장 효율이 좋은 계열이 셋업 비밀이라는, 새로 믿어야 할 자리를 남겼고, 그 자리를 없앤 계열은 효율을 내줬습니다. 「블록체인으로 투표하면 조작할 수 없지 않나」에서는 확인할 수 있게 하는 일과 투표의 비밀이 정면으로 부딪혔습니다. 근사한 설계가 실험실을 나오지 못하거나, 나오더라도 작은 규모에 머물렀습니다.

그런데 「믿지 말고 확인한다」를 블록체인 없이 해내고, 이미 웹에 배포된 장치가 하나 있습니다. 여러 주요 브라우저 회사가 채택한 장치입니다 (arXiv:1806.08817, 2018년 기준, 프리프린트). 이름은 인증서 투명성(Certificate Transparency, 줄여서 CT)이고, 웹사이트에 발급되는 증명서를 빠짐없이 누구나 읽을 수 있는 공개 장부에 적게 합니다.

이 글은 그 장치가 무엇을 해냈고 무엇을 해내지 못했는지를 따라갑니다. 결론을 먼저 적습니다. 확인 장치를 놓는 것과 실제로 확인되는 것은 다른 일입니다. CT는 앞의 절반을 널리 해냈고, 뒤의 절반은 아직 논쟁 중입니다.

arXiv·SSRN·TechRxiv에 올라온 글은 프리프린트, 곧 동료심사를 거치기 전에 공개된 논문으로 표기했고, 그 뒤 학술지나 학회에 실렸는지는 확인하지 않았습니다.

자물쇠가 보증한다고 흔히 믿는 것

주소창에 자물쇠가 뜨면 흔히 두 가지를 뜻한다고 배웁니다. 통신이 암호화됐다는 것, 그리고 상대가 진짜 그 사이트라는 것입니다. 앞의 절반은 대체로 맞고, 까다로운 쪽은 뒤의 절반입니다.

뒤의 절반은 인증서에 기댑니다. 「열쇠와 자물쇠 — 공개키는 왜 공개해도 안전한가」의 정의로, 인증서는 이 공개키가 이 사람의 것이라고 제3자가 서명해 준 문서입니다. 인증기관(Certificate Authority, 줄여서 CA)은 인증서에 자기 개인키로 서명해 그 공개키의 주인을 보증해 주는 곳입니다. 웹에서는 이 인증서가 「이 도메인 이름, 곧 이 사이트 주소의 주인이 이 공개키의 주인이 맞다」를 보증합니다. 웹의 무결성과 신뢰가 X.509라는 표준 형식의 이 인증서 위에 서 있습니다 (arXiv:2407.02287, 프리프린트).

뿌리 저장소는 브라우저와 운영체제가 믿기로 정해 두고 들고 다니는 CA들의 목록입니다. 이 목록에 오른 기관을 뿌리 CA라고 부릅니다. 목록 안의 기관이 서명한 인증서면 브라우저는 자물쇠를 띄웁니다.

그러니 흔한 믿음을 정확히 적으면 「믿을 만한 기관을 잘 골라 두면 된다」입니다. 나쁘지 않은 출발점이지만, 이 구조에서 「잘 골라 둔다」가 무슨 뜻인지가 문제입니다.

신뢰는 가장 약한 고리로 정해진다

소프트웨어 제품마다 뿌리 저장소가 다르고, 저장소 하나에는 보통 수백 개의 뿌리가 들어 있습니다. 그 뿌리 하나하나가 어떤 도메인에 대해서든 「신뢰되는」 인증서를 발급할 수 있습니다 (arXiv:2001.04319, 프리프린트). 뿌리 CA는 중간 CA, 곧 그 아래에 둔 다른 기관에 발급 권한을 넘겨줄 수도 있습니다. 그래서 최종 사용자가 어느 기관이 정말 믿을 만한지 가려내기는 어렵습니다 (DOI: 10.1142/s0218126623501037, 공학 일반 학술지 게재).

이 구조를 한 문장으로 적으면 이렇습니다. 웹 PKI, 곧 인증기관과 인증서로 짜인 웹의 신뢰 체계에서는 모든 CA가 똑같이 신뢰되고, 보안은 가장 약한 고리로 정해집니다 (arXiv:2108.08581, 2021년 프리프린트).

내 사이트의 안전은 다른 누군가가 내 도메인 이름으로 인증서를 받아 낼 수 있느냐로 정해집니다. 내가 고른 기관이 아무리 꼼꼼해도, 목록 안의 다른 기관 하나가 내 이름으로 인증서를 내주면 그 인증서도 똑같이 신뢰됩니다.

기관 하나가 뚫렸을 때

한 인증기관에서 최소 531건의 부정 인증서가 발급된 일이 있습니다. 그 기관은 자기 시스템이 뚫린 것을 한 달 넘게 알고 있었고, 잘못 발급한 인증서의 전체 기록조차 갖고 있지 않았습니다. 그래서 최종 집계는 영영 알 수 없습니다 (DOI: 10.1145/2668152.2668154, 학술지가 아닌 실무 매거진 기고).

정책·규제 쪽 분석은 같은 사건에서 구조를 짚습니다. 당시 54개 관할권에 흩어진 650개 인증기관 가운데 단 하나를 뚫는 데 성공하자, 공격자는 어떤 웹사이트나 서비스에 대해서든 거짓 인증서를 만들 수 있었습니다. 그 침해가 알려지지 않은 90일 동안 브라우저들은 그 기관의 인증서를 계속 믿었고, 그 사이 공격자는 약 30만 명의 통신을 가로챌 수 있었습니다. 저자들의 표현으로 각 CA가 생태계 전체 보안의 단일 실패점입니다 (DOI: 10.2139/ssrn.2031409, SSRN 프리프린트).

거짓 인증서가 있으면 「열쇠와 자물쇠」가 설명한 중간자 공격, 곧 가운데 낀 누군가가 양쪽 모두에게 상대방인 척하는 공격이 가능해집니다. 가운데 낀 사람이 진짜 사이트의 인증서처럼 보이는 인증서를 내밀고, 브라우저는 목록 안의 기관이 서명했으니 받아들입니다.

이 글은 그 사건의 배후나 소재지는 다루지 않습니다. 하나가 흔들리면 전부가 흔들리는 구조였다는 것만 봅니다.

「누구를 믿을 것인가」로는 풀리지 않는 이유

이 결함은 기술에만 있지 않습니다. CA 신뢰 모형의 구조적 결함은 법·경제·조직에 걸쳐 있습니다 (DOI: 10.2139/ssrn.2249042, SSRN 프리프린트).

인증기관 생태계를 다시 조사한 연구는 더 아프게 적습니다. 모든 통신을 암호화하는 쪽으로는 큰 걸음을 내디뎠지만, 그 대가로 통신 상대가 진짜인지 확인하는 일의 신뢰를 잃었다는 것입니다. 저자들은 남은 문제의 뿌리를 참여자들 사이의 어긋난 인센티브, 곧 각자 이득을 보는 방향이 서로 엇갈리는 데서 찾습니다. 그리고 그때까지 제안된 보안 확장들이 그 인센티브를 제대로 바로잡지 못한다고 봅니다 (arXiv:1801.00933, 프리프린트).

브라우저가 쥔 선택지도 거칩니다. 클라이언트는 사용자 쪽에서 돌아가며 사이트에 접속하는 브라우저 같은 프로그램입니다. 웹 PKI에서 클라이언트가 의심스러운 CA를 만났을 때 할 수 있는 일은 그 기관을 완전히 불신하는 것뿐입니다. 그러면 그 기관이 발급한 멀쩡한 인증서까지 한꺼번에 거부되는 부수 피해가 납니다 (arXiv:2108.08581). 신뢰가 켜고 끄는 두 값뿐이니, 대응도 두 값뿐입니다.

기관을 고르는 대신 발급을 적는다

여기서 방향이 꺾이고, 이 꺾임이 이 시리즈가 계속 찾던 것입니다.

CT의 목표는 발급된 모든 인증서를 공개 로그에 저장해, 잘못 발급됐을지 모르는 인증서가 있는지를 누구나 확인할 수 있게 하는 것입니다 (DOI: 10.56553/popets-2022-0075). 여기서 로그는 「블록체인이란 무엇인가 — 아무도 관리하지 않는 장부가 성립하는 이유」가 말한 장부, 곧 누가 무엇을 언제 했는지를 일어난 순서대로 적어 둔 기록입니다. CT 로그는 인증서를 공개적이고, 감사할 수 있고, 추가전용인 방식으로 보관합니다 (arXiv:2001.04319, 프리프린트). 추가전용(append-only)은 뒤에 붙이는 것만 되고, 이미 적힌 것을 고치거나 지우는 것은 안 되는 성질입니다.

이 전환의 성격은 한 프라이버시 학회 논문의 문장에 정확히 담겨 있습니다. 주요 브라우저들이 CA 생태계의 가장 약한 고리 보안을 넘어서려고, 인증기관의 서명에 더해 CT 로그 기록까지 의무로 요구하기 시작했다는 것입니다 (DOI: 10.2478/popets-2021-0024).

그래서 나온 답은 이렇습니다. 누가 무엇을 발급했는지 전부 적어 놓고, 아무나 읽게 합니다. 기관의 자격을 심사하는 대신, 기관의 행동을 기록으로 남긴 것입니다.

이 설계가 약속하는 것을 부풀리지 않는 문장도 있습니다. 공개적으로 검증할 수 있는 CT 로그에 대한 신뢰는 암호와 gossip, 감사, 모니터링을 통해 줄어듭니다 (arXiv:1711.03952, 프리프린트). gossip은 뒤에서 다룰, 각자 본 로그를 서로 대조하는 절차입니다. 이 문장이 고른 동사는 「줄어든다」입니다. 이 글의 나머지는 줄어들고 남은 신뢰가 어디에 있는지를 따라갑니다.

머클 트리 — 고치면 티가 나는 로그를 짧게 확인하는 법

로그에 인증서가 여덟 장 적혀 있다고 해 보겠습니다. 인증서마다 「블록체인이란 무엇인가」가 설명한 해시를 하나씩 찍습니다. 해시는 아무리 긴 글이든 정해진 길이의 짧은 값 하나로 줄여 놓은 것이고, 같은 글은 늘 같은 값이 되며 글자 하나만 바뀌어도 값이 달라집니다.

이웃한 두 해시를 붙여 다시 해시를 찍으면 값이 넷이 되고, 같은 일을 되풀이하면 둘, 다시 하나가 됩니다. 꼭대기에 남은 값 하나를 루트라고 부릅니다. 머클 트리는 이렇게 데이터를 해시로 두 개씩 묶어 올라가며 꼭대기에 값 하나를 만드는 자료구조입니다. 맨 아래 인증서 한 장의 글자 하나만 바뀌어도 위로 올라가는 값이 차례로 바뀌어 루트가 달라집니다. 로그는 이 루트에 서명해 공개합니다.

CT 프로토콜을 머클 트리까지 정밀하게 모형으로 옮겨, 지켜야 할 성질이 지켜지는지를 처음으로 수학적 증명으로 따진 연구가 있습니다. 이 연구는 머클 트리가 주는 것을 둘로 꼽습니다. 데이터가 거기 있다는 간결한 증명과, 트리가 확장됐다는 간결한 증명입니다 (arXiv:2303.04500, 프리프린트).

포함 증명(inclusion proof)은 어떤 인증서가 이 로그 안에 있다는 것을, 로그 전체를 내려받지 않고 해시 몇 개만으로 보이는 증명입니다. 여덟 장 가운데 셋째 장이 들어 있는지 확인하려면, 셋째 장에서 루트까지 올라가는 길 옆에 붙는 해시 세 개만 받으면 됩니다. 셋째 장의 해시와 그 세 개로 루트를 다시 계산해서 공개된 루트와 같으면, 셋째 장은 로그 안에 있습니다.

인증서 여덟 장 위로 해시가 두 개씩 묶여 넷, 둘, 하나로 올라가는 머클 트리. 셋째 장에서 루트까지 올라가는 길이 파랑으로 칠해져 있고, 그 길 옆에 붙는 해시 세 개(넷째 장의 해시, 첫째·둘째 장을 묶은 해시, 다섯째~여덟째 장을 묶은 해시)가 금색 ①②③이다. 나머지 값은 흐린 회색으로 받지 않아도 되는 값이다. 꼭대기는 로그가 서명해 공개한 루트이고, 오른쪽 상자에 '다시 계산한 루트 = 공개된 루트 → 셋째 장은 로그 안에 있음'이라고 적혀 있다. 아래 메모: 로그 전체를 내려받지 않고 해시 몇 개만으로, 인증서 수가 두 배가 될 때마다 받는 해시가 하나씩 늘어난다.

일관성 증명(consistency proof)은 지금의 로그가 예전의 로그 뒤에 덧붙이기만 한 것임을 보이는 증명입니다. 어제 인증서가 네 장일 때의 루트를 기억해 둔 사람이 있다고 해 보겠습니다. 로그는 오늘 여덟 장짜리 트리에서 해시 몇 개를 내밀어, 어제의 네 장이 그대로 앞부분에 있음을 보일 수 있습니다. 어제의 네 장 가운데 하나라도 고치거나 지웠다면 어제의 루트가 다시 나오지 않으므로 이 증명이 성립하지 않습니다.

왼쪽은 어제의 네 장짜리 트리로, 꼭대기가 기억해 둔 어제의 루트다. 오른쪽은 오늘의 여덟 장짜리 트리다. 앞의 네 장은 어제와 그대로이고 그 위 꼭짓점이 어제의 루트와 같은 값이라 점선으로 이어져 있다. 뒤의 네 장은 새로 덧붙인 것이고, 그 위 꼭짓점이 로그가 내미는 해시(금색)다. 맨 위는 로그가 서명해 공개한 오늘의 루트다. 아래 확인 줄: 기억해 둔 어제의 루트와 로그가 내민 해시로 다시 계산한 값이 오늘 공개된 루트와 같은가. 빨강 줄: 어제의 네 장 가운데 하나라도 고치거나 지웠다면 어제의 루트가 다시 나오지 않아 증명이 성립하지 않는다. 회색 메모: 이 증명은 내가 본 로그와 남이 본 로그가 같은지는 말하지 않는다.

증명은 인증서가 늘어도 아주 천천히 커집니다. 인증서 수가 두 배가 될 때마다 해시가 하나씩 느는 정도이고, 이런 증가를 로그 비례라고 부릅니다(이때의 로그는 장부가 아니라 수학 함수의 이름입니다). 2017년 당시 알려진 CT 구성은 모두 머클 트리를 써서 증명 크기가 인증서 수에 로그 비례했고, 이 크기를 인증서 수와 상관없는 상수 크기로 줄이려는 암호학적 시도도 있습니다 (arXiv:1704.04937, 프리프린트).

모두가 같은 로그를 보고 그 증명을 실제로 확인한다면, 로그 운영자를 정직하다고 믿을 필요 없이 「거짓말하면 들킨다」만으로 충분합니다. 그 조건이 실제로 채워지는지는 아래 「남은 문제」에서 다시 봅니다. 「블록체인이란 무엇인가」가 변조 탐지라 부른 성질, 곧 고치는 것을 막지는 못하지만 고친 사실이 드러나게 하는 성질이 바로 이것입니다. 「신뢰를 줄인다」는 말이 정확히 뜻하는 것도 이것입니다. 바뀐 것은 믿음의 종류입니다. 「이 운영자는 나쁜 짓을 안 할 것이다」에서 「이 운영자가 나쁜 짓을 하면 흔적이 남는다」로 바뀌었습니다.

이 성질은 CT만의 것이 아닙니다. 어떤 기록이 다른 기록보다 먼저 있었음을 보증하는 상대 타임스탬프와 추가전용 로그는 거의 따로 연구돼 온 두 갈래인데, 한 체계화 논문은 둘이 같은 동전의 양면, 곧 접두 관계의 인증이라고 정리합니다. 접두 관계는 예전 기록이 지금 기록의 앞부분에 그대로 들어 있는 관계입니다. 이 논문이 정의한 그래프 종류는 저자들이 아는 모든 해시 기반 타임스탬프·로그 설계를 담습니다 (arXiv:2308.13836, 프리프린트). 「과거는 현재의 앞부분이어야 한다」가 이 계열 전체의 공통 뼈대입니다.

해시로 이어 붙여 과거를 고치면 티가 나게 하는 데까지는 「블록체인이란 무엇인가」의 공책과 같습니다. 다만 지금 배포된 CT 로그에는 무엇이 진짜 기록인지 여럿이 정하는 증인들의 합의가 없습니다. 로그 하나는 그 운영자가 쓰고, 다른 사람들은 그 로그를 읽고 따집니다. 그래서 모두가 같은 판본을 보고 있는지는 따로 맞춰 봐야 하고, 이 문제는 「남은 문제 ②」에서 다시 나옵니다.

SCT — 로그가 써 주는 약속표

인증서를 로그에 제출하면 로그는 SCT(Signed Certificate Timestamp, 서명된 인증서 타임스탬프)를 돌려줍니다. SCT는 「이 인증서를 정해진 시간 안에 로그에 넣겠다」고 로그가 서명해 준 약속표입니다.

이 표가 CT를 강제하는 손잡이가 됐습니다. 브라우저는 SCT가 붙지 않은 인증서를 거부하기만 하면 되고, 그러면 CA들은 인증서를 로그에 넣을 수밖에 없습니다. 앞에서 본, 브라우저들이 CA의 서명에 더해 CT 로그 기록을 의무로 요구하기 시작한 것이 이 방식입니다 (DOI: 10.2478/popets-2021-0024).

여기에 이 글의 핵심 균열이 있습니다. SCT는 약속이고, 로그에 들어갔다는 증거는 아닙니다. 인증서가 실제로 로그에 들어갔는지는 나중에 포함 증명을 받아 확인해야 합니다. SCT 감사는 이렇게 약속표를 받은 인증서가 실제로 로그에 들어갔는지 확인하는 일입니다. 이 감사가 실제로 얼마나 일어나는지는 아래에서 다시 봅니다.

모니터와 감사자 — 로그를 읽는 두 역할

CT는 로그를 지켜보는 일을 둘로 나눕니다.

모니터는 로그의 항목을 하나도 빠짐없이 지켜보면서, 자기가 관심 있는 수상한 인증서를 찾는 쪽입니다. 도메인 소유자라면 「내 도메인 이름이 붙은 인증서가 나왔는데 내가 신청한 것이 아니다」를 찾는 일입니다. 모니터는 누구나 돌릴 수 있지만, 쉬지 않고 돌려야 하고 로그 사본도 들고 있어야 합니다 (arXiv:1711.03952, 프리프린트).

부담이 크니 대행업이 생겼습니다. 서비스형 모니터링은 신뢰받는 제3자가 모니터를 대신 돌리고, 등록한 사람에게 「foo.com 인증서가 나오면 알려 줘」 같은 골라 받는 알림을 보내 주는 서비스입니다. 신뢰를 줄이려고 만든 체계 안에 신뢰받는 제3자가 다시 들어선 것입니다. 그래서 그 알림이 빠뜨린 것 없이 정확한지 받는 사람이 검증할 수 있게 하는 확장이 제안됐습니다. 대행자에게 두는 신뢰를 다시 줄이려는 시도입니다 (arXiv:1711.03952).

감사자는 로그가 일관되고 정직하게 행동하는지 확인하는 쪽입니다. 2015년 기준으로 로그 기반 방식에 아직 없던 것이 바로 이것, 곧 클라이언트가 로그의 일관성과 정직성을 검증할 방법이었습니다 (arXiv:1511.01514, 프리프린트).

막는 장치와 드러내는 장치

CT는 잘못된 발급을 막지 않고, 드러냅니다. CT 같은 로그 기반 방식이 하는 일은 부정한 인증서가 누구에게나 보이게 만드는 것입니다 (arXiv:1511.01514).

막는 쪽 장치는 따로 있습니다. DNS는 도메인 이름을 실제 서버 주소로 바꿔 주는 인터넷의 주소록입니다. CAA는 도메인 소유자가 DNS에 「내 도메인의 인증서는 이 CA만 발급할 수 있다」고 적어 두는 안전장치입니다. 그런데 CAA의 개념과 운영에 있는 결함이 잘못된 발급을 막는 효과를 깎아 먹습니다 (arXiv:2411.07702, 프리프린트).

인기 도메인 400만 개를 잰 측정은 더 구체적입니다 (arXiv:2407.02287, 프리프린트). CAA는 형식으로는 대체로 올바르게 배포됐지만, 적힌 문자열이 CA들을 골라서 가르지 못하는 경향을 보였습니다. 그리고 수많은 도메인이 자기 CAA가 허용한 범위를 벗어난 인증서를 갖고 있었습니다.

DNS를 지키는 다른 장치와도 어긋났습니다. DNSSEC은 DNS 기록에 서명을 붙여 위조를 막는 장치입니다. CAA는 거의 전적으로 DNSSEC이 없는 곳에 배포됐고, 반대로 DNSSEC으로 보호되는 이름들은 인증서를 지키는 데 DNS를 쓰지 않는 경향을 보였습니다. 인증서 정보를 DNS에 직접 적어 두는 DANE의 TLSA 기록은 관리가 되풀이해 부실했고, 때로 DNSSEC 없이 있었습니다 (arXiv:2407.02287).

장치를 놓는 것과 그 장치가 실제로 일하는 것은 다릅니다. 이 문장은 이제 CT 자신에게 돌아옵니다.

남은 문제 ① — 클라이언트는 확인하지 않는다

CT의 핵심 요구는 주어진 인증서가 실제로 하나 이상의 로그 안에 있다는 것입니다. 그런데 이 문제를 체계화한 2022년의 프라이버시 학회 논문은 그때의 배포 상태를 이렇게 적습니다. 대부분의 개별 클라이언트는 자기가 본 인증서가 로그에 있는지 확인하지 않습니다 (DOI: 10.56553/popets-2022-0075).

걸림돌은 프라이버시입니다. 클라이언트가 로그에 포함 증명을 직접 요청하면 어떤 인증서를 묻는지가 그대로 드러나고, 그것은 그 사용자가 어느 사이트를 방문했는지를 드러내는 것과 같습니다. 확인하려면 프라이버시를 내주어야 하는 구조입니다.

그래서 프라이버시를 지키면서 감사하는 기법들이 여러 갈래로 제안됐습니다. 브라우저가 사용자 프라이버시를 침해하지 않고 CT 로그를 감사하게 하는 방식이 있습니다 (DOI: 10.1515/popets-2017-0052). 강한 익명성을 갖춘 오블리비어스 파일 공유 시스템, 곧 누가 무엇을 가져가는지 서버도 알 수 없게 하는 파일 공유 방식으로 질의를 감추는 시도도 있습니다 (arXiv:1905.09478, 프리프린트).

같은 체계화 논문은 제안들을 훑은 뒤 또 하나의 한계를 짚습니다. 많은 제안이 클라이언트와 로그 사이의 주고받기에만 집중하고, 클라이언트가 「로그에 없는 인증서를 봤다」는 사실을 어떻게 비공개로 신고할지는 열어 둡니다 (DOI: 10.56553/popets-2022-0075).

확인해서 이상을 찾아도 말할 길이 없으면, 확인은 절반만 끝난 것입니다.

남은 문제 ② — 모두가 같은 로그를 보고 있는가

일관성 증명은 내가 어제 본 로그와 오늘 본 로그를 이어 줍니다. 내가 본 로그와 남이 본 로그가 같은지는 말해 주지 않습니다.

CT 로그는 이론상 믿을 필요가 없습니다. 다만 그 전제는 조건 하나에 기댑니다. 모든 클라이언트가 같은 로그를 보고, 그것을 암호로 검증한다는 것입니다. 그래서 실무에서는 어떤 형태로든 gossip이 필요합니다. gossip은 클라이언트들이 각자 본 로그를 서로 대조해 보는 절차입니다. 그리고 이것은 CT에서 오래 풀리지 않은 문제입니다. 2018년 기준으로 여러 주요 브라우저 회사가 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을 서비스로 제공하는 방식입니다.

2018년에 공개된 이 설계의 평가에는 20일치 측정이 쓰였습니다. 그 측정은 3,500개 자율 시스템과 IPv4 주소 공간의 40%에 걸친 클라이언트를 대표합니다. 자율 시스템은 통신사나 대학처럼 한 운영 주체가 관리하는 인터넷의 독립된 망 단위입니다. 저자들은 이 측정을 근거로, 이 방식을 조금씩 배포해 나가기만 해도 현실적인 위협 모형에서 split-view 로그에 맞서는 유의미한 방어를 얻을 수 있다고 보고합니다. 라우터·스위치급 장비에서 10 Gbps 회선 속도로 돌릴 수 있다는 구현도 보였습니다 (arXiv:1806.08817, 프리프린트). 제안은 나와 있지만, 이 글이 인용한 연구들이 나온 2018~2020년 기준으로 널리 배포된 gossip은 없었습니다.

더 근본적인 지적도 있습니다. 대부분의 제안은 전역 감사자 집합, 곧 모든 로그를 대신 살펴 줄 감사자 무리가 있다고 가정합니다. 그리고 목표한 투명성을 이루려면 그들이 제 역할을 하리라고 맹목적으로 믿어야 합니다. 그래서 사용자가 스스로 감사할 수 있게 하는 gossip 프로토콜과 검증 가능한 레지스트리가 제안됐습니다 (arXiv:2011.04551, 프리프린트).

신뢰를 덜어 낸 자리에 신뢰가 다시 들어섭니다. 이 시리즈에서 여러 번 본 모양입니다.

남은 문제 ③ — 로그 운영자에게 남는 신뢰

2021년의 한 프라이버시 학회 논문에 따르면, CT는 여러 로그가 나눠 맡는 분산 체계 위에 서는데 그 로그들의 정확성은 충분히 보호되지 않고 있었습니다. CA와 그에 대응하는 로그를 함께 장악한 은밀한 공격자는 여전히 들키지 않고 부정 인증서를 발급할 수 있습니다 (DOI: 10.2478/popets-2021-0066).

그 대응으로 로그들이 협업하는 설계가 제안됐습니다. 여러 로그를 한 무리로 묶고, 그 가운데 무작위로 뽑힌 하나가 인증서를 넣으면 나머지가 그 발급 과정을 지켜보고 증언하게 합니다. 그러면 신뢰받는 제3자 없이도 로그가 로그를 감사할 수 있고, 공격자는 참여하는 증인을 하나하나 전부 장악해야 합니다 (DOI: 10.2478/popets-2021-0066).

잘 알려지지 않은 사실도 하나 있습니다. CT 로그도 자기 뿌리 목록을 갖고 있습니다. CT가 도입되면서 신뢰 지형이 바뀌었고, 로그들은 각자 믿는 뿌리 목록을 두고 그 뿌리로 이어지는 인증서만 기록하게 됐습니다. 이 새 지형을 처음으로 그려 낸 연구는 로그들의 뿌리 목록을 서로, 그리고 주요 소프트웨어 회사들의 뿌리 저장소와 견주었습니다. 그리고 뿌리 목록 관리 부실이 로그의 부정행위와 이어질 수 있음을 보였습니다 (arXiv:2001.04319, 프리프린트).

한 익명 브라우징 네트워크에 CT를 얹는 설계를 제안한 2021년 논문은 문제를 한 문장으로 적습니다. 당시의 CT 배포에는 로그 운영자가 규칙대로 행동하는지 검증할 강한 장치가 없습니다 (DOI: 10.2478/popets-2021-0024). 같은 논문은 당시 배포된 CT 강제가 맹목적 신뢰(blind trust)에 기대고 있다고 보고, CA와 로그의 부정 증거를 확률적으로 잡아내 공개하는 설계를 내놓습니다.

대안 설계는 많습니다. 블록체인 위에 CT를 올려 split-view를 없애자는 제안이 있습니다 (arXiv:1806.03914, 프리프린트). 검증 가능한 신뢰 당사자를 둔 대체 PKI도 있고 (DOI: 10.1155/2018/8527010), 클라이언트 쪽에서 돌아가는 탈중앙 감사도 있습니다 (DOI: 10.3390/cryptography5020014). 서버가 인증서 바꿔치기 공격을 스스로 알아채고 그 발원지를 짐작하는 방식도 있습니다 (DOI: 10.1049/iet-ifs.2016.0611). 도메인 소유자와 클라이언트가 각자 발급 정책과 검증 정책을 정해, 서로 다른 당사자가 서로 다른 신뢰 기준을 쓰는 「신뢰 이질성」을 들이자는 제안도 있습니다 (arXiv:2108.08581).

이 목록의 한 논문이 2018년에 적어 둔 문장이 이 계열 전체의 사정을 설명합니다. 이 문제를 풀겠다는 해법이 여럿 제안됐지만, 복잡성과 배포 가능성 문제로 어느 것도 아직 널리 채택되지 않았습니다 (DOI: 10.1049/iet-ifs.2016.0611).

CT가 자리 잡은 까닭을 여기서 거꾸로 짐작할 수 있습니다. 대안들이 복잡성과 배포 가능성에 걸린 자리에서, CT는 브라우저 정책만으로 강제할 수 있었습니다.

남은 문제 ④ — 공개의 대가

CT 로그에 쌓인 인증서 수는 지수적으로 늘었고, 사이트의 CT 지원도 꾸준히 늘었습니다. 2018년 시점 측정에서는 맺어진 연결의 33%가 CT를 지원했습니다 (arXiv:1809.08325, 프리프린트). 그 성공이 새 문제를 낳습니다. 로그에 적히는 인증서에는 도메인 이름이 들어 있고, 모든 인증서가 CT 로그에 보인다는 사실 자체가 정보가 새는 통로가 됩니다.

같은 연구가 이것을 실험으로 확인했습니다. 저자들은 CT 허니팟을 만들었습니다. 허니팟은 일부러 놓아둔 미끼로, 여기서는 인증서를 발급받되 그 이름을 아무 데도 알리지 않고 누가 찾아오는지 지켜보는 장치입니다. 결과는 이렇습니다. 인증서를 발급받은 지 불과 몇 분 만에, CT 로그 데이터가 스캐닝 캠페인의 표적을 고르는 데 쓰이고 있었습니다 (arXiv:1809.08325, 프리프린트). 스캐닝 캠페인은 인터넷의 기계들을 차례로 훑어 공격할 곳을 찾는 활동입니다.

조직 안에서만 쓰려던 이름도 인증서를 받는 순간 공개 장부에 올라갑니다. vpn-test.내회사.com에서 vpn-test처럼 도메인 앞에 붙는 하위 이름을 서브도메인이라고 부르는데, 이런 이름은 그 조직이 무엇을 운영하고 시험하는지를 흘립니다. 저자들은 나아가 CT에 기록된 방대한 도메인에서 새 서브도메인을 학습하고 검증하는 방법도 내놓았습니다 (arXiv:1809.08325).

그래서 비공개 서브도메인을 지원하도록 CT를 넓히자는 제안이 나왔습니다 (DOI: 10.1515/popets-2017-0052). 이 대가는 ①과 뿌리가 같습니다. 확인은 공개를 요구하고, 공개는 대가를 요구합니다. 확인하는 쪽인 클라이언트의 프라이버시와, 확인당하는 쪽인 도메인 소유자의 프라이버시가 함께 값을 치릅니다.

남은 문제 ⑤ — 폐기, CT가 덮지 않는 영역

CT는 발급을 막지 않고, CT가 아예 덮지 않는 영역도 하나 크게 남아 있습니다. 폐기입니다. 「열쇠와 자물쇠」의 정의로 폐기는 발급된 인증서를 만료 전에 무효로 돌리는 일입니다. 잘못된 발급을 CT가 드러내 줘도, 그 인증서를 무효로 만들고 그 사실을 전 세계 브라우저에 전하는 일은 별개입니다.

그 자리가 비어 있습니다. 2021년 기준으로, 인증서 발급에 대한 CT에 해당하는 절차, 곧 모든 폐기의 투명하고 바뀌지 않는 이력을 남기는 절차는 채택된 적이 없습니다 (arXiv:2102.04288, 프리프린트). 같은 연구는 폐기된 인증서 100만 건 이상을 놓고, 인증서가 만료된 때부터 폐기 상태 정보가 사라질 때까지의 이력을 처음으로 오래 따라갔습니다. 그중 77만 3천 건은 한 인증기관이 한꺼번에 폐기한 것입니다. 연구는 폐기 상태가 얼마나 짧게 남는지, 기관마다 폐기 관행이 얼마나 다른지를 수치로 보였습니다.

폐기가 어렵다는 것은 오래된 이야기입니다. 폐기 방식들의 득실을 분류하고 분석한 작업이 20년도 더 전에 나왔고 (DOI: 10.1145/956981.956991), 2026년의 종합 조사도 주요 폐기 방식들이 프라이버시와 확장성 같은 여러 면에서 한계를 보여 왔다고 정리합니다 (DOI: 10.1145/3785653).

사정이 하나 더 겹칩니다. TLS는 「열쇠와 자물쇠」가 소개한, 브라우저와 사이트 사이의 연결을 맺고 지키는 규약입니다. 전통적인 폐기 방식들은 대부분 지연·가용성·프라이버시 문제를 안고 있는데, TLS에 위임 장치가 기본으로 들어 있지 않아 문제가 커집니다. 위임은 도메인 소유자가 자기 개인키를 넘기지 않고도 남에게 그 사이트를 대신 서비스할 권한을 주는 일입니다. 이 장치가 없으니 도메인 소유자들은 점점 제3자에게 자기 개인키를 나눠 주는 위험한 관행으로 내몰립니다 (arXiv:1906.10775, 프리프린트).

같은 연구는 폐기·위임 방식들을 평가한 뒤, 수명이 짧은 위임 자격증명이나 프록시 인증서를 알맞은 폐기 체계와 묶으면 시급한 문제 여럿이 풀린다고 결론짓습니다. 답이 없다기보다, 2019년의 이 연구가 보기에 답의 조각들은 나와 있었고 남은 일은 그것들을 맞춰 배포하는 것이었습니다. 확인 장치를 아무리 잘 설계해도, 개인키가 몇 군데에 복제돼 있는지 아무도 모르면 그 쓸모가 줄어듭니다.

폐기에도 투명성을 붙이려는 제안은 있습니다. 포스트인증서는 인증서 소유자가 발급 CA를 거치지 않고 기존 CT 로그에 직접 제출해, 스스로 폐기 절차를 시작하게 하는 인증서입니다. CA는 CT 로그를 지켜보다가 포스트인증서를 발견하면 폐기를 진행해야 합니다. 기존 CT 로그를 그대로 다시 쓰므로 배포 비용이 낮다는 것이 저자들의 주장입니다 (arXiv:2203.02280, 프리프린트).

남은 문제 ⑥ — 사람

결함 있는 TLS 인증서는 인터넷에서 드물지 않은데, 대부분은 설정 실수나 의도적인 배포처럼 해가 없는 원인에서 나옵니다. 그래서 연결을 믿을지 말지의 판단이 흐려집니다 (arXiv:2207.11610, 프리프린트). 마지막 고리는 사람이고, 이 고리가 가장 다루기 까다롭습니다.

산업 IT 콘퍼런스 참가자 75명이 여러 인증서 검증 오류를 조사하는 과정을 지켜본 연구는 세 가지를 보고합니다. 첫째, IT 종사자들의 견해는 매우 섬세했고 신뢰 판단은 이분법과 거리가 멀었습니다. 둘째, 자기 자신이 서명한 자체 서명 인증서와, 쓸 수 있는 이름의 범위를 미리 제한해 둔 이름 제약 인증서는 실제보다 더 믿기는 경향을 보였고, 이름 제약 인증서는 잘 이해되지도 않았습니다. 셋째, 기존 오류 메시지를 아주 조금만 바꿔도 자료 활용과 이해, 신뢰 판단이 좋은 쪽으로 움직였습니다 (arXiv:2207.11610, 프리프린트).

셋째 항목이 중요합니다. 「사람들이 확인하지 않는다」는 하늘에서 떨어진 상수가 아니고, 설계로 움직일 수 있는 변수입니다.

인증서를 발급하는 쪽 소프트웨어도 검사 대상입니다. ACME는 도메인 확인과 인증서 발급을 자동으로 처리하는 표준 규약입니다. ACME를 따르는 오픈소스 CA 구현 네 종의 개발자 작성 테스트를 분석한 프리프린트는, 테스트가 프로토콜을 덮는 범위가 좁다고 보고합니다(프로토콜 연산 39.5%, 오류 처리 25.6%). 프로토콜 버그를 고칠 때 그 버그가 되돌아오지 않는지 보는 회귀 테스트도 거의 추가되지 않았습니다. 저자들은 명세에서 행동 모형을 끌어내 상태를 따라가며 테스트를 만드는 생성기로 두 범위를 각각 100%까지 끌어올렸고, 보고된 적 없는 버그 3건을 찾았습니다 (DOI: 10.36227/techrxiv.176972158.85579194/v1, TechRxiv 프리프린트). 인증서를 검증하는 쪽 구현들에도, 표준 문서에서 규칙을 뽑아 여러 구현을 맞대 시험해야 드러나는 잠재 결함이 있습니다 (DOI: 10.1145/3355048).

그럼에도 실제로 해낸 것

비판으로만 끝나면 이 글은 반쪽입니다. CT는 조용히 아주 큰 일을 하나 해냈습니다. 공개 기록이 생기자, 발급 감시 말고도 다른 쓰임을 찾는 감시자들이 나타났습니다.

CT 로그를 실시간으로 읽어, 준비 중인 피싱 사이트를 인증서 발급 단계에서 잡아내려는 분류 파이프라인이 나왔습니다. 이미 드러난 사이트를 차단 목록에 올리는 기존 방식은 공격자에게 「기회의 창」을 남기는데, 사이트가 만들어지는 순간을 로그로 포착해 그 창을 줄이자는 발상입니다. 저자들이 여러 분류기를 시험해 확인한 것은 앞으로 분류기를 개선할 여지까지입니다 (arXiv:2106.12343, 프리프린트).

표준 준수 검사로는 걸러지지 않는 이상한 인증서를 찾는 탐지 기법이 CT 로그 표본으로 검증됐습니다 (arXiv:2405.05206, 프리프린트). CT 스트림을 브라우저 렌더링과 의미 분석에 엮어 새 사이트를 실시간으로 분류하는 시스템은, 23.83시간 동안 X.509 기록 851만 건을 처리했다고 보고합니다 (DOI: 10.47813/2782-5280-2026-5-3-1001-1014, 소규모 지역 학술지 게재).

이 셋은 모두 로그가 공개돼 있어서 가능했습니다. 특히 피싱 탐지와 새 사이트 분류는 잘못된 발급을 찾는다는 CT의 목표 바깥으로 쓰임새가 넓어진 사례입니다.

인증서 생태계 자체도 감시의 재료가 됐습니다. DNS 조작은 검열자 같은 쪽이 주소록의 응답을 바꿔 사용자의 접속을 막거나 가로채는 일입니다. TLS 인증서를 검증할 수 있는 신호로 삼아 DNS 조작을 잡아낸 연구는, 26개국 55개 자율 시스템이 통신사 수준에서 DNS를 조작하고 있음을 찾아냈습니다. 52개국에서 쓰이는 상용 DNS 필터링 제품 17종과, 선행 연구가 다루지 못한 새 차단 페이지 묶음 226개도 식별했습니다. 선행 연구가 쓰던 일관성 기반 어림법은 DNS 조작으로 탐지한 사례 가운데 72.45%가 오탐이었습니다 (arXiv:2305.08189, 프리프린트).

로그 기반 투명성 기술 전반을 체계화한 논문은 투명성의 목적과 쓸모, 함정을 정리합니다. 그러면서 투명성이 외부 장치, 곧 시스템에 이의를 제기하고 운영자에게 책임을 묻게 해 주는 장치와 어떻게 이어지는지를 함께 다룹니다 (arXiv:2305.01378, 프리프린트). 로그는 그 외부 장치의 입력일 뿐이고, 로그 자체는 아무에게도 책임을 묻지 않습니다.

제도 쪽 성취도 있습니다. 인증서를 만드는 CA들과 브라우저 회사들이 함께 발급 기본 요건을, 그리고 CT 자체를 만들고 집행하는 비정부 포럼이 있습니다. 이 포럼의 2013~2022년 회의록 369건을 모으고, 123개 조직에서 온 553명의 참석 기록과 192건의 투표를 분석한 거버넌스 연구가 있습니다. 이 연구는 이 협력이 왜 안정적으로 유지되는지를 참여자들의 인센티브 구조로 설명합니다 (DOI: 10.2139/ssrn.4528663, SSRN 프리프린트). 확인 가능성이 관행이 되려면, 그 관행을 지탱하는 제도가 있어야 합니다.

남는 걱정도 있습니다. 브릭스(BRICS) 국가들과 유럽연합(EU)의 도메인 인증서를 조사한 2025년 프리프린트는, 양쪽 모두 75% 이상이 두 권역 바깥인 미국에 기반을 둔 CA에서 발급된다고 보고합니다. 저자들은 이 높은 외부 의존이 디지털 주권에 위험이 될 수 있다고 봅니다 (arXiv:2504.16897, 프리프린트). 신뢰를 기록으로 바꿨어도, 발급 자체는 여전히 좁은 곳에 모여 있습니다.

확인 가능성은 장치보다 관행

세 문장으로 정리합니다.

첫째, 이 문제는 「누구를 믿을 것인가」로 풀리지 않습니다. 모든 CA가 똑같이 신뢰되는 구조에서 보안은 가장 약한 고리로 정해집니다. 뿌리 목록 안 수백 개 가운데 어느 하나만 흔들려도 아무 도메인의 인증서가 만들어지고, 실제로 하나가 흔들렸을 때 그 하나로 충분했습니다.

둘째, 그래서 해법이 기관을 고르는 일에서 기록을 공개하는 일로 옮겨 갔습니다. 모든 발급을 추가전용 로그에 적고, 포함 증명과 일관성 증명으로 「거짓말하면 들킨다」를 만들고, SCT라는 약속표로 브라우저가 그것을 강제하게 하고, 모니터와 감사자에게 읽게 합니다. 블록체인 같은 원장도, 증인들의 합의 규칙도 없이 해낸 일이고, 이미 웹에 배포돼 있습니다.

셋째, 그런데 적히는 것만으로는 아무 일도 일어나지 않습니다. 2022년 기준 배포에서 대부분의 클라이언트는 자기가 본 인증서가 로그에 있는지 확인하지 않았습니다. 모두가 같은 로그를 보고 있는지 맞춰 보는 gossip은 널리 배포되지 않았습니다. 로그 운영자가 규칙대로 행동하는지 검증할 강한 장치도 없었습니다. 확인 장치는 놓였고, 확인은 아직 부분적으로만 일어납니다.

남는 것도 있습니다. CT는 발급을 막지 않고 드러낼 뿐입니다. 폐기에는 아직 CT에 해당하는 투명성이 없습니다. 공개 로그는 지키는 사람에게도, 표적을 찾는 사람에게도 똑같이 열려 있고, 허니팟 실험에서 그 시차는 몇 분이었습니다. 그리고 이 글의 모든 수치는 각 연구가 각자의 시점에 각자의 방법으로 관측한 값입니다. 이 분야에서 엇갈리는 측정 결과들은 실제 배포의 차이보다 측정 설정의 차이에 뿌리를 둔다는 지적이 이미 나와 있습니다 (arXiv:2401.18053, 프리프린트). 배포 상태는 이 글이 쓰인 뒤에도 계속 움직입니다.

그러니 이 시리즈의 질문에 CT가 주는 답은 이렇습니다.

무엇을 믿어야 하는가 — 로그 운영자가 규칙을 지킨다는 것, 그리고 누군가 그 로그를 실제로 읽고 있다는 것. 무엇을 확인할 수 있는가 — 어떤 인증서가 발급됐다는 사실, 그리고 로그가 자기 과거를 고치지 않았다는 사실.

앞의 목록이 뒤의 목록보다 짧아졌습니다. 그것이 CT가 한 일입니다. 그리고 앞의 목록이 아직 비지 않았다는 것, 그것이 아직 남은 일입니다.

확인 가능성은 누군가 실제로 읽을 때만 성립하는 관행입니다.

근거 논문

"Certificate Transparency" (2014) — DOI: 10.1145/2668152.2668154 (실무 매거진 기고) — 한 인증기관에서 최소 531건의 부정 인증서가 발급됐고, 그 기관은 침해를 한 달 넘게 알고 있었으며 오발급 인증서 전체 기록조차 없었다.
"Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain" (2012) — DOI: 10.2139/ssrn.2031409 (프리프린트) — 54개 관할권 650개 CA 중 하나만 뚫려도 임의 사이트의 거짓 인증서 생성 가능. 90일 침묵, 약 30만 명 통신 가로채기. 각 CA가 단일 실패점.
"F-PKI: Enabling Innovation and Trust Flexibility in the HTTPS Public-Key Infrastructure" (2021) — arXiv:2108.08581 (프리프린트) — 모든 CA가 동등하게 신뢰되고 보안은 가장 약한 고리로 정의됨. 클라이언트의 선택지는 '완전 불신'뿐이라 부수 피해 발생.
"Characterizing the Root Landscape of Certificate Transparency Logs" (2020) — arXiv:2001.04319 (프리프린트) — 뿌리 저장소마다 수백 개의 뿌리, 각각이 어떤 도메인에 대해서든 발급 가능. CT 로그도 자기 뿌리 목록을 유지하며, 그 관리 부실이 로그 부정행위와 연결될 수 있음.
"Trust Darknet: Control and Compromise in the Internet's Certificate Authority Model" (2013) — DOI: 10.2139/ssrn.2249042 (프리프린트) — CA 신뢰 모형의 결함이 기술만이 아니라 법·경제·조직에 걸쳐 있음.
"New Directions for Trust in the Certificate Authority Ecosystem" (2018) — arXiv:1801.00933 (프리프린트) — 보편적 암호화의 진전이 통신 상대 인증의 신뢰를 대가로 왔고, 어긋난 인센티브가 구조적 문제의 뿌리이며 제안된 확장들이 그것을 재정렬하지 못함.
"A Secure Two-Tier Domain Verification and Certificate Validation…" (2022) — DOI: 10.1142/s0218126623501037 (공학 일반 학술지) — 어떤 CA든 인터넷상의 어떤 개체에 대해서도 인증서를 발급할 수 있어 최종 사용자가 신뢰 여부를 가리기 어려움.
"SoK: SCT Auditing in Certificate Transparency" (2022) — DOI: 10.56553/popets-2022-0075 — CT의 목표와 SCT 감사의 현실. 대부분의 개별 클라이언트는 인증서의 로그 존재를 확인하지 않으며, 이는 포함 증명 요청이 곧 프라이버시 침해이기 때문. 제안들이 '없는 인증서를 어떻게 비공개로 신고할 것인가'를 열어 둠.
"Privacy-Preserving & Incrementally-Deployable Support for Certificate Transparency in Tor" (2021) — DOI: 10.2478/popets-2021-0024 — 브라우저들이 CA 생태계의 가장 약한 고리 보안을 극복하려 CT 로깅을 의무화. 현재 CT 배포에는 로그 운영자가 규칙대로 행동하는지 검증할 강한 메커니즘이 없음.
"Verifiable Light-Weight Monitoring for Certificate Transparency Logs" (2017) — arXiv:1711.03952 (프리프린트) — CT 로그에 대한 신뢰는 암호·gossip·감사·모니터링으로 '줄어든다'. 모니터의 역할과 서비스형 모니터링의 신뢰 문제, 그 알림을 검증 가능하게 하는 확장.
"Automatic verification of transparency protocols (extended version)" (2023) — arXiv:2303.04500 (프리프린트) — 머클 트리가 주는 것은 '데이터 존재의 간결한 증명'과 '트리 확장의 간결한 증명'. 머클 트리를 정밀 모형화한 CT의 최초 형식 검증.
"SoK: Authenticated Prefix Relations — A Unified Perspective On Relative Time-Stamping and Append-Only Logs" (2023) — arXiv:2308.13836 (프리프린트) — 상대 타임스탬프와 추가전용 로그는 같은 동전의 양면, 곧 접두 관계의 인증.
"Certificate Transparency with Enhancements and Short Proofs" (2017) — arXiv:1704.04937 (프리프린트) — 기존 구성의 증명 크기는 인증서 수에 로그 비례. 상수 크기 증명을 겨냥한 대안.
"A Call to Reconsider Certification Authority Authorization (CAA)" (2024) — arXiv:2411.07702 (프리프린트) — CAA의 개념·운영상 결함이 오발급 방지 효과를 훼손.
"Do CAA, CT, and DANE Interlink in Certificate Deployments? A Web PKI Measurement Study" (2024) — arXiv:2407.02287 (프리프린트) — 400만 인기 도메인 실측. CAA는 거의 DNSSEC 부재 환경에만 배포되고, 수많은 도메인이 자기 CAA 범위를 벗어난 인증서를 보유. TLSA는 관리 부실.
"Efficient Gossip Protocols for Verifying the Consistency of Certificate Logs" (2015) — arXiv:1511.01514 (프리프린트) — 로그가 일관되고 정직하게 행동하는지 클라이언트가 검증할 방법의 부재. 최초의 gossip 프로토콜 제안과 프라이버시·효율·배포가능성의 난점.
"Aggregation-Based Certificate Transparency Gossip" (2018) — arXiv:1806.08817 (프리프린트) — 주요 브라우저의 CT 채택에도 널리 배포된 gossip 메커니즘은 없음. 네트워크 장비가 gossip을 서비스로 제공하는 설계, 3,500 AS·IPv4 40% 대표 20일 측정.
"Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures" (2020) — arXiv:2011.04551 (프리프린트) — 기존 gossip 제안들은 전역 감사자 집합을 가정하고 그들을 맹목적으로 믿어야 함. 사용자가 스스로 감사하는 프로토콜과 검증 가능 레지스트리.
"CertLedger: A New PKI Model with Certificate Transparency Based on Blockchain" (2018) — arXiv:1806.03914 (프리프린트) — 로그 기반 PKI 개선안들이 split-world 공격에 여전히 취약함.
"SCM: Secure and accountable TLS certificate management" (2020) — DOI: 10.1002/dac.4503 — 로그 기반 PKI는 공격자가 표적에게 서로 다른 서명된 로그 버전을 제시할 수 있으면 여전히 취약.
"LogPicker: Strengthening Certificate Transparency Against Covert Adversaries" (2021) — DOI: 10.2478/popets-2021-0066 — CA와 대응 로그를 함께 장악한 은밀한 공격자는 여전히 부정 인증서를 발급 가능. 로그 풀이 서로 증인이 되는 설계.
"Server notaries: a complementary approach to the web PKI trust model" (2018) — DOI: 10.1049/iet-ifs.2016.0611 — 여러 해법이 제안됐으나 복잡성·배포가능성 문제로 어느 것도 널리 채택되지 않음. 서버 측 인증서 치환 공격 탐지.
"Accountable and Transparent TLS Certificate Management…" (2018) — DOI: 10.1155/2018/8527010 — 검증 가능한 신뢰 당사자를 둔 대체 PKI 제안.
"Associative Blockchain for Decentralized PKI Transparency" (2021) — DOI: 10.3390/cryptography5020014 — 기존 투명성 접근이 여전히 다소 중앙집중적이라는 지적과 클라이언트 측 탈중앙 감사.
"The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem" (2018) — arXiv:1809.08325 (프리프린트) — CT 로그 인증서의 지수적 증가와 사이트 지원 확대. CT 허니팟 실험 — 발급 후 불과 몇 분 만에 로그 데이터가 스캐닝 표적 선정에 사용됨.
"Certificate Transparency with Privacy" (2017) — DOI: 10.1515/popets-2017-0052 — 사용자 프라이버시를 침해하지 않는 브라우저의 로그 감사, 비공개 서브도메인 지원 확장.
"Private Queries on Public Certificate Transparency Data" (2019) — arXiv:1905.09478 (프리프린트) — 클라이언트의 CT 질의가 브라우징 습관을 호스팅 서버에 노출하는 문제와 익명 질의 시도.
"Revocation Statuses on the Internet" (2021) — arXiv:2102.04288 (프리프린트) — 인증서 발급에 대한 CT에 상응하는 폐기 투명성 절차는 채택된 바 없음. 100만 건 이상 폐기 인증서의 상태 이력 종단 분석(그중 77만 3천 건은 한 기관의 대량 폐기).
"SoK: Delegation and Revocation, the Missing Links in the Web's Chain of Trust" (2019) — arXiv:1906.10775 (프리프린트) — 폐기 스킴의 지연·가용성·프라이버시 문제, 그리고 TLS의 네이티브 위임 부재가 도메인 소유자를 개인키 공유라는 위험한 관행으로 내몲.
"Postcertificates for Revocation Transparency" (2022) — arXiv:2203.02280 (프리프린트) — 인증서 소유자가 CA를 우회해 기존 CT 로그에 제출함으로써 스스로 폐기를 개시하는 설계.
"Tradeoffs in certificate revocation schemes" (2003) — DOI: 10.1145/956981.956991 — 폐기 스킴들의 분류와 트레이드오프 분석.
"Certificate Revocation in the TLS Ecosystem: A Survey" (2026) — DOI: 10.1145/3785653 — 주요 폐기 스킴들이 프라이버시·확장성 등에서 보여 온 한계와 최신 기법들의 실배포 함의.
"Will You Trust This TLS Certificate? Perceptions of People Working in IT (Extended Version)" (2022) — arXiv:2207.11610 (프리프린트) — IT 종사자 75명 관찰. 신뢰 판단은 이분법과 거리가 멀고, 자체 서명·이름 제약 인증서는 과신되는 경향. 오류 메시지의 작은 변경만으로도 이해와 판단이 개선.
"Testing Certificate Authorities: An Empirical Study and Stateful Fuzzing Approach" (2026) — DOI: 10.36227/techrxiv.176972158.85579194/v1 (프리프린트 서버 판본·게재 여부 미확인) — 오픈소스 CA 구현 4종의 개발자 테스트 프로토콜 커버리지 39.5%/25.6%, 명세 기반 생성기로 100%까지, 미보고 버그 3건.
"Differential Testing of Certificate Validation in SSL/TLS Implementations" (2019) — DOI: 10.1145/3355048 — 표준 문서에서 인증서 규칙을 뽑아 구현들을 차등 테스트해 잠재 결함을 드러냄.
"Finding Phish in a Haystack: A Pipeline for Phishing Classification on Certificate Transparency Logs" (2021) — arXiv:2106.12343 (프리프린트) — 차단 목록의 '기회의 창'을 줄이기 위해 CT 로그로 준비 단계의 피싱을 포착하는 파이프라인.
"Anomaly Detection in Certificate Transparency Logs" (2024) — arXiv:2405.05206 (프리프린트) — 표준 준수 검사로는 잡히지 않는 이상 인증서 탐지, CT 로그 표본으로 검증.
"Certificate Transparency-driven real-time website categorization…" (2026) — DOI: 10.47813/2782-5280-2026-5-3-1001-1014 (소규모 지역 학술지) — 23.83시간 동안 851만 건의 X.509 기록 처리, 36개 범주 분류.
"CERTainty: Detecting DNS Manipulation at Scale using TLS Certificates" (2023) — arXiv:2305.08189 (프리프린트) — TLS 인증서를 검증 가능한 신호로 삼은 DNS 조작 탐지. 기존 일관성 기반 휴리스틱의 오탐 72.45%.
"SoK: Log Based Transparency Enhancing Technologies" (2023) — arXiv:2305.01378 (프리프린트) — 로그 기반 투명성 기술의 목적·유용성·함정, 그리고 투명성이 시스템에 이의를 제기하고 운영자에게 책임을 묻는 외부 메커니즘과 맺는 관계.
"Non-governmental Governance of Trust on the Internet: The CA/Browser Forum" (2023) — DOI: 10.2139/ssrn.4528663 (프리프린트) — 인증서 생산자와 브라우저 벤더가 발급 기준선과 CT를 함께 개발·집행하는 포럼. 회의록 369건·123개 조직 553명·192건 투표 분석.
"Assessing SSL/TLS Certificate Centralization: Implications for Digital Sovereignty" (2025) — arXiv:2504.16897 (프리프린트) — 두 정치·경제권 도메인 인증서의 75% 이상이 단일 국가 기반 CA에서 발급.
"How to Measure TLS, X.509 Certificates, and Web PKI: A Tutorial and Brief Survey" (2024) — arXiv:2401.18053 (프리프린트) — 선행 TLS 측정 연구들의 엇갈린 결과는 실제 배포 차이가 아니라 측정 설정의 차이에 뿌리를 둠.

이 글은 AI가 연구 논문을 바탕으로 작성한 교육·정보 제공용 콘텐츠이며, 전문가의 조언을 대체하지 않습니다. 오류를 발견하셨나요? 알려주세요

Paperis 아티클

주소창의 자물쇠는 무엇을 보증하나 — '믿을 기관'을 고르는 대신, 모든 발급을 공개 장부에 적기로 한 웹

논쟁AI 생성컴퓨터과학·AI · 2026년 10월 9일

내 분야 논문을 오디오로

관심 분야·저널을 고르면 Paperis가 핵심 논문을 요약하고 음성으로 변환해 드려요. 출퇴근길에 들어보세요.

Paperis 무료로 시작하기 →

주소창의 자물쇠는 무엇을 보증하나 — '믿을 기관'을 고르는 대신, 모든 발급을 공개 장부에 적기로 한 웹

중개자 없이 확인한다는 물음, 그리고 이미 돌아가는 장치 하나

이 시리즈는 줄곧 한 가지를 물어 왔습니다. 중개자를 믿지 않고도 무언가를 확인할 수 있는가.

자물쇠가 보증한다고 흔히 믿는 것

신뢰는 가장 약한 고리로 정해진다

기관 하나가 뚫렸을 때

이 글은 그 사건의 배후나 소재지는 다루지 않습니다. 하나가 흔들리면 전부가 흔들리는 구조였다는 것만 봅니다.

「누구를 믿을 것인가」로는 풀리지 않는 이유

이 결함은 기술에만 있지 않습니다. CA 신뢰 모형의 구조적 결함은 법·경제·조직에 걸쳐 있습니다 (DOI: 10.2139/ssrn.2249042, SSRN 프리프린트).

기관을 고르는 대신 발급을 적는다

여기서 방향이 꺾이고, 이 꺾임이 이 시리즈가 계속 찾던 것입니다.

머클 트리 — 고치면 티가 나는 로그를 짧게 확인하는 법

SCT — 로그가 써 주는 약속표

모니터와 감사자 — 로그를 읽는 두 역할

CT는 로그를 지켜보는 일을 둘로 나눕니다.

막는 장치와 드러내는 장치

CT는 잘못된 발급을 막지 않고, 드러냅니다. CT 같은 로그 기반 방식이 하는 일은 부정한 인증서가 누구에게나 보이게 만드는 것입니다 (arXiv:1511.01514).

장치를 놓는 것과 그 장치가 실제로 일하는 것은 다릅니다. 이 문장은 이제 CT 자신에게 돌아옵니다.

남은 문제 ① — 클라이언트는 확인하지 않는다

확인해서 이상을 찾아도 말할 길이 없으면, 확인은 절반만 끝난 것입니다.

남은 문제 ② — 모두가 같은 로그를 보고 있는가

일관성 증명은 내가 어제 본 로그와 오늘 본 로그를 이어 줍니다. 내가 본 로그와 남이 본 로그가 같은지는 말해 주지 않습니다.

신뢰를 덜어 낸 자리에 신뢰가 다시 들어섭니다. 이 시리즈에서 여러 번 본 모양입니다.

남은 문제 ③ — 로그 운영자에게 남는 신뢰

남은 문제 ④ — 공개의 대가

남은 문제 ⑤ — 폐기, CT가 덮지 않는 영역

남은 문제 ⑥ — 사람

셋째 항목이 중요합니다. 「사람들이 확인하지 않는다」는 하늘에서 떨어진 상수가 아니고, 설계로 움직일 수 있는 변수입니다.

그럼에도 실제로 해낸 것

확인 가능성은 장치보다 관행

세 문장으로 정리합니다.

그러니 이 시리즈의 질문에 CT가 주는 답은 이렇습니다.

앞의 목록이 뒤의 목록보다 짧아졌습니다. 그것이 CT가 한 일입니다. 그리고 앞의 목록이 아직 비지 않았다는 것, 그것이 아직 남은 일입니다.

확인 가능성은 누군가 실제로 읽을 때만 성립하는 관행입니다.

근거 논문

"Certificate Transparency" (2014) — DOI: 10.1145/2668152.2668154 (실무 매거진 기고) — 한 인증기관에서 최소 531건의 부정 인증서가 발급됐고, 그 기관은 침해를 한 달 넘게 알고 있었으며 오발급 인증서 전체 기록조차 없었다.
"Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain" (2012) — DOI: 10.2139/ssrn.2031409 (프리프린트) — 54개 관할권 650개 CA 중 하나만 뚫려도 임의 사이트의 거짓 인증서 생성 가능. 90일 침묵, 약 30만 명 통신 가로채기. 각 CA가 단일 실패점.
"F-PKI: Enabling Innovation and Trust Flexibility in the HTTPS Public-Key Infrastructure" (2021) — arXiv:2108.08581 (프리프린트) — 모든 CA가 동등하게 신뢰되고 보안은 가장 약한 고리로 정의됨. 클라이언트의 선택지는 '완전 불신'뿐이라 부수 피해 발생.
"Characterizing the Root Landscape of Certificate Transparency Logs" (2020) — arXiv:2001.04319 (프리프린트) — 뿌리 저장소마다 수백 개의 뿌리, 각각이 어떤 도메인에 대해서든 발급 가능. CT 로그도 자기 뿌리 목록을 유지하며, 그 관리 부실이 로그 부정행위와 연결될 수 있음.
"Trust Darknet: Control and Compromise in the Internet's Certificate Authority Model" (2013) — DOI: 10.2139/ssrn.2249042 (프리프린트) — CA 신뢰 모형의 결함이 기술만이 아니라 법·경제·조직에 걸쳐 있음.
"New Directions for Trust in the Certificate Authority Ecosystem" (2018) — arXiv:1801.00933 (프리프린트) — 보편적 암호화의 진전이 통신 상대 인증의 신뢰를 대가로 왔고, 어긋난 인센티브가 구조적 문제의 뿌리이며 제안된 확장들이 그것을 재정렬하지 못함.
"A Secure Two-Tier Domain Verification and Certificate Validation…" (2022) — DOI: 10.1142/s0218126623501037 (공학 일반 학술지) — 어떤 CA든 인터넷상의 어떤 개체에 대해서도 인증서를 발급할 수 있어 최종 사용자가 신뢰 여부를 가리기 어려움.
"SoK: SCT Auditing in Certificate Transparency" (2022) — DOI: 10.56553/popets-2022-0075 — CT의 목표와 SCT 감사의 현실. 대부분의 개별 클라이언트는 인증서의 로그 존재를 확인하지 않으며, 이는 포함 증명 요청이 곧 프라이버시 침해이기 때문. 제안들이 '없는 인증서를 어떻게 비공개로 신고할 것인가'를 열어 둠.
"Privacy-Preserving & Incrementally-Deployable Support for Certificate Transparency in Tor" (2021) — DOI: 10.2478/popets-2021-0024 — 브라우저들이 CA 생태계의 가장 약한 고리 보안을 극복하려 CT 로깅을 의무화. 현재 CT 배포에는 로그 운영자가 규칙대로 행동하는지 검증할 강한 메커니즘이 없음.
"Verifiable Light-Weight Monitoring for Certificate Transparency Logs" (2017) — arXiv:1711.03952 (프리프린트) — CT 로그에 대한 신뢰는 암호·gossip·감사·모니터링으로 '줄어든다'. 모니터의 역할과 서비스형 모니터링의 신뢰 문제, 그 알림을 검증 가능하게 하는 확장.
"Automatic verification of transparency protocols (extended version)" (2023) — arXiv:2303.04500 (프리프린트) — 머클 트리가 주는 것은 '데이터 존재의 간결한 증명'과 '트리 확장의 간결한 증명'. 머클 트리를 정밀 모형화한 CT의 최초 형식 검증.
"SoK: Authenticated Prefix Relations — A Unified Perspective On Relative Time-Stamping and Append-Only Logs" (2023) — arXiv:2308.13836 (프리프린트) — 상대 타임스탬프와 추가전용 로그는 같은 동전의 양면, 곧 접두 관계의 인증.
"Certificate Transparency with Enhancements and Short Proofs" (2017) — arXiv:1704.04937 (프리프린트) — 기존 구성의 증명 크기는 인증서 수에 로그 비례. 상수 크기 증명을 겨냥한 대안.
"A Call to Reconsider Certification Authority Authorization (CAA)" (2024) — arXiv:2411.07702 (프리프린트) — CAA의 개념·운영상 결함이 오발급 방지 효과를 훼손.
"Do CAA, CT, and DANE Interlink in Certificate Deployments? A Web PKI Measurement Study" (2024) — arXiv:2407.02287 (프리프린트) — 400만 인기 도메인 실측. CAA는 거의 DNSSEC 부재 환경에만 배포되고, 수많은 도메인이 자기 CAA 범위를 벗어난 인증서를 보유. TLSA는 관리 부실.
"Efficient Gossip Protocols for Verifying the Consistency of Certificate Logs" (2015) — arXiv:1511.01514 (프리프린트) — 로그가 일관되고 정직하게 행동하는지 클라이언트가 검증할 방법의 부재. 최초의 gossip 프로토콜 제안과 프라이버시·효율·배포가능성의 난점.
"Aggregation-Based Certificate Transparency Gossip" (2018) — arXiv:1806.08817 (프리프린트) — 주요 브라우저의 CT 채택에도 널리 배포된 gossip 메커니즘은 없음. 네트워크 장비가 gossip을 서비스로 제공하는 설계, 3,500 AS·IPv4 40% 대표 20일 측정.
"Think Global, Act Local: Gossip and Client Audits in Verifiable Data Structures" (2020) — arXiv:2011.04551 (프리프린트) — 기존 gossip 제안들은 전역 감사자 집합을 가정하고 그들을 맹목적으로 믿어야 함. 사용자가 스스로 감사하는 프로토콜과 검증 가능 레지스트리.
"CertLedger: A New PKI Model with Certificate Transparency Based on Blockchain" (2018) — arXiv:1806.03914 (프리프린트) — 로그 기반 PKI 개선안들이 split-world 공격에 여전히 취약함.
"SCM: Secure and accountable TLS certificate management" (2020) — DOI: 10.1002/dac.4503 — 로그 기반 PKI는 공격자가 표적에게 서로 다른 서명된 로그 버전을 제시할 수 있으면 여전히 취약.
"LogPicker: Strengthening Certificate Transparency Against Covert Adversaries" (2021) — DOI: 10.2478/popets-2021-0066 — CA와 대응 로그를 함께 장악한 은밀한 공격자는 여전히 부정 인증서를 발급 가능. 로그 풀이 서로 증인이 되는 설계.
"Server notaries: a complementary approach to the web PKI trust model" (2018) — DOI: 10.1049/iet-ifs.2016.0611 — 여러 해법이 제안됐으나 복잡성·배포가능성 문제로 어느 것도 널리 채택되지 않음. 서버 측 인증서 치환 공격 탐지.
"Accountable and Transparent TLS Certificate Management…" (2018) — DOI: 10.1155/2018/8527010 — 검증 가능한 신뢰 당사자를 둔 대체 PKI 제안.
"Associative Blockchain for Decentralized PKI Transparency" (2021) — DOI: 10.3390/cryptography5020014 — 기존 투명성 접근이 여전히 다소 중앙집중적이라는 지적과 클라이언트 측 탈중앙 감사.
"The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem" (2018) — arXiv:1809.08325 (프리프린트) — CT 로그 인증서의 지수적 증가와 사이트 지원 확대. CT 허니팟 실험 — 발급 후 불과 몇 분 만에 로그 데이터가 스캐닝 표적 선정에 사용됨.
"Certificate Transparency with Privacy" (2017) — DOI: 10.1515/popets-2017-0052 — 사용자 프라이버시를 침해하지 않는 브라우저의 로그 감사, 비공개 서브도메인 지원 확장.
"Private Queries on Public Certificate Transparency Data" (2019) — arXiv:1905.09478 (프리프린트) — 클라이언트의 CT 질의가 브라우징 습관을 호스팅 서버에 노출하는 문제와 익명 질의 시도.
"Revocation Statuses on the Internet" (2021) — arXiv:2102.04288 (프리프린트) — 인증서 발급에 대한 CT에 상응하는 폐기 투명성 절차는 채택된 바 없음. 100만 건 이상 폐기 인증서의 상태 이력 종단 분석(그중 77만 3천 건은 한 기관의 대량 폐기).
"SoK: Delegation and Revocation, the Missing Links in the Web's Chain of Trust" (2019) — arXiv:1906.10775 (프리프린트) — 폐기 스킴의 지연·가용성·프라이버시 문제, 그리고 TLS의 네이티브 위임 부재가 도메인 소유자를 개인키 공유라는 위험한 관행으로 내몲.
"Postcertificates for Revocation Transparency" (2022) — arXiv:2203.02280 (프리프린트) — 인증서 소유자가 CA를 우회해 기존 CT 로그에 제출함으로써 스스로 폐기를 개시하는 설계.
"Tradeoffs in certificate revocation schemes" (2003) — DOI: 10.1145/956981.956991 — 폐기 스킴들의 분류와 트레이드오프 분석.
"Certificate Revocation in the TLS Ecosystem: A Survey" (2026) — DOI: 10.1145/3785653 — 주요 폐기 스킴들이 프라이버시·확장성 등에서 보여 온 한계와 최신 기법들의 실배포 함의.
"Will You Trust This TLS Certificate? Perceptions of People Working in IT (Extended Version)" (2022) — arXiv:2207.11610 (프리프린트) — IT 종사자 75명 관찰. 신뢰 판단은 이분법과 거리가 멀고, 자체 서명·이름 제약 인증서는 과신되는 경향. 오류 메시지의 작은 변경만으로도 이해와 판단이 개선.
"Testing Certificate Authorities: An Empirical Study and Stateful Fuzzing Approach" (2026) — DOI: 10.36227/techrxiv.176972158.85579194/v1 (프리프린트 서버 판본·게재 여부 미확인) — 오픈소스 CA 구현 4종의 개발자 테스트 프로토콜 커버리지 39.5%/25.6%, 명세 기반 생성기로 100%까지, 미보고 버그 3건.
"Differential Testing of Certificate Validation in SSL/TLS Implementations" (2019) — DOI: 10.1145/3355048 — 표준 문서에서 인증서 규칙을 뽑아 구현들을 차등 테스트해 잠재 결함을 드러냄.
"Finding Phish in a Haystack: A Pipeline for Phishing Classification on Certificate Transparency Logs" (2021) — arXiv:2106.12343 (프리프린트) — 차단 목록의 '기회의 창'을 줄이기 위해 CT 로그로 준비 단계의 피싱을 포착하는 파이프라인.
"Anomaly Detection in Certificate Transparency Logs" (2024) — arXiv:2405.05206 (프리프린트) — 표준 준수 검사로는 잡히지 않는 이상 인증서 탐지, CT 로그 표본으로 검증.
"Certificate Transparency-driven real-time website categorization…" (2026) — DOI: 10.47813/2782-5280-2026-5-3-1001-1014 (소규모 지역 학술지) — 23.83시간 동안 851만 건의 X.509 기록 처리, 36개 범주 분류.
"CERTainty: Detecting DNS Manipulation at Scale using TLS Certificates" (2023) — arXiv:2305.08189 (프리프린트) — TLS 인증서를 검증 가능한 신호로 삼은 DNS 조작 탐지. 기존 일관성 기반 휴리스틱의 오탐 72.45%.
"SoK: Log Based Transparency Enhancing Technologies" (2023) — arXiv:2305.01378 (프리프린트) — 로그 기반 투명성 기술의 목적·유용성·함정, 그리고 투명성이 시스템에 이의를 제기하고 운영자에게 책임을 묻는 외부 메커니즘과 맺는 관계.
"Non-governmental Governance of Trust on the Internet: The CA/Browser Forum" (2023) — DOI: 10.2139/ssrn.4528663 (프리프린트) — 인증서 생산자와 브라우저 벤더가 발급 기준선과 CT를 함께 개발·집행하는 포럼. 회의록 369건·123개 조직 553명·192건 투표 분석.
"Assessing SSL/TLS Certificate Centralization: Implications for Digital Sovereignty" (2025) — arXiv:2504.16897 (프리프린트) — 두 정치·경제권 도메인 인증서의 75% 이상이 단일 국가 기반 CA에서 발급.
"How to Measure TLS, X.509 Certificates, and Web PKI: A Tutorial and Brief Survey" (2024) — arXiv:2401.18053 (프리프린트) — 선행 TLS 측정 연구들의 엇갈린 결과는 실제 배포 차이가 아니라 측정 설정의 차이에 뿌리를 둠.