SSL(Secure Sockets Layer) 취약점에 대해 알아보겠습니다.

Ⅰ. SSL(Secure Sockets Layer) 취약점 이란? 

 웹 보안 프로토콜인 SSL과 이를 계승한 TLS(Transport Layer Security)에서 발생하는 보안 약점입니다. SSL은 안전한 인터넷 통신을 위해 널리 사용되었지만, 여러 취약점이 발견되면서 TLS로 대체되었습니다. 여전히 많은 웹사이트가 SSL을 사용하거나 SSL/TLS 설정이 잘못되어 다양한 공격에 노출될 수 있습니다.

Ⅱ. 주요 SSL/TLS 취약점

ⅰ. Heartbleed (하트블리드)
○ 설명: 2014년에 발견된 이 취약점은 OpenSSL 라이브러리에서 발생한 버그로 인해 공격자가 서버의 메모리 일부를 읽을 수 있는 문제입니다. 이를 통해 공격자는 암호화된 데이터, 사용자 이름, 비밀번호, 비밀 키 등 민감한 정보를 탈취할 수 있었습니다.
○ 원인: OpenSSL에서 잘못된 Heartbeat 프로토콜 구현으로 인해 발생.
○ 영향: 약 60%의 웹 서버가 이 버그의 영향을 받았습니다.
○ 조치: 취약한 OpenSSL 버전을 패치하고, SSL 인증서와 비밀 키를 교체해야 합니다.
○ 조치 방법
1) 취약한 OpenSSL 버전을 사용하는 서버에서 최신 패치 적용.
2) 서버에서 사용 중인 SSL 인증서와 비밀 키를 재발급하여 교체.
○ 권장 버전
1) OpenSSL 1.0.1g 이상 버전으로 업그레이드 (1.0.1 버전에서 발생한 버그).
2) OpenSSL 1.0.2 이상으로 업그레이드하면 추가적인 보안 향상 가능.

ⅱ. POODLE (Padding Oracle On Downgraded Legacy Encryption)
○ 설명: POODLE 공격은 SSL 3.0에서 발생하는 취약점으로, 공격자가 패딩 오라클 공격을 이용해 SSL 연결을 복호화할 수 있습니다. 주로 사용자가 HTTPS 연결에서 다운그레이드를 강제 당할 때 발생합니다.
○ 원인: SSL 3.0의 취약한 패딩 처리 방식.
○ 영향: 공격자는 네트워크 상의 민감한 정보를 가로챌 수 있습니다.
○ 조치: SSL 3.0을 비활성화하고, 최신 TLS 프로토콜(예: TLS 1.2 이상)을 사용해야 합니다.
○ 조치 방법
1) SSL 3.0 프로토콜을 비활성화하고 TLS만 사용하도록 서버와 클라이언트를 설정.
2) 안전한 암호화 알고리즘(Cipher Suite)을 사용하도록 설정.
○ 권장 버전
1) TLS 1.2 이상을 사용. 가능하면 TLS 1.3을 사용하는 것이 최선.
2) 클라이언트와 서버에서 SSLv3 프로토콜 비활성화.

ⅲ. BEAST (Browser Exploit Against SSL/TLS)
○ 설명: BEAST는 TLS 1.0 이하 버전에서 CBC(Cipher Block Chaining) 모드를 사용하는 경우, 공격자가 브라우저의 암호화된 세션을 복호화할 수 있게 하는 취약점입니다.
○ 원인: TLS 1.0 이하에서의 CBC 모드 취약점.
○ 영향: 공격자는 세션 쿠키나 기타 민감한 데이터를 탈취할 수 있습니다.
○ 조치: TLS 1.1 이상 버전을 사용하고, 안전한 암호화 알고리즘을 사용하도록 설정해야 합니다.
○ 조치 방법
1) TLS 1.0 이하 버전에서 발생하는 취약점이므로 TLS 1.1 또는 TLS 1.2 이상으로 업그레이드.
2) 서버 및 클라이언트에서 안전한 Cipher Suite를 선택하여 CBC 모드 사용을 피해야 합니다.
○ 권장 버전
1) TLS 1.2 이상을 사용하는 것이 권장됩니다.
2) TLS 1.1 이상에서는 이 취약점이 완화됩니다.

ⅳ. FREAK (Factoring RSA Export Keys)
○  설명: FREAK 공격은 클라이언트와 서버 간의 암호화 협상에서 강제로 취약한 RSA 키 길이를 사용하도록 만드는 취약점입니다. 공격자는 이 약한 키를 크랙하여 데이터를 탈취할 수 있습니다.
○ 원인: 1990년대 미국의 암호화 수출 제한으로 인해 생긴 약한 RSA 키.
○ 영향: HTTPS 통신이 취약한 암호화 키로 인해 공격당할 수 있습니다.
○ 조치: 서버와 클라이언트 모두에서 취약한 RSA 익스포트 암호화를 비활성화해야 합니다.
○ 조치 방법
1) RSA Export Cipher Suite를 비활성화하여 더 이상 약한 RSA 키를 사용하지 않도록 설정.
2) 서버와 클라이언트에서 강력한 암호화 키를 사용하도록 설정.
○ 권장 버전
1) TLS 1.2 이상을 사용하고, 클라이언트 및 서버에서 RSA Export Cipher Suite를 비활성화.

