용어 사전
OpenSSL이란 — HTTPS의 토대가 되는 라이브러리와 그 방어법
OpenSSL은 HTTPS(TLS/SSL)와 암호화를 떠받치는 오픈소스 라이브러리입니다. 대부분의 서버는 웹 서버나 OS를 통해 간접적으로 사용하기에 결함 하나가 전 세계로 번집니다(Heartbleed). 영향 범위가 큰 이유와 방어법: 버전 파악, EOL 회피, CVE 감시, 신속한 패치.
HTTPS를 제공하고 있다면 여러분의 서버는 거의 틀림없이 OpenSSL(또는 호환 구현) 위에서 돌고 있습니다. 직접 손댈 일은 없지만 그 결함은 모두에게 닿습니다 — 그 기반 라이브러리가 무엇이며 어떻게 방어하는지 정리합니다.
어디에 자리하는가 — "물려받는" 토대
OpenSSL의 까다로운 점은 고른 적도 없으면서 쓰고 있다는 것입니다. 여러분의 앱은 TLS를 웹 서버에 맡기고, 웹 서버는 암호화를 OpenSSL에 맡기며, 그 OpenSSL은 OS가 함께 제공합니다 — 겹겹이 쌓인 스택입니다.
보통은 이것이 축복입니다 — 암호화를 전문가가 작성한 공용 구현에 맡길 수 있기 때문입니다. 하지만 그 공용 토대에 구멍이 생기면 그 위에 올라탄 모두가 한꺼번에 영향을 받습니다. "기반 라이브러리의 결함은 영향 범위가 엄청나게 넓다"는 말의 의미가 바로 이것입니다.
왜 무서운가: 버그 하나가 전 세계의 키를 위협했다
2014년의 Heartbleed(CVE-2014-0160)는 OpenSSL의 작은 구현 실수(주장된 길이를 검증하지 않고 신뢰한 것)에서 비롯되어, 외부인이 서버 메모리 — 거기에는 개인 키와 세션 데이터가 포함될 수 있었습니다 — 를 조금씩 읽을 수 있게 만들었습니다. OpenSSL이 워낙 널리 쓰였던 탓에 전 세계의 수많은 서버가 동시에 표적이 되었습니다(전말 → Heartbleed).
교훈은 단호합니다: 의존성이 토대에 가까울수록 영향 범위는 넓어진다. 따라서 앱이 직접 가져오는 의존성만이 아니라, 그 밑에서 돌고 있는 OpenSSL 같은 기반 라이브러리도 똑같은 진지함으로 감시하고 패치할 가치가 있습니다.
어떻게 방어하는가: EOL 회피, 토대 감시
자신의 스택이 어떤 OpenSSL을 쓰는지 파악한다
보이지 않는 것은 방어할 수 없습니다. 서버, 컨테이너 베이스 이미지, 언어 런타임이 각각 어떤 OpenSSL(릴리스 라인과 버전)에 의존하는지 목록으로 만드십시오.
지원 종료(EOL) 버전을 돌리지 않는다
릴리스 라인이 지원 기간을 지나면 거기서 새로 발견되는 취약점은 수정되지 않습니다. EOL을 돌린다는 것은 구멍이 발견되어도 닫히지 않을 문을 열어 두는 것입니다. 지원되는 라인으로 업그레이드할 계획을 세우십시오.
토대도 CVE 감시에 포함한다
앱 의존성은 osv-scanner 같은 도구로 쉽게 추적할 수 있지만, OS가 함께 제공하는 OpenSSL은 놓치기 쉽습니다. 기반 라이브러리의 새 CVE도 떠오르도록 해 두십시오(→ CVE 대응 플레이북).
심각할 때는 신속하게 패치한다
Heartbleed급 버그는 공개되는 순간 공격받습니다. 심각도가 요구할 때는 기반 패치를 당일에 배포할 수 있을 만큼 업데이트 경로를 가볍게 유지하십시오 — "다음 정기 업데이트 때"가 아니라.
저희의 견해: 토대는 기계로 감시한다
기반 라이브러리의 결함은 사람의 기억으로 추적할 수 없습니다. 본 사이트는 자체 의존성과 토대를 기계 기반 CVE 감시 아래에 두고 있습니다. Let's Encrypt로 제공하는 인증서조차 그 밑에서는 OpenSSL 계열 구현으로 암호화를 수행합니다 — 그러므로 "보이지 않는 토대"를 목록화하고 감시 아래에 두는 것이 영향 범위가 큰 사고를 막는 가장 빠른 길입니다.
이어서 읽기
- 사고에서 배운다: Heartbleed (전 세계의 키를 위협한 OpenSSL의 결함)
- 관련: Let's Encrypt란 무엇인가 (무료 TLS 인증서 + 자동 갱신) / 용어: CVE란 무엇인가
- 실전: CVE 대응 플레이북 / osv-scanner로 의존성 감시하기
FAQ
QOpenSSL을 설치한 적이 없는데 — 그래도 쓰고 있을 수 있나요?
거의 틀림없이 그렇습니다. OpenSSL은 웹 서버(Nginx/Apache), 운영체제, 언어 런타임이 내부적으로 사용하는 기반 라이브러리입니다. 코드에서 한 번도 참조한 적이 없더라도 HTTPS를 제공하고 있다면 그 밑에서 OpenSSL(또는 호환 구현)이 돌고 있을 가능성이 매우 높습니다. '나는 안 쓴다'고 가정하는 것이야말로 기반 취약점을 놓치게 되는 전형적인 경로입니다.
QLibreSSL이나 BoringSSL과는 어떻게 다른가요?
둘 다 OpenSSL의 포크입니다. LibreSSL은 Heartbleed 이후 OpenBSD 프로젝트가 코드베이스를 정리하기 위해 만들었고, BoringSSL은 Google이 자체 용도로 만든 변형입니다. 대부분의 사용자는 둘 중 무엇을 고를지 고민할 필요가 없습니다 — 훨씬 더 중요한 것은 자신의 플랫폼에 들어 있는 구현이 무엇이든 그것을 지원되는 최신 버전으로 유지하는 일입니다.
Q버전을 확인하거나 업데이트하려면 어떻게 하나요?
많은 시스템에서 `openssl version`으로 확인할 수 있고, 업데이트는 OS의 패키지 관리자를 통하거나 컨테이너의 베이스 이미지를 다시 빌드해서 합니다. 핵심은 지원 종료(EOL)된 릴리스를 계속 돌리지 않는 것입니다. 어떤 릴리스 라인이 EOL이 되면 거기서 새로 발견되는 취약점은 더 이상 수정되지 않습니다. 기반 의존성도 애플리케이션의 의존성과 똑같은 방식으로 추적하십시오.