163. OCSP (Online Certificate Status Protocol)

⚠️ 이 문서는 무겁고 뚱뚱한 '전체 폐기 명단(CRL)'을 다운로드해야 했던 과거의 지옥을 끝내고, "방금 받은 이 인증서 번호 하나만 죽었는지 살았는지 즉시 대답해 다오!"라며 브라우저와 CA 서버가 1:1로 가볍고 민첩하게 묻고 답하는 현대 PKI의 실시간 신분증 검사기, OCSP를 다룹니다.

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

본질: OCSP(온라인 인증서 상태 프로토콜)는 클라이언트(브라우저)가 서버에 접속할 때 받은 특정 인증서의 일련번호(Serial Number) 딱 1개만 들고 CA(인증기관)의 OCSP 서버에 실시간으로 접속해 "이거 분실/폐기(Revoked)된 거 맞음?"이라고 묻고 답을 받아내는 초경량 HTTP 기반 질의응답 프로토콜이다.

가치: 수십 메가바이트(MB)에 달하던 블랙리스트(CRL) 전체를 다운받는 무식한 네트워크 낭비를 고작 수백 바이트 수준의 패킷 1번 왕복으로 박살 냈으며, CA가 데이터베이스를 업데이트하자마자 그 즉시 브라우저가 폐기 사실을 알 수 있는 완벽한 실시간성(Real-time)을 확보했다.

한계/융합: 엄청난 발전이지만, 해커가 이 OCSP 서버를 디도스(DDoS) 쳐서 죽여버리면 브라우저가 접속을 못 해 버벅대고(가용성 병목), 브라우저가 CA에게 "나 방금 네이버 들어갔다?"라고 내 서핑 기록을 고스란히 고자질하는 심각한 프라이버시 침해가 발생하여 결국 **OCSP Stapling(스테이플링)**이라는 기막힌 우회 아키텍처로 융합 발전하게 된다.

Ⅰ. 개요 및 CRL이라는 짐 덩어리의 몰락 (Context & Necessity)

당신이 카페에서 스마트폰으로 쇼핑몰에 들어갔다. 쇼핑몰이 '인증서'를 줬다. 과거(CRL 시절) 당신의 폰은 쇼핑몰 접속을 멈추고 50MB짜리 거대한 '전 세계 분실 인증서 엑셀 파일'을 다운로드하느라 데이터 요금을 날리고 로딩창을 5초간 멍하니 쳐다봐야 했다. 심지어 그 엑셀 파일은 어제자 파일이라 오늘 오전에 해킹당한 쇼핑몰은 잡아내지도 못했다. [162번 문서 참고]

이 미친 짓을 막기 위해 IETF(국제 인터넷 표준화 기구)는 1999년에 **OCSP (RFC 2560)**를 발명했다. "야, 엑셀 전체를 왜 다운받아? 쇼핑몰이 준 인증서 번호가 '1234'면, 그냥 CA한테 카톡 하나 날려. '1234번 살아있냐?' 그러면 CA가 'ㅇㅇ 살아있음(Good)' 아니면 'ㄴㄴ 죽었음(Revoked)' 딱 한 줄만 답장해 주면 0.1초 만에 끝나잖아!"

이 기발한 실시간 1:1 Q&A 시스템 덕분에 인터넷 브라우저의 로딩 속도와 보안성은 비약적으로 폭등했다.

📢 섹션 요약 비유: 수배 전단지 책자(CRL) 1만 페이지짜리를 매일 아침 택배로 받아 들고 다니며 길거리 사람들의 얼굴을 일일이 대조하는 게 옛날 방식입니다. OCSP는 길에서 수상한 사람을 보면 바로 경찰청(CA)에 무전기를 쳐서 "주민번호 990101-123456, 이놈 수배범 맞습니까?" 묻고 "아닙니다, 통과시키세요!" 하고 1초 만에 답변받는 스마트폰 신원 조회 시스템입니다.

Ⅱ. OCSP의 작동 원리 (실시간 핑퐁)

OCSP는 빠르고 가벼운 통신을 위해 복잡한 암호화를 쓰지 않고 단순한 HTTP 통신을 쓴다.

