SSL에 대해 알고 있던 상식, 이제는 대부분 틀렸습니다

한눈에 보는 핵심 요약

장기 인증서 + 수동 갱신이라는 예전 운영 방식은 끝났습니다. 지금은 TLS 1.3, 단기 인증서, ACME 자동화가 표준입니다.
CA의 부실 감사, 인증서 오발급, SHA-1 충돌, Heartbleed, 허술한 폐기 체계까지 — 굵직한 사고가 이어지면서 브라우저 업체들이 CA 업계의 합의를 기다리지 않고 자체 신뢰 정책을 강제하기 시작했습니다.
완전 순방향 비밀성(PFS) 도입으로, 서버 개인 키가 나중에 털려도 과거 통신 기록은 복호화할 수 없게 됐습니다.
인증서 최대 유효기간은 앞으로 급격히 줄어듭니다. 2026년 200일 → 2027년 100일 → 2029년 47일. 인증서 50개만 관리해도 연간 약 500번의 갱신을 처리해야 하는 시대입니다.
이제는 발급 자동화만으로 부족하고, 검색·발급·배포·형식 변환·서비스 재적용·소유권 관리·모니터링을 아우르는 인증서 수명주기 관리 자체가 필요합니다. 이 기반은 향후 포스트양자 암호 전환에도 그대로 이어집니다.

SSL에서 TLS로: 우리가 알던 그 구조

전통적인 SSL/TLS 핸드셰이크는 이렇게 동작했습니다.

브라우저가 지원 버전과 암호 스위트를 서버에 전달
서버가 하나를 선택하고 자신의 신원을 증명하는 인증서를 반환
브라우저가 인증서의 공개 키로 premaster secret을 만들어 서버에 전송
이후 통신은 이 공유 비밀을 기반으로 암호화

브라우저는 서버 인증서 → 중간 CA → 루트 CA로 이어지는 인증서 체인을 검증하는데, 이 루트 인증서는 사용자가 고르는 게 아니라 브라우저에 미리 번들로 들어 있습니다. 체인이 유효하면 신뢰하고, 아니면 경고를 띄우죠.

이름은 계속 'SSL'로 불렸지만, 실제로는 1999년 SSL 3.0 → TLS 1.0으로 넘어갔고, 2006년 TLS 1.1(초기화 버그 수정), 2008년 TLS 1.2(현대적 암호 스위트 추가, 다만 업그레이드는 느렸음)로 발전해왔습니다.

"RSA 2048, SHA-1, 3년 유효기간" — 그 유명한 OpenSSL 명령의 문제

한때 인터넷에 널리 퍼졌던 OpenSSL CSR 생성 명령은 RSA 2048, SHA-1, 3년 유효기간을 기본값으로 썼습니다. 새 키를 요청하는 부분 자체는 지금도 유효하지만, RSA 2048·SHA-1·3년 인증서는 더 이상 권장되지도, 허용되지도 않습니다.

게다가 'RSA'라는 단어 자체가 헷갈립니다.

지금은 안전하지 않다고 여겨지는 RSA 키 교환
타원 곡선 키로 대체되고 있는 RSA 인증서 키
경우에 따라 여전히 쓰이는 RSA 서명 알고리듬
RSA Conference, RSA라는 회사 이름

같은 약어가 완전히 다른 맥락에서 쓰이다 보니 "우리는 RSA를 씁니다"라는 말만으로는 실제로 무엇을 의미하는지 알 수 없습니다.

DV·OV·EV, 그리고 CA들의 오래된 사업 모델

인증서는 오랫동안 세 등급으로 판매됐습니다.

DV(Domain Validation): 도메인 제어권만 확인, 연간 약 200달러
OV(Organization Validation): 전화 확인·기업 존재 확인 추가, 약 500달러
EV(Extended Validation): 서류 절차 추가, 약 1,200달러 — 과거엔 주소창에 회사명이 초록색으로 표시됐죠

하지만 2019년 Chrome, Safari, Firefox가 EV 녹색 표시를 일제히 제거합니다. 이유는 Google 연구 결과, 사용자들이 결제 전 회사 정보를 실제로 확인하기보다 그냥 초록색 표시 자체만 믿는다는 게 밝혀졌기 때문입니다. 이후 DV·OV·EV 사이의 시각적 차이는 사실상 사라졌습니다.

한편 CA가 브라우저 루트 저장소에 남으려면 매년 WebTrust 감사를 받아야 했는데, 문제는 CA가 감사인을 직접 선정하고 비용을 지불하며 재계약 여부까지 결정하는 구조였다는 점입니다. 전형적인 이해상충이죠.