ⅴ. Logjam
○ 설명: Logjam 공격은 Diffie-Hellman 키 교환에서 사용되는 소수 기반의 취약점을 악용하는 방식으로, 공격자가 HTTPS 세션을 다운그레이드하거나 복호화할 수 있습니다.
○ 원인: Diffie-Hellman의 취약한 파라미터.
○ 영향: TLS 연결이 다운그레이드되거나 복호화될 수 있습니다.
○ 조치: 더 강력한 Diffie-Hellman 그룹을 사용하고 TLS 1.2 이상의 버전을 사용해야 합니다.
○ 조치 방법
1) Diffie-Hellman 키 교환 시 사용되는 소수(prime)를 1024비트에서 최소 2048비트 이상으로 업그레이드.
2) 강력한 Diffie-Hellman 그룹을 사용하도록 설정.
○ 권장 버전
1) TLS 1.2 이상을 사용하고, 2048비트 이상의 Diffie-Hellman 키를 사용해야 합니다.
2) TLS 1.3에서는 더 안전한 키 교환 방식이 기본적으로 사용됩니다.

ⅵ. DROWN (Decrypting RSA with Obsolete and Weakened eNcryption)
○ 설명: DROWN은 서버가 취약한 SSLv2 프로토콜을 지원할 경우, 공격자가 TLS 연결을 해독할 수 있는 취약점입니다. SSLv2에서의 약한 암호화는 공격자가 데이터를 쉽게 해독할 수 있게 합니다.
○ 원인: SSLv2 지원 서버에서 발생하는 취약한 암호화.
○ 영향: 공격자는 TLS 세션을 복호화하고 민감한 정보를 얻을 수 있습니다.
○ 조치: SSLv2 지원을 비활성화하고, 최신 보안 패치를 적용해야 합니다.
○ 조치 방법
1) 서버에서 SSLv2 지원을 완전히 비활성화.
2) SSLv2를 지원하는 구성을 모두 제거하고, TLS 1.2 이상의 버전을 사용.
○ 권장 버전
1) OpenSSL 1.0.2g 또는 OpenSSL 1.1.0 이상 버전으로 업그레이드.
2) SSLv2 및 SSLv3 비활성화, TLS 1.2 이상을 사용.

ⅶ. RC4 취약점
○ 설명: RC4 스트림 암호화 알고리즘은 여러 가지 암호화 분석 공격에 취약하여, 공격자가 암호화된 데이터를 해독할 수 있습니다. RC4는 주로 SSL/TLS 연결에서 널리 사용되었으나, 안전하지 않은 것으로 판명되었습니다.
○ 영향: 공격자가 RC4를 사용하는 세션의 데이터를 해독할 수 있습니다.
○ 조치: RC4 알고리즘을 비활성화하고, 보다 안전한 암호화 방식(AES-GCM 등)을 사용하는 것이 권장됩니다.
○ 조치 방법
1) RC4 암호화 알고리즘을 사용하는 모든 SSL/TLS 설정에서 RC4를 비활성화.
2) AES-GCM과 같은 강력한 암호화 알고리즘으로 전환.
○ 권장 버전
1) TLS 1.2 이상에서는 기본적으로 RC4를 비활성화하도록 설정.
2) TLS 1.3에서는 RC4가 아예 지원되지 않으므로 안전합니다.

Ⅲ. SSL 취약점에 대한 조치 방법

ⅰ. 최신 TLS 버전 사용
SSL 2.0 및 SSL 3.0은 더 이상 안전하지 않으므로 사용을 중단하고, TLS 1.2 이상(가능한 경우 TLS 1.3)을 사용해야 합니다.
ⅱ. 취약한 암호화 알고리즘 비활성화
RC4, MD5, 3DES와 같은 취약한 암호화 알고리즘을 비활성화하고, AES-GCM 등 보다 안전한 알고리즘을 사용해야 합니다.
ⅲ. 적절한 인증서 관리
SSL/TLS 인증서를 주기적으로 갱신하고, 인증서에서 사용하는 키 길이를 충분히 길게 설정해야 합니다(최소 2048비트 RSA 키 권장).
ⅳ. HSTS(HTTP Strict Transport Security) 적용
HSTS는 웹사이트가 HTTPS 연결만 허용하도록 강제하여, SSL/TLS 다운그레이드 공격을 방지할 수 있습니다.
ⅴ. 취약한 프로토콜 비활성화
SSLv2, SSLv3, TLS 1.0과 같이 알려진 취약점을 가진 프로토콜은 서버에서 비활성화해야 합니다.
ⅵ. 보안 패치 적용
서버 운영 체제와 SSL/TLS 라이브러리(OpenSSL, GnuTLS 등)의 최신 보안 패치를 항상 적용해야 합니다.
ⅶ. 강력한 키 교환 알고리즘 사용:
Diffie-Hellman 키 교환에서 취약한 512비트 소수를 사용하는 대신 2048비트 이상의 강력한 키를 사용해야 합니다.