Heartbleed는 HTTPS 인증서만으로 안전을 보장하지 못함을 보여줬다

Heartbleed는 HTTPS 인증서가 유효하고 연결이 암호화돼 있어도 서비스가 안전하다고 단정할 수 없음을 보여준 사례다. TLS 구현의 오류로 연결 상대에게 프로세스 메모리가 노출될 수 있었다.

문제는 암호화 수학이 깨진 데 있지 않았다. 프로토콜 경계의 작은 오류로 공격자가 소프트웨어에 읽지 말아야 할 바이트를 돌려달라고 요청할 수 있었다.

잘못된 프로토콜 기능

TLS/DTLS 하트비트 확장 기능은 연결 상대끼리 연결이 살아 있는지 확인하는 방법을 제공한다. 하트비트 메시지는 메시지 유형, 선언된 페이로드 길이, 페이로드, 패딩으로 구성된다. 응답은 요청의 페이로드를 그대로 돌려줘야 한다. 수신 측은 선언된 페이로드와 필요한 패딩이 수신 레코드 안에 들어맞지 않으면 메시지를 거부해야 한다. RFC 6520 3~4절

핵심 조건은 간단하다.

declared payload length <= bytes actually available for the payload

취약한 OpenSSL 코드가 필요한 경계 검사를 하지 않아 Heartbleed가 발생했다. 따라서 응답에는 송신자가 보낸 페이로드만이 아니라 프로세스 메모리의 인접 영역이 포함될 수 있었다. OpenSSL 보안 권고에 따르면 연결된 클라이언트나 서버가 요청 한 번으로 약 64KB까지 노출시킬 수 있었다. 이는 범위를 벗어난 읽기(out-of-bounds read)이지, 임의의 파일을 읽는 기능은 아니다. OpenSSL 보안 권고

이 차이는 취약점의 심각성과 불확실성을 함께 설명한다. 연결 상대가 파일 이름이나 특정 비밀번호를 지정해 요청하는 것은 아니다. 노출되는 내용은 읽기가 발생한 시점의 프로세스 메모리에 따라 달라진다.

영향을 받은 버전과 당시 수정 사항

2014년 4월 보안 권고에서 영향을 받는다고 명시한 버전은 OpenSSL 1.0.1부터 1.0.1f까지와 베타1을 포함한 취약한 1.0.2 베타 버전이다. 당시 수정 버전은 1.0.1g와 1.0.2-beta2였으며, 임시 조치로 빌드 시 하트비트 지원을 비활성화할 수 있었다.

이는 과거 버전 경계에 대한 정보이지, 2026년에 설치할 버전을 권하는 내용이 아니다. 지금 시스템에서 취약점이 발견되면 공급업체가 유지·관리하는 지원 중인 패키지로 옮겨야 한다. 실제로 TLS를 처리하는 구성 요소를 확인해야 한다. 애플리케이션 의존성을 업그레이드해도 요청 경로의 다른 곳에 있는 오래된 리버스 프록시나 어플라이언스는 수정되지 않는다. 당시 버전 정보는 OpenSSL 보안 권고에 나와 있다.

시스템 목록에는 외부 TLS 종료 지점, 오리진 서버의 수신기, 관리용 HTTPS 인터페이스, 같은 라이브러리를 사용하는 별도 서비스를 구분해 기록해야 한다. 브라우저로 호스트 이름 하나에 접속해 확인할 수 있는 경로는 그중 하나뿐이다.

개인 키도 유출될 수 있었나

무작위 메모리 노출로는 중요한 정보를 얻기 어렵다고 생각하기 쉽다. Cloudflare는 2014년 의도적으로 취약하게 만든 Nginx 서버를 대상으로 공개 시험을 진행해 이 가정을 확인했다. 참가자들이 서버의 개인 키를 복구했고, Cloudflare는 성공한 제출물이 Heartbleed를 이용했다고 확인했다. Cloudflare의 시험 결과

이 시험은 당시 조건에서 개인 키 복구가 가능했음을 보여준다. 그렇다고 취약한 모든 배포 환경에서 키가 유출됐거나 특정 엔드포인트가 공격당했다는 뜻은 아니다.

사고를 검토할 때는 다음 세 질문을 구분해야 한다.