CA/Browser Forum: CA가 브라우저의 발목을 잡던 시절

2005년 CA들과 브라우저 업체들은 CA/Browser Forum을 만들고 Baseline Requirements라는 공통 규칙을 세웠습니다. 문제는 초기엔 규칙 변경에 CA와 브라우저 양쪽의 합의가 필요했다는 것 — 즉 CA가 마음만 먹으면 브라우저 측의 변경 요구를 막을 수 있었습니다.

1999년식 운영 모델은 이랬습니다: 사용자가 CA에 돈을 내고 도메인 제어권을 확인받아 수년짜리 인증서를 받고, 유출되거나 분실되면 새로 사서 씁니다.

신뢰가 무너진 사건들

DigiNotar (2011)

네덜란드 CA DigiNotar가 침해당해 공격자가 CA 루트 저장소까지 접근, google.com용 비정상 인증서를 발급했습니다. 이 인증서는 이란에서 실사용됐고요. 조사해보니 패치 안 된 소프트웨어, 네트워크 분리 부재, 인터넷에 노출된 내부 서비스, 기본 비밀번호까지 — 총체적 부실이었습니다. 그런데도 감사는 통과했습니다. 신뢰가 제거되자 DigiNotar는 몇 달 만에 파산했습니다.

Symantec 대규모 오발급 (2017)

세계 최대 CA였던 Symantec이 소유하지 않은 도메인(google.com 포함)의 인증서를 3만 개 넘게 오발급한 사실이 인증서 투명성 로그를 통해 드러났습니다. 자체 보안 정책을 무시했고 정식 감사인이 아닌 사람의 자료까지 제출했죠. 결국 Google이 Symantec/VeriSign/Thawte/RapidSSL 브랜드 신뢰를 모두 제거했고, 사업은 DigiCert에 넘어갔습니다.

기존 CA/Browser Forum과 정기 감사가 못 잡아낸 문제를, 공개 로그가 대신 잡아낸 것이 핵심입니다.

완전 순방향 비밀성(PFS): 감시 시대의 대응

Snowden이 공개한 자료는 PRISM(대형 기술기업 데이터 접근), Tempora(백본 광섬유 감청) 등 대규모 감시 프로그램을 드러냈습니다. 특히 무서운 건 "harvest now, decrypt later" — 트래픽을 미리 수집해두고, 나중에 개인 키를 확보하면 과거 통신을 통째로 복호화하는 방식이 실제로 추진됐다는 점입니다.

기존 방식은 하나의 장기 개인 키를 신원 증명과 암호화에 함께 썼기 때문에, 키가 나중에 유출되면 과거 통신까지 몽땅 뚫렸습니다. 2013년 도입된 PFS는 이 둘을 분리합니다.

인증서 → 서버 신원 증명 전용
데이터 암호화 → 세션마다 새로 만드는 일회성 Diffie-Hellman 키

Diffie-Hellman 교환에서는 클라이언트와 서버가 각각 비밀값(A, B)을 만들고, 공개된 G·P로 계산한 중간값만 교환합니다. 관찰자는 G^A, G^B는 볼 수 있어도 A, B 자체는 알 수 없고, 공유 비밀 자체가 네트워크로 전송되지도 않죠. 그 결과 나중에 개인 키를 얻어도 과거 세션은 복호화가 불가능해집니다. 유출 사고가 나도 피해 범위가 완전히 달라지는 겁니다.

인증서 투명성(CT) 로그

Google은 2013년 RFC 6962로 CT 로그를 추진, CA가 발급한 모든 인증서를 공개된 추가 전용 로그에 기록하도록 요구했습니다. Chrome은 CA들의 합의를 기다리지 않고 2015년 EV 인증서부터, 2018년엔 전체 인증서로 강제 확대했습니다. 로그에 없는 인증서는 아예 신뢰하지 않는 방식으로 밀어붙인 거죠.

덕분에 누구든 특정 도메인에 발급된 인증서 이력(도메인, 발급자, 만료일)을 검색할 수 있게 됐지만, 반대로 비공개 하위 도메인이나 인증서에 포함된 개인 이메일까지 열거될 수 있다는 부작용도 생겼습니다.

SHA-1: 알고도 3년을 더 쓴 위험

SHA-1 충돌 가능성은 2005년부터 경고됐습니다. 공격자가 정상 인증서와 악성 인증서가 같은 SHA-1 값을 갖게 만들 수 있다면, CA가 눈치채지 못한 채 부정한 인증서에 서명해버릴 수 있죠. Microsoft는 2013년 이를 심각한 문제로 판단해 2016년부터 Windows에서 SHA-1을 신뢰하지 않겠다고 선언했고, 2015년 free-start collision, 2017년 Google의 SHAttered(완전한 SHA-1 충돌 실증)로 우려가 현실이 됐습니다. 그런데 당시 3년짜리 인증서가 발급되고 있었기 때문에, 충돌이 실증된 이후에도 2019년까지 유효한 SHA-1 인증서가 남아있을 수 있었습니다.