인증서 획득: 앨리스(브라우저)가 네이버에 접속해 인증서를 받는다. 인증서 속성(AIA)을 까보면 OCSP 응답 서버 주소: http://ocsp.digicert.com 라고 적혀있다.
OCSP Request (질문): 앨리스의 폰은 그 주소로 "네이버 인증서 일련번호 778899 상태 좀 알려줘!"라는 아주 작은 패킷(Request)을 휙 날린다.
OCSP Response (답변): CA(DigiCert)의 OCSP 전광판 서버는 자기들 내부 DB를 딱 0.001초 조회해 본 뒤, 다음 3가지 중 하나의 상태를 뱉어낸다.
- Good (정상): 해킹 안 당했고 잘 살아있음.
- Revoked (폐기됨): 해킹당했거나 폐업해서 내가 죽였음! 절대 접속하지 마!
- Unknown (모름): 어? 우리 DB에 그런 번호 자체가 아예 없는데? 가짜 아냐?
결정적 도장 (서명): 해커가 중간에서 "Good"이라고 거짓말 답장을 보낼 수 있으므로, CA 서버는 이 "Good"이라는 답변에 자신의 마스터 개인키로 전자서명(도장)을 쾅! 찍어서 보낸다. 앨리스 폰은 이 도장을 검사하고 100% 안심하며 네이버 창을 연다.

┌───────────────────────────────────────────────────────────────────────────────┐
│           OCSP (실시간 상태 질의)의 초고속 검증 아키텍처 시각화               │
├───────────────────────────────────────────────────────────────────────────────┤
│                                                                               │
│ [ 👩 앨리스 브라우저 ]                 [ 🏢 네이버 서버 ]                     │
│   1. 접속! ────────────────────────▶                                          │
│                     ◀────────── 2. "내 인증서(No. 778) 받아!"                 │
│                                                                               │
│  (잠깐 멈춤! CA한테 물어보자)                                                 │
│            │                                                                  │
│            │ 3. OCSP 질문 (100바이트)                                         │
│            │ "인증서 번호 778 죽었니? 살았니?"                                │
│            ▼                                                                  │
│  [ 🏛️ CA (DigiCert)의 OCSP 핫라인 서버 ]                                      │
│   (내부 DB 0.001초 검색: 778번 이상 없음 확인!)                               │
│            │                                                                  │
│            │ 4. OCSP 답변 (도장 쾅!)                                          │
│            │ "Good! (정상이다. 이 답변은 CA가 보증함 📝)"                     │
│            ▼                                                                  │
│                                                                               │
│  브라우저: "휴 다행이다! 자 이제 진짜 네이버 띄워준다~!" (0.1초 만에 렌더링)  │
└───────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 그림만 보면 0.1초 만에 완벽하게 방어가 끝나는 갓(God) 기술 같다. 하지만 네트워크 공학자들의 눈에는 이 그림에서 엄청난 2가지 재앙의 불씨(단일 병목, 프라이버시 침해)가 이글이글 타오르고 있는 것이 보인다. 브라우저가 사이트에 들어갈 때마다 무조건 CA 서버와 "3번과 4번 통신"을 해야만 한다는 구조적 한계점 때문이다.

📢 섹션 요약 비유: 클럽 입구에서 기도(브라우저)가 손님의 민증을 받으면, 두꺼운 위조 민증 책(CRL)을 뒤지지 않습니다. 바코드 스캐너로 띡! 찍으면 중앙 경찰 서버(OCSP)와 통신해서 0.1초 만에 "위조 아님 띠링~" 하고 파란불이 켜지는 최첨단 검사입니다.

Ⅲ. OCSP의 치명적 부작용 3가지 (왜 욕을 먹는가?)

아무리 빠르다 해도 전 세계 수십억 대의 폰이 이 짓을 하면 인터넷 전체가 망가진다.

