162. CRL (Certificate Revocation List)

⚠️ 이 문서는 발급된 디지털 신분증(인증서)이 만료일이 되기 전에 해킹당하거나 분실되었을 때, 전 세계 컴퓨터들에게 "저놈 신분증은 가짜니까 믿지 마라!"라고 알리기 위해 CA(인증기관)가 정기적으로 찍어내어 뿌리는 무식하고 거대한 블랙리스트, CRL을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: CRL(폐지 인증서 목록)은 유효 기간이 남았지만 개인키 유출, 퇴사, 회사 파산 등의 이유로 **신뢰가 파기된 인증서들의 고유 일련번호(Serial Number)들을 모아 CA가 직접 전자 서명하여 배포하는 텍스트 목록(블랙리스트)**이다.
  2. 가치: 아무리 암호를 튼튼하게 만들어도 열쇠(개인키)가 털리는 건 막을 수 없으므로, 암호화 생태계에 **'사후 수습 체계'**를 제공한다. 브라우저는 네이버에 접속할 때 네이버의 인증서 일련번호가 이 CRL 목록에 들어있는지 대조해 보고, 들어있으면 즉각 접속을 차단한다.
  3. 한계/융합: 전 세계 폐기된 인증서가 수백만 개로 팽창하면서 CRL 파일 용량이 수십 메가바이트(MB)로 폭발했고, 모바일 시대에 이 무거운 엑셀 파일을 매번 다운받아 검사하는 것은 미친 짓(대역폭 낭비)이 되었다. 결국 현대 아키텍처는 이를 가벼운 실시간 질문(OCSP) 방식으로 강제 진화시켰다.

Ⅰ. 개요 및 왜 '폐기'가 중요한가? (Context & Necessity)

우리가 신용카드를 발급받아(유효기간 5년) 잘 쓰다가 지갑을 통째로 도둑맞았다고 치자. 유효기간이 5년 남았으니까 5년 동안 도둑이 내 돈을 맘대로 쓰게 놔둘 것인가? 당연히 카드사에 전화해서 **"분실 신고(정지)"**를 해야 한다. 카드사는 모든 가맹점 POS 기계에 "이 카드 번호는 분실된 거니까 결제 막아!"라고 명령을 내린다.

인터넷 세상(PKI)도 똑같다. 네이버가 유효기간 1년짜리 HTTPS 인증서를 발급받았는데, 3달 만에 해커가 서버에 침투해 네이버의 **마스터 개인키(Private Key)**를 훔쳐갔다. 해커는 이 키를 이용해 자기가 가짜 네이버 서버를 만들어서 완벽한 피싱을 할 수 있다.

이 참사를 막기 위해 네이버 사장님은 즉시 CA(인증기관)에 달려가 "내 인증서 무효로 해줘!"라고 외친다. CA는 "네이버의 옛날 인증서 번호 12345번은 해킹당해서 죽었음. 절대 믿지 말 것!" 이라는 방을 써서 벽에 붙인다. 이 방(블랙리스트 파일)의 이름이 바로 **CRL(Certificate Revocation List)**이다.

📢 섹션 요약 비유: 경찰이 발급해 준 운전면허증을 도둑맞았을 때, 도둑이 내 얼굴로 성형수술을 하고 면허증을 내밀면 꼼짝없이 속습니다. 그래서 경찰은 매일 아침 "어제 도난당한 면허증 번호 10,000개"가 적힌 수배 전단지(CRL)를 전국의 편의점에 뿌립니다. 알바생은 민증 검사할 때 얼굴만 보는 게 아니라, 그 수배 전단지에 이 면허증 번호가 있는지 엑셀(Ctrl+F)로 꼭 검색해 봐야만 사기를 면할 수 있습니다.

Ⅱ. CRL의 작동 메커니즘과 포맷 (How it works)

CRL은 대충 메모장으로 써서 뿌리는 게 아니다. 엄격한 X.509 표준 포맷을 따른다.

