TLS 인증서 폐기 확인: OCSP Stapling과 CRLite의 차이
인증서 폐기 확인이 왜 어려운지, 서버가 OCSP 응답을 함께 보내는 방식과 브라우저가 폐기 정보를 압축해 확인하는 CRLite의 설계 차이를 설명합니다. 운영 조건과 근거 범위도 구분합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
폐기 확인은 왜 별도 문제일까?
TLS 인증서는 서버가 공개키와 도메인 이름을 연결한다는 인증기관의 서명된 주장입니다. 인증서가 만료되기 전에도 개인 키가 유출되거나 잘못 발급되면 신뢰를 거둬야 합니다. 만료일만 보는 브라우저는 이런 중간 폐기 상태를 놓칠 수 있어, 인증서 상태 확인 경로가 필요합니다. 다만 모든 연결마다 외부 상태 서버를 동기 조회하면 지연·가용성 문제가 생기고, 사용자가 어느 사이트를 방문하는지 조회자에게 드러날 수 있습니다.
폐기 목록(CRL)은 취소된 인증서들을 담아 클라이언트에 전달하는 전통적인 방법입니다. 목록이 커질수록 전송·저장 비용이 증가하고, 갱신 간격과 배포 지연 사이에서 절충해야 합니다. OCSP는 인증서 하나의 상태를 응답하는 온라인 프로토콜이라 필요한 자료를 작게 만들 수 있지만, 클라이언트가 응답자를 직접 찾아가면 연결 지연이나 응답자 장애가 생깁니다. 따라서 두 방식 모두 최신성, 성능, 개인정보 보호를 함께 고려해야 합니다.
OCSP Stapling은 무엇을 바꾸나?
RFC 6066의 TLS status_request 확장은 클라이언트가 인증서 상태 응답을 요청할 수 있도록 정의합니다. 서버는 OCSP 응답을 인증서와 함께 TLS 핸드셰이크에 실어 보낼 수 있습니다. 브라우저가 매번 OCSP 서버에 직접 접속하지 않아도 되므로 왕복 지연과 방문 기록 노출을 줄일 수 있습니다. 클라이언트는 받은 응답의 유효성을 검사해야 하며 만족스럽지 않으면 핸드셰이크를 중단하도록 RFC가 규정합니다.
스테이플링은 서버가 유효하고 최신인 응답을 준비해 두어야 작동합니다. 응답이 만료되거나 갱신이 실패하거나, 인증서·서버 구성과 응답이 맞지 않으면 클라이언트가 기대한 상태 자료를 받지 못할 수 있습니다. RFC 6066은 TLS 1.2 시대의 확장 문서이며 모든 최신 TLS 인증서 검증 정책을 포괄하는 단일 안내서가 아닙니다. 실제 동작은 브라우저 정책, TLS 버전, 인증서 확장 및 서버 배포 방식에 따라 달라집니다.
전문가 관점: 신뢰성은 서버 운영에 달렸다
Cloudflare 엔지니어링 글은 당시 자사 서비스가 요청 때마다 응답을 가져오는 대신 중앙에서 OCSP 응답을 수집하고, 만료가 가까워지면 갱신해 여러 서버로 배포한 운영 방식을 설명합니다. 이 사례에서 응답의 유효기간 동안 재시도 여유를 두고 장애를 회복할 수 있었습니다. 이는 특정 사업자의 당시 설계 사례이지, 모든 인증서 발급자나 호스팅 사업자가 같은 신뢰도를 제공한다는 보증은 아닙니다.
일반적인 OCSP 직접 조회에서 응답을 가져오지 못했을 때 연결을 허용하는 soft-fail은 가용성을 높일 수 있지만, 공격자가 폐기된 인증서의 상태 응답을 숨기는 경우를 놓칠 위험이 있습니다. 반대로 반드시 스테이플을 요구하는 정책은 응답이 없을 때 연결을 실패시켜 보안 신호를 강하게 만들지만, 정상 서버의 갱신 장애도 사용자에게 접속 실패로 보일 수 있습니다. “항상 스테이플이 있다”는 전제가 운영상 실제로 유지되어야 강한 실패 정책을 안전하게 적용할 수 있습니다.
CRLite는 서버 대신 브라우저에 자료를 둔다
Mozilla 연구의 CRLite/Clubcard 계열 접근은 대량의 폐기 정보를 압축된 멤버십 자료로 만들어 브라우저 쪽에서 인증서를 조회하는 방향을 탐구합니다. 브라우저가 사이트별 OCSP 요청을 매번 보내지 않으므로 조회 지연과 개별 방문 호스트 노출을 줄일 가능성이 있습니다. 연구는 압축 크기와 업데이트 전송량, 필터를 갱신하는 구조, Firefox Nightly 구현을 구체적으로 평가합니다.
논문은 2024년 말 WebPKI 자료에서 전체 스냅샷 6.7MB와 평균 26.8KB의 6시간 증분 업데이트를 보고합니다. 저자들은 Firefox Nightly 134에서 clubcard 기반 CRLite가 기본 폐기 확인 방식이 됐고, 연구 표본 내 확인의 약 93%를 처리했다고 설명합니다. 이 수치는 해당 논문의 데이터·시점·Nightly 환경에 한정되며 현재 모든 Firefox나 브라우저의 기본 설정, 즉시 전 세계 갱신을 뜻하지 않습니다. 압축 자료의 정기 배포와 검증, 오래된 스냅샷이나 누락된 업데이트의 처리는 별도의 운영 과제로 남습니다.
방식을 비교할 때 확인할 질문
OCSP Stapling은 서버가 단기 상태 응답을 전달하는 방식이고 CRLite는 클라이언트가 압축된 폐기 집합을 조회하는 방식입니다. 전자는 서버의 응답 갱신·배포 신뢰성, 후자는 대량 자료의 업데이트 주기·저장·검증이 핵심 운영점입니다. 어느 쪽도 인증서 발급과 키 보호, 신뢰 저장소, 브라우저의 검증 정책을 대신하지 않습니다.
시스템을 설계한다면 먼저 지원 대상 브라우저와 TLS 버전을 정하고, 응답이 없거나 오래된 경우의 실패 정책을 문서화해야 합니다. 그 다음 프라이버시, 지연, 네트워크 단절 시 동작, 업데이트 신선도와 복구 경로를 함께 측정합니다. 현재 제품 상태는 해당 브라우저·서비스의 최신 문서와 실제 구성에서 확인하세요.