프라이버시(Privacy) 대재앙
- 내가 '우울증 병원 사이트'나 '야동 사이트'에 들어갔다 치자. 내 브라우저는 접속 창을 열기 전에, CA(도장 가게) 서버에 "나 지금 우울증 사이트 인증서(번호 1234) 검사해 줘!"라고 패킷을 보낸다.
- 결과: CA 기업(구글, 디지서트 등)은 가만히 앉아서 전 세계 수십억 명의 사람들이 매일 밤 어느 사이트에 몇 시에 접속하는지 '실시간 사생활 접속 로그(Tracking)'를 100% 수집하고 감시하는 빅브라더가 되어버린다. 개인정보 보호론자들이 거품을 물고 반대했다.
CA 서버의 병목과 디도스(DDoS)
- 만약 블랙프라이데이에 아마존에 1억 명이 접속하면? 그 1억 대의 브라우저가 동시에 CA의 OCSP 서버로 "아마존 인증서 살았냐?!"고 질문(Traffic) 폭탄을 날린다. CA 서버가 못 버티고 뻗어버린다(단일 고장 점, SPOF).
Soft-Fail의 함정 (해커의 꼼수)
- 해커가 CA의 OCSP 서버를 디도스로 눕혀버렸다. 내 브라우저가 질문을 던졌는데 CA가 3초 동안 응답이 없다.
- 브라우저는 접속을 끊을까? (Hard-Fail). 그러면 네이버, 구글이 다 마비된다.
- 그래서 크롬은 **"에이, 응답 없으면 일단 접속 통과시켜 줘!(Soft-Fail)"**라는 타협을 한다. 해커는 이걸 노린다! 진짜 해킹한 네이버 인증서로 가짜 사이트를 연 뒤, 옆에서 OCSP 서버만 디도스로 눕혀버리면? 크롬은 멍청하게 "응답 없네, 그냥 열어!"라며 해커의 사이트를 파란 자물쇠 띄우고 통과시켜 버린다. (OCSP 무력화)

Ⅳ. 결론 및 구원자의 등장 (OCSP Stapling)

"가장 가볍고 완벽한 1:1 질문이, 역설적으로 전 세계 인터넷에 거대한 족쇄를 채웠다." OCSP는 뚱뚱한 CRL 엑셀 파일을 버리고 실시간 API 질의를 도입한 훌륭한 진보였다. 하지만 클라이언트(사용자 폰)가 직접 CA에게 "나 저기 접속해!"라고 질문을 날려야 하는 아키텍처 자체가, 속도 지연(Latency)과 사생활 털림이라는 치명적 독을 품고 있었다.

이 무거운 숙제를 브라우저(고객)에게 짊어지게 하지 말고, 접속할 서버(네이버)가 미리 CA에게 도장 받아온 걸 고객에게 주면 안 될까? 라는 천재적인 역발상이 등장했고, 이것이 바로 다음 시대의 표준을 지배한 **'OCSP 스테이플링(Stapling)'**이다. [164번 문서 참조]

📌 관련 개념 맵

전체 분류: PKI (Public Key Infrastructure) 인증서 상태 검증 메커니즘
대체한 구형 기술: CRL (Certificate Revocation List - 거대한 오프라인 엑셀 파일 다운로드)
진화된 다음 기술: OCSP Stapling (서버가 대신 OCSP 답변을 챙겨서 브라우저에 던져주는 기술)
보안 한계점: Soft-Fail (응답 없으면 통과시키는 브라우저의 허점), Privacy Leak (접속 기록 노출)

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

길에서 만난 경찰 아저씨가 진짜인지 확인하려고(CRL 책자 뒤지기 귀찮아서) 제가 직접 112 경찰청에 전화를 걸었어요. "여기 경찰 번호 778번 아저씨 진짜 맞아요?"
경찰청에서 1초 만에 "네 맞습니다!" 대답해 줘서 빠르고 좋긴 했는데, 치명적인 문제가 두 개 생겼어요.
첫째, 전 국민이 동시에 112에 전화하니까 경찰청 전화통이 불타버렸고요! 둘째, 경찰청은 제가 하루 종일 누구랑 만나서 노는지 통화 기록(사생활)을 다 엿보게 되어버린 아주 찜찜한 방법이었답니다.