• 노출 기간에 운영 중이던 소프트웨어가 취약했는가?
• 해당 프로세스 메모리에 어떤 비밀 정보나 민감한 데이터가 있을 수 있었는가?
• 실제 접근과 그 뒤의 오용에 관한 증거가 있는가?

세 번째 질문에 대한 답이 부정적이라고 해서 앞의 두 질문에 대한 답까지 자동으로 부정되는 것은 아니다.

대응은 두 가지 완료 기준으로 관리해야 한다

취약한 환경에서는 소프트웨어 수정과 신뢰 자료의 교체를 따로 추적해야 한다.

먼저 영향을 받는 TLS 처리 프로세스를 모두 찾아 업데이트한다. 새 패키지가 실제로 사용 중인지 확인해야 한다. 디스크의 라이브러리를 교체하는 일과 실행 중인 프로세스를 교체하는 일은 다르다. 부하 분산 서비스를 운영한다면 외부 주소를 한 번 확인하고 모든 인스턴스가 같다고 가정하지 말고, 각 백엔드나 종료 계층을 확인해야 한다.

다음으로 어떤 자격 증명, 세션, 키 자료를 교체해야 하는지 평가한다. 노출 경로를 차단한 뒤에 대체 자료를 설치해야 한다. 그렇지 않으면 새로 교체한 자료도 노출될 수 있다.

인증서 키를 다룰 때는 새 키를 생성했는지, 어디에 배포했는지, 기존 인증서를 어떻게 처리했는지 기록한다. 애플리케이션 자격 증명은 발급 서비스와 폐기 상태, 이를 사용하는 클라이언트를 함께 기록한다. 적절한 조치 범위는 영향을 받은 프로세스와 아키텍처에 따라 달라지므로 TLS 핸드셰이크만으로 스캐너가 결정할 수 없다.

종료 기록에는 패키지나 어플라이언스 버전, 재시작한 구성 요소, 테스트한 엔드포인트, 자격 증명별 별도 조치를 담는 것이 유용하다. “검사 결과가 깨끗하다”는 말만으로는 전체 대응을 설명하기 어렵다.

로컬 정보와 원격 검사 결과 구분하기

다음과 같은 로컬 명령은 해당 셸에서 실행한 OpenSSL 실행 파일에 관한 정보를 보여준다.

openssl version -a

이 결과만으로 웹 서버나 번들형 어플라이언스, 컨테이너가 어떤 라이브러리를 사용하는지 입증할 수는 없다. 패키지 목록과 실제 서비스를 처리하는 프로세스 정보를 함께 확인해야 한다.

Nmap의 Heartbleed 스크립트는 취약점을 능동적으로 탐지한다. 버전 문자열만 확인하는 것과는 다르다. 직접 운영하거나 점검 권한을 받은 시스템에만 사용하고, 결과를 엔드포인트 및 프로세스 관련 증거와 함께 해석해야 한다. Nmap 스크립트 문서

서비스를 복구해야 한다는 점을 설명하기 위해 유출된 메모리를 수집하거나 공개할 필요는 없다.

NetChek의 검사 범위

NetChek의 ssl_heartbleed 검사는 열린 TCP 포트 443과 8443에서 Nmap의 ssl-heartbleed 스크립트를 실행한다. 스크립트가 표시하는 취약점 신호를 찾아 가능성이 있는 문제로 기록한다. 전체 환경의 라이브러리를 목록화하거나 과거에 공격이 있었는지 조사하지는 않는다.

검사 결과가 깨끗하더라도 그 의미는 검사한 주소와 포트, 응답한 서비스, 검사 시점에 한정된다. 환경 내 모든 TLS 포트와 가상 호스트, 백엔드를 다루지는 않는다. 과거에 노출됐을 수 있는 자격 증명이 폐기됐는지도 알려주지 않는다.

따라서 Heartbleed 보안 안내를 이 글과 함께 참고할 수 있다. 외부 검사는 유용한 관찰 결과를 제공하지만, 실제 복구에는 그 뒤에 있는 소프트웨어와 비밀 정보를 파악해야 한다.

기술 참고 자료는 2026년 10월 13일에 검토했다. 과거의 실험과 수정 버전은 위에서 과거 정보로 표시했다.