1. 배포 과정

  • CA는 매일 자정(보통 24시간 또는 7일 주기)에 해킹당하거나 파기된 인증서의 **'일련번호(Serial Number)'**들을 쭉 모아서 리스트를 만든다.
  • "이 리스트는 해커가 가짜로 조작한 게 아니라 우리 CA가 진짜 배포한 블랙리스트가 맞다"는 걸 증명하기 위해, CA 자신의 1급 마스터 개인키로 이 리스트 겉면에 전자 서명 도장을 쾅 찍는다.
  • 그리고 누구나 다운받을 수 있도록 HTTP 서버나 LDAP 디렉터리에 올려둔다 (CRL 배포 포인트, CDP).

2. 브라우저의 검증 과정 (클라이언트의 삽질)

  • 앨리스(크롬 브라우저)가 쇼핑몰 서버에 접속한다.
  • 쇼핑몰이 인증서를 주면, 브라우저는 인증서 안에 적힌 CRL Distribution Points (여기서 블랙리스트 다운받으세요) 주소를 읽는다.
  • 브라우저는 쇼핑몰 접속을 잠시 멈추고(Loading 딜레이), 저 주소로 달려가 수십 MB짜리 CRL 파일을 통째로 다운로드 받는다.
  • 다운로드한 CRL에 쇼핑몰의 일련번호가 없다면? "휴~ 분실된 인증서 아니네!" 하고 그제야 쇼핑몰 창을 띄워준다. 만약 있다면? 즉시 빨간 경고창을 띄우고 접속을 찢어버린다.
┌──────────────────────────────────────────────────────────────────────────┐
│           CRL (폐지 인증서 목록)의 비효율적인 검증 프로세스 시각화       │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│ [ 👨 사용자 브라우저 ]                 [ 🏢 쇼핑몰 서버 ]                │
│   "접속할게!" ───────────────▶                                           │
│                     ◀──────── "내 인증서(신분증) 여깄음!"                │
│                                                                          │
│  (브라우저의 속마음)                                                     │
│   "잠깐! 유효기간은 1년 남았는데 혹시 중간에 도난당한 거 아냐?           │
│    인증서 안에 적힌 '수배 전단지(CRL) 배포처'로 가보자!"                 │
│            │                                                             │
│            ▼                                                             │
│  [ 🏛️ CA의 CRL 서버 ]                                                    │
│   브라우저: "수배 전단지 줘!"                                            │
│   CA: "자, 여기 전 세계에서 도난당한 인증서 번호 100만 개가 적혀있는     │
│        ★50MB짜리 엑셀 파일(CRL)★이다. 다운받아라!"                       │
│                                                                          │
│   (브라우저가 50MB 다운받느라 폰 요금 날아가고 3초 동안 로딩 멈춤 🐢)    │
│            │                                                             │
│            ▼                                                             │
│   브라우저: "다운 다 받았다... Ctrl+F 로 쇼핑몰 번호 검색 중... 헥헥...  │
│            휴, 리스트에 없네! 접속 완료!"                                │
└──────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 무식한 엑셀 다운로드 방식의 치명적인 문제점은 '시간차 공격'에 있다. CA가 CRL 리스트를 업데이트해서 찍어내는 주기가 보통 24시간에 한 번이다. 만약 오늘 낮 12시에 네이버가 털려서 CA에 폐기 신청을 했더라도, CA가 다음 날 자정에 새 CRL 파일을 굽기 전까지(약 12시간 동안) 해커는 가짜 네이버 사이트로 국민들의 아이디를 마음껏 털 수 있다. 이 **Time Window(블랙아웃 시간)**는 실시간 해킹 방어에서 최악의 독이다.

  • 📢 섹션 요약 비유: 수배 전단지(CRL)는 매일 아침 신문에만 인쇄되어 나옵니다. 낮 12시에 살인마가 수배되어도, 내일 아침 신문이 나오기 전까지 알바생은 수배 전단지에서 그 살인마 얼굴을 확인할 수 없어서 그냥 통과시켜 버리는 치명적인 '시간차 오류'가 존재합니다.

Ⅲ. 치명적 단점 3가지와 대안의 등장 (OCSP)

