OCSP Stapling vs CRL: 인증서 폐기의 두 가지 나쁜 선택지

인증서가 침해되면 폐기해야 한다. 폐기 확인 메커니즘 두 가지가 다 근본적으로 고장 나 있다.

인증서 폐기는 화이트보드에서 설명하면 항상 해결된 것 같고, 브라우저에서 실제로 무슨 일이 일어나는지 설명하면 항상 고장 난 것 같은 PKI 파트다.

이론은 단순하다. 인증서가 침해되거나 잘못 발급되면 폐기한다. 세상이 더 이상 신뢰하지 않아야 한다.

실제는 반만 된 조치, 오래된 데이터, 소프트페일 로직, 프라이버시 유출, 백업 계획의 백업 계획의 행렬이다.

CRL: 아무도 안 다운로드하는 큰 목록

Certificate Revocation List가 원래 답이었다. CA가 폐기된 인증서 시리얼 번호 목록을 게시한다. 클라이언트가 목록을 다운로드하고 보고 있는 인증서가 있는지 확인한다.

규모에서의 문제는 뻔하다. CRL이 커진다 — 일부 CA는 수십만 항목이 있다. 인증서 하나 검증하기 전에 메가바이트의 폐기 데이터를 다운로드하면 아무도 참지 못할 지연이 생긴다. 캐싱이 도움 되지만 오래된 데이터를 확인한다는 뜻이다.

브라우저가 수년 전에 CRL을 포기했다. Chrome이 2012년에 CRL 확인을 중단했다.

OCSP: 실시간이 아닌 실시간 확인

Online Certificate Status Protocol이 개선이었다. 전체 목록 대신 CA에게 실시간으로 묻는다: “이 특정 인증서 폐기됐어?”

이론에서는 낫다. 실제에서는 끔찍하다.

지연. 모든 새 TLS 연결이 CA의 OCSP 응답기에 추가 HTTP 요청을 보내야 한다. 50-200ms 추가 지연.

프라이버시. OCSP 요청이 CA에게 정확히 어떤 사이트를 방문하는지, 언제인지 알려준다. CA가 브라우징 습관 로그를 갖게 된다.

가용성. OCSP 응답기가 단일 장애점이 된다. 다운되면? 맞는 답은 “인증서를 거부”다 — 닫힌 상태로 실패. 실제 답은 “어차피 인증서 수락” — 열린 상태로 실패. 닫힌 실패는 응답기가 딸꾹질할 때마다 그 CA 뒤의 모든 사이트가 다운되니까.

이 소프트페일이 전체 목적을 무력화한다. 공격자가 인증서를 침해하고 OCSP 요청도 차단하면(네트워크 수준 공격자에게 사소하다), 브라우저가 어깨를 으쓱하고 침해된 인증서를 수락한다.

OCSP Stapling: 낫지만 선택적

Stapling이 OCSP 문제 두 개를 고친다. 브라우저가 CA에 묻는 대신 서버가 자체 OCSP 응답을 주기적으로 가져와서 TLS 핸드셰이크에 “스테이플”한다. 브라우저가 별도 왕복 없이 신선도 증명을 받고, CA는 클라이언트 요청을 전혀 안 본다.

지연 없음. 프라이버시 유출 없음. 우아하다.

문제: stapling이 선택적이다. 서버가 응답을 스테이플하지 않으면 브라우저가 직접 OCSP(문제 전부 포함)로 폴백하거나 확인을 전혀 안 한다. 많은 서버가 스테이플하지 않는다.

OCSP Must-Staple: 아무도 안 쓴 해결책

Must-Staple(RFC 7633) 인증서 확장이 있다. Must-Staple이 있는 인증서가 브라우저에게 말한다: “스테이플된 OCSP 응답 없이 오면 거부해라.”

폴백 구멍을 닫는다. 스테이플 없으면? 하드 페일.

채택이 미미하다. 스테이플링 실패 — OCSP 응답기가 느리거나, 캐시된 응답이 만료되거나, 갱신 스크립트가 깨지면 — 사이트가 다운된다. 저하가 아니라. 다운. 선택적 확인을 CA 인프라에 대한 하드 의존성으로 바꾼 것이다.

대부분의 운영자가 받아들이기에 실패 모드가 너무 가혹하다.

CRLite: Mozilla의 영리한 접근

Mozilla가 CRLite를 만들었다 — 모든 폐기된 인증서의 압축 표현을 Firefox에 필터로 푸시한다. 블룸 필터 캐스케이드로 전체 폐기 인증서 세트를 수 메가바이트에 표현하고 매일 업데이트한다.

브라우저가 CA에 연락할 필요가 전혀 없다. 폐기 데이터가 이미 로컬에 있다. 지연 없음, 프라이버시 유출 없음, 가용성 의존 없음.

진짜 좋은 아이디어다. Firefox 전용이다.

짧은 수명 인증서: 암묵적 폐기

이게 진짜 답일 수 있다. 인증서가 24-48시간이면 폐기가 거의 무의미해진다. 침해된 인증서가 전통적 폐기 메커니즘이 따라잡기 전에 만료된다.

Let’s Encrypt가 90일 인증서를 개척했다. 업계가 더 짧은 쪽으로 밀고 있다. Let’s Encrypt가 64일, 그다음 45일로 이동 발표. Google은 더 짧은 수명을 제안했다.

24시간 인증서 수명에서 폐기 문제는 사실상 사라진다. 인증서가 자체 폐기 메커니즘이다 — 그냥 유효하지 않게 된다. 트레이드오프는 자동화에 대한 완전한 의존. 갱신 파이프라인이 깨지면 사이트가 몇 시간 안에 다운된다.

해결 안 된 문제

25년 동안 시도했는데 인증서 폐기가 아직 안정적으로 작동하지 않는다. 솔직한 상태: 인증서가 오늘 침해되면 대부분의 브라우저가 만료될 때까지 계속 신뢰한다.

그래서 짧은 인증서 수명을 위한 추진이 어떤 폐기 프로토콜 개선보다 중요하다. 인증서가 나쁘다고 세상에 안정적으로 알릴 수 없으면, 최소한 빨리 유효하지 않게 만들어라.

토론 참여

← 블로그로 돌아가기