Heartbleed와 작동하지 않은 폐기 시스템

2014년 Heartbleed는 OpenSSL 버퍼 오버플로 결함으로, 조작된 요청 한 번에 서버 메모리 최대 64KB를 유출시켰습니다(개인 키, 세션 토큰, 비밀번호 포함 가능, 반복 요청도 가능). 인터넷 보안 서버의 **17%**가 취약했습니다.

여기서 PFS의 진가가 드러납니다. PFS를 쓰던 서버는 개인 키가 노출돼도 과거 통신 전체가 뚫리지 않았지만, 안 쓰던 서버는 그 키로 보호된 과거 통신까지 노출됐다고 가정해야 했죠.

문제는 수십만 개 인증서를 한꺼번에 폐기해야 하는데, 기존 인프라가 이를 감당하지 못했다는 점입니다.

CRL: 폐기 목록 전체를 파일로 배포 — 크고 느리고 최신화 어려움
OCSP: 상태 조회 API지만 장애가 잦고, 방문 사이트가 CA에 노출되는 프라이버시 문제
OCSP stapling: 구현이 어려워 널리 채택되지 못함
CRLSet(Chrome) 등: 중요 정보 일부만 배포

실제로 revoked.badssl.com은 브라우저에 따라 차단되기도, 정상 로드되기도 합니다 — 인증서 폐기가 얼마나 일관되지 않은지 보여주는 상징적인 사례죠.

Let's Encrypt와 ACME: 자동화가 답이었다

Mozilla와 EFF가 각각 진행하던 무료 CA, 자동 발급 프로토콜 작업이 비영리 조직 ISRG 아래로 합쳐지며 Let's Encrypt(CA) + ACME(자동화 프로토콜) 조합이 탄생했습니다. 목표는 단순합니다: 사람 개입 없이 무료 단기 인증서를 발급·갱신하는 것.

동작 방식도 간단합니다.

ACME 클라이언트가 CA에 인증서 요청
도메인 제어권 증명 도전 과제를 받음 — DNS _acme-challenge TXT 레코드 추가, 또는 /.well-known/acme-challenge 경로에 지정 파일 제공
검증 후 CSR 전송
수초 안에 인증서 발급 — 전화 확인도, 서류도, 결제도 없음

초기 CA들은 "기업이 이 방식을 감당 못 할 것"이라며 반대했지만, 10년이 지난 지금 전체 인증서의 60%가 Let's Encrypt에서 발급되고, 매일 수백만 건이 갱신됩니다. IRS(미국 국세청)조차 Let's Encrypt의 무료 DV 인증서를 씁니다. ACME는 이제 사실상 표준이죠.

브라우저가 CA의 거부권을 무력화하다

2017년 Google은 인증서 최대 유효기간을 3년에서 1년으로 줄이자고 제안했습니다. 다른 브라우저들은 찬성했지만, Let's Encrypt를 제외한 CA들이 반대하면서 CA/Browser Forum의 합의 요건을 채우지 못했습니다.

...(원문이 이 지점에서 끊겨 있어, 이후 브라우저 업체들이 실제로 어떤 방식으로 CA들의 거부권을 무력화하고 유효기간 단축을 관철시켰는지는 이어지는 영상에서 확인하실 수 있습니다.)

정리하며

DigiNotar, Symantec, SHA-1, Heartbleed로 이어지는 일련의 사고들은 결국 하나의 결론으로 수렴합니다. CA들의 자율 규제와 느슨한 합의 구조로는 인터넷 신뢰를 지킬 수 없다는 것이죠. 그래서 브라우저 업체들은 CT 로그, EV 표시 제거, 유효기간 단축을 밀어붙였고, Let's Encrypt와 ACME는 그 흐름 위에서 '수동 갱신'이라는 관행 자체를 없애버렸습니다.

앞으로 인증서 최대 유효기간이 2026년 200일, 2027년 100일, 2029년 47일로 계속 줄어드는 만큼, 단순히 '발급 자동화'만으로는 부족합니다. 검색·발급·배포·형식 변환·재적용·소유권·모니터링까지 아우르는 인증서 수명주기 관리 체계를 지금부터 갖춰두는 것이 곧 다가올 포스트양자 암호 전환에도 그대로 자산이 될 겁니다.

원문: https://news.hada.io/topic?id=32756