CRL은 너무 무식해서 클라우드/모바일 시대의 짐 덩어리로 전락했다.

  1. 기가 막힌 뚱뚱함 (Bandwidth 낭비)
    • 폐기된 인증서는 계속 쌓인다. 구글 같은 큰 CA의 CRL 파일 크기는 수십 메가바이트(MB)를 거뜬히 넘긴다. 스마트폰으로 쇼핑몰 하나 들어갈 때마다 50MB짜리 파일을 다운받아야 한다면 누가 인터넷을 쓰겠는가?
  2. 느린 업데이트 (Real-time 불가)
    • 위에서 말했듯, 배치(Batch) 작업으로 찍어내는 구조라 털린 즉시 방어할 수 없다.
  3. 다운로드가 실패하면 어쩔 건데? (Soft-Fail)
    • 만약 해커가 CA의 CRL 서버를 디도스(DDoS) 공격으로 눕혀버렸다. 브라우저가 CRL 다운로드를 못 받으면 어떻게 반응해야 할까?
    • "안전을 위해 접속을 아예 막자!(Hard-Fail)" $\rightarrow$ 전 세계 인터넷 접속이 마비된다.
    • "일단 눈 감고 접속시켜 주자!(Soft-Fail)" $\rightarrow$ 해커가 훔친 인증서로 완벽히 사기를 칠 수 있게 된다. (현재 대부분 브라우저의 눈물겨운 선택)

해결책의 등장: "아니, 50MB짜리 명부 전체를 왜 다 다운받아? 그냥 CA한테 전화해서 '야, 쇼핑몰 인증서 1234번 죽었냐 살았냐?' 딱 하나만 물어보면 0.1초 만에 끝나잖아?" 이 당연하고 기발한 1:1 실시간 질문-답변(Query) 시스템이 바로 차세대 표준인 **OCSP(Online Certificate Status Protocol)**다. [163번 문서 참조]

Ⅳ. 결론

"가장 원시적인 블랙리스트, 그러나 모든 신뢰의 최후의 바닥망." 오늘날 Chrome, Safari 등 최신 브라우저들은 뚱뚱한 CRL 파일을 다운로드하는 무식한 짓을 거의 하지 않는다(OCSP나 자체 단축 리스트인 CRLite를 쓴다). 그럼 CRL은 죽은 기술인가? 아니다. 군사망 폐쇄망(Offline) 환경이나, 실시간 인터넷 핑퐁(OCSP)을 하기 힘든 수백만 대의 구형 금융 인프라(B2B) 뒷단에서는, 이 무식하지만 든든한 일괄 명부 파일(CRL)이 매일 밤 FTP를 타고 내려와 조용히 서버의 블랙리스트 장부를 갱신하며 신뢰의 바닥을 지탱하고 있다.

📌 관련 개념 맵

  • 전체 체계: PKI (Public Key Infrastructure) 사후 통제 매커니즘
  • 대체/진화 기술: OCSP (Online Certificate Status Protocol - 실시간 개별 상태 질의)
  • 파일 포맷 규격: X.509 v2 CRL Format
  • 치명적 한계: 대역폭 비만화 (Fat File), 실시간성 부족 (Time Window Gap)

👶 어린이를 위한 3줄 비유 설명

  1. 내가 잃어버린 학생증을 누가 주워서 나인 척 나쁜 짓을 할까 봐, 교장 선생님한테 "내 옛날 학생증은 무효 처리해 주세요!" 하고 신고했어요.
  2. 교장 선생님은 전교생 중에 학생증을 잃어버린 수만 명의 번호를 A4 용지 100장에 빼곡히 적어서(CRL) 학교 정문에 붙여뒀죠.
  3. 수위 아저씨는 학생이 들어올 때마다 그 100장짜리 명단에서 번호를 찾아야 해서 시간도 엄청 오래 걸리고(로딩 지연), 어제 신고한 번호는 내일 아침 명단에나 올라가서 틈(시간차 해킹)이 생기는 불편한 방법이랍니다.