HTTPS를 제공하고 있다면 서버는 거의 틀림없이 OpenSSL(또는 호환 구현) 위에서 돌고 있습니다. 직접 손댈 일은 없지만, 결함이 발견되면 엄청난 수의 서버가 영향을 받습니다. 이 라이브러리가 무엇을 하며 어떻게 방어하는지 정리합니다.
어디에서 쓰이는가
OpenSSL의 까다로운 점은 고른 적도 없으면서 쓰고 있다는 것입니다. 앱은 TLS를 웹 서버에 맡기고, 웹 서버는 암호화를 OpenSSL에 맡기며, 그 OpenSSL은 OS가 함께 제공하는, 겹겹이 쌓인 구조입니다.
보통은 이것이 편리합니다. 암호화를 전문가가 작성한 공용 구현에 맡길 수 있기 때문입니다. 하지만 그 공용 라이브러리에 취약점이 생기면 그것을 쓰는 모두가 한꺼번에 영향을 받습니다. 기반 라이브러리의 결함은 영향 범위가 넓다는 말의 의미가 바로 이것입니다.
OpenSSL, SSL/TLS, 인증서의 차이
이름이 비슷해 섞여 쓰이지만 각각 역할이 다릅니다.
| 용어 | 무엇인가 | 예 |
|---|---|---|
| SSL / TLS | 연결을 암호화하는 규칙(프로토콜). SSL은 옛 버전이고, 지금은 TLS 1.2 / 1.3을 씀 | HTTPS는 HTTP를 TLS로 감싼 것 |
| OpenSSL | TLS와 암호 연산을 실제로 수행하는 프로그램(라이브러리)과 함께 제공되는 명령줄 도구 | Nginx와 Apache가 내부에서 호출 |
| 인증서 | 인증 기관이 도메인 소유를 보증하는 데이터. 공개 키가 들어 있음 | Let's Encrypt가 무료로 발급 |
즉 OpenSSL은 TLS 규칙을 구현하는 도구 중 하나이고, 인증서는 그 도구가 연결 중에 쓰는 데이터입니다. TLS를 구현하는 라이브러리는 그 밖에도 있으며(LibreSSL, BoringSSL, Windows Schannel 등), 어느 것을 쓰는지는 OS와 소프트웨어에 따라 다릅니다.
영향이 넓은 이유: 버그 하나가 많은 서버의 키를 위험에 빠뜨렸다
2014년의 Heartbleed(CVE-2014-0160)는 OpenSSL의 작은 구현 실수(주장된 길이를 검증하지 않고 신뢰한 것)에서 비롯되었습니다. 외부인이 서버 메모리를 조금씩 읽을 수 있었고, 거기에는 개인 키와 세션 데이터가 포함될 수 있었습니다. OpenSSL이 워낙 널리 쓰였던 탓에 전 세계의 수많은 서버가 동시에 표적이 되었습니다(전말 → Heartbleed).
교훈은 분명합니다. 의존성이 스택의 아래쪽에 있을수록 영향 범위는 넓어집니다. 따라서 앱이 직접 가져오는 의존성만이 아니라, 그 밑에서 돌고 있는 OpenSSL 같은 기반 라이브러리도 똑같이 진지하게 감시하고 패치해야 합니다.
어떻게 방어하는가: EOL 회피, 기반 라이브러리 감시
자신의 스택이 어떤 OpenSSL을 쓰는지 파악한다
보이지 않는 것은 방어할 수 없습니다. 서버, 컨테이너 베이스 이미지, 언어 런타임이 각각 어떤 OpenSSL(릴리스 라인과 버전)에 의존하는지 목록으로 만드세요.
지원 종료(EOL) 버전을 돌리지 않는다
릴리스 라인이 지원 기간을 지나면 거기서 새로 발견되는 취약점은 수정되지 않습니다. EOL을 계속 돌리면 취약점이 발견되어도 수정되지 않은 채 남습니다. 지원되는 라인으로 업그레이드할 계획을 세우세요.
기반 라이브러리도 CVE 감시에 포함한다
앱 의존성은 osv-scanner 같은 도구로 쉽게 추적할 수 있지만, OS가 함께 제공하는 OpenSSL은 놓치기 쉽습니다. 기반 라이브러리의 새 CVE도 드러나도록 해 두세요(→ CVE 대응 플레이북).
심각할 때는 신속하게 패치한다
Heartbleed급 버그는 공개되는 순간 공격받습니다. 심각도가 요구할 때는 '다음 정기 업데이트 때'가 아니라 당일에 기반 패치를 배포할 수 있도록 업데이트 경로를 가볍게 유지하세요.
지원 중인 버전(2026년 10월 기준)
OpenSSL 프로젝트는 홀수 해 4월에 장기 지원(LTS) 버전을 내고 최소 5년간 지원합니다. 3.5 이후에 나온 LTS가 아닌 버전은 출시 후 13개월간 지원됩니다.
| 라인 | 종류 | 지원 종료 |
|---|---|---|
| 4.0 | 일반 | 2027년 5월 14일 |
| 3.6 | 일반 | 2026년 11월 1일 |
| 3.5 | LTS | 2030년 4월 8일 |
| 3.4 | 일반 | 2026년 10월 22일 |
| 3.0 / 1.1.1 / 1.0.2 | — | 종료(OpenSSL Corporation의 유료 연장 지원만) |
OS가 제공하는 OpenSSL은 사정이 다릅니다. Red Hat 계열을 비롯한 많은 Linux 배포판은 버전 번호를 올리지 않고 수정만 가져옵니다(백포트). OS의 지원 기간 동안에는 3.0으로 표시되는 패키지도 OS 벤더로부터 수정을 계속 받을 수 있습니다. 번호만 보고 '오래됐으니 취약하다', '새것이니 안전하다'고 판단하지 말고, OS 벤더의 보안 공지를 확인하세요.
자신의 환경에서 확인하는 방법
OS의 OpenSSL을 확인한다
openssl version -a로 버전을 봅니다. 패키지 버전은 Debian/Ubuntu에서는 dpkg -l 'libssl*' openssl, Red Hat 계열에서는 rpm -q openssl로 확인합니다. 그 패키지 버전을 OS 벤더의 보안 공지와 대조해 수정이 들어 있는지 봅니다.애플리케이션이 실제로 쓰는 것을 확인한다
nginx -V, Python은 python3 -c "import ssl; print(ssl.OPENSSL_VERSION)", Node.js는 node -p process.versions.openssl로 내장 버전을 볼 수 있습니다.컨테이너 이미지도 확인한다
OpenSSL 보안 공지를 구독한다
취약점 심각도 읽는 법
OpenSSL 프로젝트는 자체 취약점을 네 단계로 평가하고, 그에 따라 수정의 배포 방식을 바꿉니다.
| 심각도 | 대략적인 의미 | 수정의 배포 방식 |
|---|---|---|
| Critical | 흔한 설정에 영향을 주고 악용이 쉬움(서버 메모리의 대량 유출, 개인 키 탈취 등) | 모든 지원 버전에 즉시 수정판 출시 |
| High | Critical보다는 덜하지만 여전히 심각(덜 흔한 설정, 클라이언트 측만 해당 등) | 비공개로 준비한 뒤 모든 지원 버전에 출시 |
| Moderate | 서비스 거부, 드문 프로토콜 등에 한정 | 다음 정기 릴리스에 포함 |
| Low | 명령줄 도구만 해당, 일어나기 어려운 조건 조합 등 | 다음 정기 릴리스에 포함 |
Heartbleed처럼 외부에서 서버 메모리를 읽을 수 있는 결함은 Critical의 정의에 해당합니다. Critical과 High는 예고를 본 시점부터 업데이트 준비를 시작하세요.
이 사이트의 관점: 기반 라이브러리는 기계로 감시한다
기반 라이브러리의 결함은 사람의 기억으로 추적할 수 없습니다. 이 사이트는 자체 의존성과 기반을 기계적인 CVE 감시 아래에 두고 있습니다. Let's Encrypt로 제공하는 인증서도 그 밑에서는 OpenSSL 계열 구현으로 암호화를 수행합니다. 그러므로 평소 의식하지 않는 기반 라이브러리를 목록으로 만들고 감시하는 것이 영향 범위가 넓은 사고를 막는 가장 직접적인 방법입니다.
이어서 읽기
- 사고에서 배운다: Heartbleed(많은 서버의 개인 키를 위험에 빠뜨린 OpenSSL의 결함)
- 관련: Let's Encrypt란 무엇인가(무료 TLS 인증서 + 자동 갱신) / 용어: CVE란 무엇인가
- 실전: CVE 대응 플레이북 / osv-scanner로 의존성 감시하기
출처(1차 자료)
- OpenSSL Library, "Release Strategy" — openssl-library.org(LTS 방침, 라인별 지원 종료일)
- OpenSSL Library, "Security Policy" — openssl-library.org(심각도 4단계, 사전 예고)
- Red Hat, "Backporting Security Fixes" — access.redhat.com(버전 번호만으로는 취약 여부를 알 수 없는 이유)
- NIST NVD, "CVE-2014-0160" — nvd.nist.gov(Heartbleed)