국내 대표적인 취약점 점검 항목에 '취약한 HTTPS 프로토콜 이용 제한' 이라는 항목이 존재한다.
해당 항목은 '암호화된 메시지가 복호화가 가능' 하기 떄문에 암호 통신 내용이 유출될 수 있는 위협이 존재하여 체크리스트 항목으로 HTTPS 프로토콜 중, SSL 프로토콜이나 TLS 구버전인 TLSv1.0 TLSv1.1 을 사용하는 서비스라면 체크되는 항목이다.
그 중에서 SSL (Secure Sockets Layer) 은 사용하지 말아야 하지만, 사용되기 때문에 종종 취약점으로 잡히곤 하는데, SSL은 푸틀, 비스트, 크라임/브리치, 하트블리드 (정확히 OpenSSL 구현 버그긴 하지만 해당 환경에서 발생한 대표적인 사고라 작성) 등 여러 취약점을 가지고 있는 암호화 프로토콜이라 알고나면 결국 사용하지 않는데, 이게 항목 자체가 영향도도 낮고 "어짜피 높은 버전을 쓰고 있는데 영향이 있는거냐" 라는 등 반박하는 사람이 있어서 해당 내용을 찾아보며 정리하고자 한다.
SSL 프로토콜
SSL 프로토콜은 Secure Sockets Layer Protocol 로 네트워크 통신에서 기밀성과 무결성, 그리고 인증을 제공하는 프로토콜이다. `90년대 중반에 Netscape 가 개발하였고 사용자 웹 브라우저와 서버 간의 HTTPS 통신 기반이 되었다.
SSL 버전 히스토리는 다음과 같다.
| 버전 | 발표 년도 | 비고 |
| SSLv1.0 | - | 치명적 결함으로 인한 비공개 |
| SSLv2.0 | 1995 | 첫 공개버전이나 심각한 결함 발견 2011년 RFC 7568을 근거로 폐기 |
| SSLv3.0 | 1996 | 재설계 버전으로 이후 취약점으로 인한 암호화 프로토콜 기능을 잃음 2015년 RFC 7568을 근거로 폐기 |
SSL의 경우, SSLv1.0 부터 사용된 것이 아니라 1995년에 발표된 SSLv2.0 부터 사용되었다. 하지만 해당 프로토콜에 대한 취약점이 발견됨에 따라 1996년 3.0 으로 대체되었으나, SSLv2 도 2011년 3월 사용이 금지되었으며, 이후 SSLv3.0 도 이어 2015년 6월 사용 금지 당했다. SSL 이후 1999년 TLS 1.0 이 발표됨에 따라 이름이 바뀌고 TLSv1.2, TLSv1.3 이 표준이다.
SSL도 암호화 프로토콜로 개발되었기 떄문에 암호화 프로토콜들이 가지는 핵심 구성 요소는 세 가지를 동일하게 가진다.
- Handshake Protocol: 암호화 알고리즘에서 협상과 키 교환, 인증서 검증
- Record Protocol: 실제 데이터를 암복호화하고 전송
- Alert Protocol: 오류나 경고 메시지 처리
SSL 및 TLS 는 응용 계층과 전송 계층 (Application / Transport Layer) 사이에서 동작하며 HTTP 나 SMTP, FTP 등 다양한 프로토콜에 대한 보호가 가능하다.
TLS 프로토콜
SSL 프로토콜 이후 만들어진 TLS 프로토콜 (Transport Layer Security Protocol)은 네트워크 통신에서 SSL과 동일하게 기밀성과 무결성, 인증을 제공하는 프로토콜이다. SSL의 후속 표준으로 볼 수 있으며, IETF (Internet Engineering Task Force) 에서 관리한다. 현재 HTTPS를 비롯한 대부분의 통신에서 기반이 되어 사용 중에 있다.
SSLv3.0 기반으로 만들었으나 이름도, 표준 기구도 바뀌며 새로운 프로토콜 계열로 분리되었으며, IETF가 TLS를 더 투명하고 체계적으로 발전했다는 분석이 대부분이다. 실무에선 대부분 SSL/TLS 라고 묶어 부르나, 결국 기술적으론 TLS가 SSL을 대체한 표준으로 TLS를 뜻한다고 이해하면 될 듯.
TLS 버전 히스토리는 다음과 같다.
| 버전 | 발표 년도 | 비고 |
| TLSv1.0 | 1999 | SSLv3.0 을 그대로 가져오되, 일부 보안 강화. 2021년 RFC 8996 근거로 폐기 |
| TLSv1.1 | 2006 | IV 예측 문제를 일부 개선하고 CBC 관련 보안수행. 2021년 RFC 8996 근거로 폐기 |
| TLSv1.2 | 2008 | AES-GCM 등 *AEAD를 지원하고 SHA-256 기반, 확장성을 강화함. |
| TLSv1.3 | 2018 | 대대적인 재설계, 핸드셰이크 간소화, 구식 암호 완전 제거. 현재 권장되는 표준 |
- AEAD (Authenticated Encryption with Associated Data): 암호화된 데이터의 기밀성과 무결성 및 변조방지를 위한 인증을 동시에 제공하며 패킷 헤더 같은 연관 데이터 (Associated Data) 까지 함께 인증하는 현재 암호화 방식
TLS 핵심 구성 요소
TLS 핵심 요소로 4개를 꼽을 수 있는데, 위 SSL 프로토콜의 구성요소에 1개가 더 추가된다.
- Change Cipher Spec (TLSv1.2까지): 암호화 파라미터 전환 신호.
그런데 같은 구성요소에서 SSL 대비해서 어떤게 달라졌을까.
SSL 대비 주요 개선
- SSL보다 더 복잡한 (강력한) 해시 함수 및 암호 알고리즘 지원
- TLSv1.1 부터 CBC 모드 취약점을 완화시킬 목적의 개선
- TLSv1.2 부터 AEAD 모드를 지원하며 AES-GCM, ChaCha20-Poly1305 등을 본격적으로 지원
- TLSv1.3 에서 구식 알고리즘 (RC4, 3DES, CBC, SHA-1 등)을 프로토콜 차원에서 제거하고 핸드 셰이크를 *1-RTT (혹은 0-RTT)로 간소화
- 0/1-RTT (Round Trip Time): 클라이언트와 서버가 패킷을 n번 주고받는 왕복시간. 0-RTT의 경우 이전에 연결했던 기록을 이용하여 왕복 지연 없이 첫 데이터를 바로 보내는 최적화 모드.
SSL 및 구버전 TLS 프로토콜 취약 사유
SSL 프로토콜 (특히 v3.0 이하)과 초기 TLS 가 취약 사유는 설계 당시 한계 및 하위 호환성 유지 에 따른다. 물론 암호화 값에 대한 예측 가능하다는 점과 검증 문제도 있기도 하지만.
- 설계 철학 한계: `90년대의 경우, 암호학 지식이 현재처럼 암호학 지식이 굉장하게 많은게 아니라 오히려 부족했던 시기다. 따라서 MAC-then-Encrypt 형식의 구조 (MAC: 메시지 인증코드를 평문에 먼저 붙인 다음 전체를 암호화 하는 구조) 특성상 우선 복호화를 처리하기 때문에 잘못된 형식의 메시지라도 복호화가 수행되기에 Padding Oracle 공격 (암호화된 데이터의 패딩 유효성 검사 결과 (오라클) 를 이용해 공격자가 암호화를 평문으로 복호화 하는 방법. 패딩의 잘못 유무에 따라 메시지가 달라지는 것을 이용한 바이트 조절로 기존 평문데이터 추출) 에 취약하다.
- *CBC모드 약점: TLSv1.0 까지 CBC 모드에서 IV (Initialization Vector) 값이 예측 가능하거나 패딩 검증이 제대로 수행되지 않는 문제가 존재했다.
- CBC (Cipher Block Chaining): 각 평문 블록이 암호화 되기 전까지의 이전 암호문 블록과 XOR 연산을 수행하는 블록 암호 운용 방식
- 버전 협상 취약점: 클라이언트가 높은 버전을 제안해도 중간 공격자가 핸드셰이크를 방해하여 낮은 버전의 프로토콜 (SSLv3, TLSv1.0 등) 로 다운그레이드가 가능하였다.
- 약한 *암호 스위트 지원: Weak Cipher Suite 지원이라고도 불리며 미국 정부가 국가 안보 및 정보 수집을 위해 암호 기술의 해외 반출 금지 (Export Restriction)가 수행되어 (예시: 해외 수출용 소프트웨어인 RSA 키 길이의 최대 512비트 제한) RC4, 3DES, MD5 등 약한 알고리즘을 사용할 수 밖에 없었다.
- 암호 스위트 (Cipher Suite): 안전한 네트워크 통신(SSL/TLS)을 위해 사용하는 [인증, 키 교환, 대칭키 암호화, 무결성 검증] 알고리즘들을 하나의 꾸러미로 모아 놓은 조합
- 하위 호환성: 레거시 시스템 지원을 위해 오래된 프로토콜을 사용하면서 공격 표면도가 커졌다.
그러니까 프로토콜 자체 설계 결함에다가 구현 버그까지 발생하며 여러 공격이 발생하게 되었다. TLSv1.3 에서는 이러한 문제들을 AEAD만 사용, 다운그레이드 방지 강화등으로 근본적으로 해결하게 된다.
버전별 취약사유 요약
| 프로토콜 | 취약사유 |
| SSLv3.0 | 패딩 문제가 비결정적이며, MAC 보호도 없어 결국 POODLE 취약점의 원인이 됨. |
| TLSv1.0 | IV 값이 이전 블록으로 고정되어 BEAST 취약점의 원인이 됨. |
| TLSv1.1 | TLSv1.0 에서 일부 개선되었으나 약한 암호 스위트와 CBC 관련 문제가 잔존하여 Lucky13 취약점의 원인이 됨. |
| 위 사유들로 인하여 2021년, 4개의 프로토콜의 경우 IETF에서 공식 폐기가 수행됨. (RFC 8996) |
프로토콜 버전 자체가 구 버전인 경우, 결국 해당 프로토콜에서 수행되는 암호 스위트도 약해지는 것으로 해석하면 되지 않을까.. 싶다. 해당 알고리즘에 대한 역계산이 가능하니까.
대표적 SSL/TLS 프로토콜 취약점
위 작성한 약점들로 인하여 결국 해당 프로토콜들을 이용한 취약점이 발견되어 발표되었는데, 해당 항목들은 네트워크 단이라 그런지 파장이 어마어마하다.
| 취약점 | 대표 CVE | 대상 프로토콜 | 취약점 세부내용 | 영향 |
| BEAST | CVE-2011-3389 | TLS 1.0 | CBC 모드에서 IV가 예측 가능한 점을 이용해 블록 단위로 평문을 복호화 |
세션 쿠키 등 |
| CRIME / BREACH | CVE-2012-4929 | TLS / HTTP 압축 | 압축 길이 차이를 이용해 비밀 값을 추론 |
쿠키, CSRF 토큰 등 유출 |
| Lucky Thirteen | CVE-2013-0169 | CBC 모드 | 타이밍을 이용한 Padding Oracle 공격 | 평문 일부 복호화 |
| POODLE | CVE-2014-3566 | SSL 3.0 | 다운그레이드 후 패딩 오라클을 이용해 바이트 단위로 복호화 |
세션 쿠키 등 탈취 |
| Heartbleed | CVE-2014-0160 | OpenSSL 구현 | Heartbeat 확장의 메모리 누출 버그 |
서버 메모리 (개인키 포함) 유출 |
| FREAK | CVE-2015-0204 | Export RSA | 약한 수출용 RSA 키(512bit)로 강제 다운그레이드 |
세션키 복호화 |
| Logjam | CVE-2015-4000 | Export DH | 약한 Diffie-Hellman 그룹으로 강제 다운그레이드 |
세션키 복호화 |
| DROWN | CVE-2016-0800 | SSLv2 + RSA | SSLv2를 오라클로 사용해 TLS 세션키를 복구 |
크로스 프로토콜 공격 |
| Sweet32 | CVE-2016-2183 | 64-bit 블록 암호 (3DES 등) |
생일 공격으로 충돌을 유도해 평문 일부 복호화 |
장기 세션 위험 |
와 찾아볼거 많다.
이 중에서 POODLE 과 BEAST, DROWN, HeartBleed 는 어디선가 들어봤을 정도로 유명한 취약점이며 Poodle, Beast, Drown 의 경우 프로토콜 설계 자체에서 비롯된 문제라 고치는 것으로 해결되는 것이 아닌 해당 프로토콜 버전을 사용하지 않아야 해결되는 취약점이라 파장이 컸다.
꽤 오랜 시간이 지난 2026년 지금은 취약한 HTTPS 프로토콜 이용 제한 항목에 대해 조치방안으로 단순히 구버전 비활성화 하세요~ 라고 안내하긴 하지만, 해당 방안말고 다른 것도 영향을 줄 가능성이 높아보여 한번 더 찾아보았다.
조치방안
1. 프로토콜 버전 제한
서버 내 비활성화가 요구되는 프로토콜은 다음과 같다.
- SSLv2.0 / SSLv3.0
- TLSv1.0 / TLSv1.1
총 4개 항목의 프로토콜은 꼭 비활성화가 필요하며, 권장 구성으로는 TLSv1.3 우선 사용이 권고된다. TLSv1.3 쓰는 것이 제한된다면 TLSv1.2 는 허용하되, 약한 암호 스위트는 제거해야한다.
2. 약한 암호 스위트 제거
약한 암호 스위트 항목은 다음과 같다.
- NULL / aNULL / eNULL
- EXPORT / EXP
- RC4
- DES / 3DES
- MD5
- SHA1 (가능한 경우)
- Non-Forward Secrecy (비전방 비밀성) 스위트 (RSA 키 교환만 이용하는 경우)
해당 스위트 항목들은 금방 역계산 및 복호화가 가능하여 사용하지 않는 것이 권고되며 *ECDHE 또는 *DHE 기반 키 교환 사용과 AEAD 모드 (AES-GCM, ChaCha20-Poly1305) 를 사용하는 것이 권고된다.
- ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): 암호화 프로토콜을 사용하는 통신에서 클라이언트와 서버가 서로 인증하고 대칭키를 안전하게 교환하기 위한 Key Exchange (키 합의) 알고리즘. 이름대로 타원 곡선 암호 이론을 이용하며 세션 별 임시키를 생성 및 폐기, 완전 전방 비밀성으로 이전 통신 데이터 복호화 불가, 기존 RSA 키교환 보다 네트워크 지연이 짧다는 특징을 가짐.
- DHE는 서버와 클라이언트가 매번 일회성 비밀키를 생성해 교환하는 키 교환 알고리즘. (ECDHE 와의 차이점은 일반 이산대수냐 타원곡선 대수냐 차이... 정도인듯)
점검 방법
필자의 경우 SSLScan 및 nmap 을 주로 사용하는데, 그냥 두 도구 중에 본인이 편한 것을 셀렉해서 쓰면 될 듯 하다.
SSLScan 취약 판단 주요 기준
| 구분 | 취약 판단 기준 | 설명 |
| 프로토콜 | SSLv2, SSLv3, TLSv1.0, TLSv1.1 이 Enabled | 공식 폐기되었거나 심각한 설계 결함이 존재 |
| 암호 스위트 | RC4, DES, 3DES, EXPORT, NULL, aNULL, eNULL, MD5 포함 시 |
약한 알고리즘 또는 인증/암호화가 없는 스위트 |
| 키 교환 | RSA 키 교환만 사용하고 ECDHE/DHE가 없으면 비권장 | Forward Secrecy가 없어 장기적으로 위험 |
| 비트 수 | 40-bit, 56-bit, 112-bit 등 낮은 비트의 암호 | Export-grade 또는 구식 암호 |
SSLScan 결과 취약 예시
| Accepted TLSv1.0 128 bits AES128-SHA Accepted TLSv1.0 112 bits DES-CBC3-SHA Accepted SSLv3 128 bits RC4-SHA |
SSLScan 결과 양호 예시
| Preferred TLSv1.3 256 bits TLS_AES_256_GCM_SHA384 Accepted TLSv1.3 128 bits TLS_AES_128_GCM_SHA256 Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 |
nmap 취약 판단 주요 기준
nmap --script ssl-enum-ciphers -p 443 <대상>nmap 이용시, TLSv1.0 과 TLSv1.1 섹션이 존재하거나 각 프로토콜 하단에 출력되는 암호 스위트 등급이 C이하 (C, D, E 등), weak/broken/insecure 키워드가 포함되거나 3DES/RC4/DES/EXPORT 등이 보이면 취약이다. nmap은 SSLScan 보다 더 세부적으로 나누어 보여주며 자체적으로 암호 스위트에 등급을 매겨서 C이하 이면 조치 대상으로 판단하면 된다.
취약점 점검하다보면 진짜 쉽게 쉽게 확인하고 바로 바로 보고 넘기는 취약점에 불과하지만, 공격에 대한 고도화나 암호 알고리즘 문제로 인한 추가적 이슈가 생길 여지가 분명하니 해당 취약점에 대해서 한번 더 생각해보고 넘어가보자.