SSLv3에 대한 POODLE 공격(CVE-2014-3566)으로부터 NGINX 및 NGINX Plus 보호

최근 보고된 SSL 프로토콜 버전 3(SSLv3)의 취약점은 중간자 공격에 악용되어 HTTPS로 암호화된 일반 텍스트 전송의 일부를 추출할 수 있습니다. 구글 연구원들은 이러한 공격이 어떻게 발생할 수 있는지에 대한 자세한 설명을 발표했습니다.

이는 SSL/TLS 구현의 취약점이 아니라 블록 암호를 사용할 때 SSLv3 프로토콜의 설계상의 취약점입니다. 모든 대체 스트림 암호에도 취약점이 있으므로 유일한 대책은 NGINX 및 NGINX Plus 구성에서 SSLv3를 비활성화하는 것입니다.

NGINX에서 SSLv3 비활성화

SSLv3는 NGINX 및 NGINX Plus에서 기본적으로 활성화되어 있으며 HTTP 및 메일 서비스에서도 사용될 수 있습니다.

[편집자 - 이 기사가 처음 게시되었을 당시에는 TCP 트래픽의 프록시 및 부하 분산이 완전히 지원되지 않았습니다. 완전성을 위해 다음 단계가 TCP 트래픽 보호를 포함하도록 업데이트되었습니다.]

모든 NGINX 및 NGINX Plus 인스턴스에서 다음 단계를 수행합니다.

1. HTTP 트래픽에 사용되는 프로토콜 집합에서 SSLv3를 제거합니다. 다음 ssl_protocols 지시문이 http{} 블록에 존재하지 않으면 추가하거나 기존 지시문을 편집하여 매개변수 목록에서 SSLv3를 제거합니다.

   # http{} 구성 blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # POODLE(CVE‑2014‑3566)로 인해 SSLv3 생략

2. NGINX 또는 NGINX Plus 인스턴스가 메일 트래픽을 처리하는 경우 mail{} 구성 블록에서 동일한 지침을 만들거나 편집합니다.

   # 메일에서{} 구성 blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # POODLE(CVE‑2014‑3566)로 인해 SSLv3 생략

3. NGINX 또는 NGINX Plus 인스턴스가 TCP 트래픽을 처리하는 경우 stream{} 구성 블록에서 동일한 지침을 만들거나 편집합니다.

   # 스트림{} 구성 blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # POODLE(CVE‑2014‑3566)로 인해 SSLv3 생략

4. 구성에서 ssl_protocols 지시문의 다른 모든 인스턴스를 찾습니다( http{} , mail{} , stream{} 블록 내의 server{} 구성 블록에 포함될 수 있음). 이러한 ssl_protocols 지시어를 제거하는 것이 좋지만 최소한 매개변수 목록에서 SSLv3를 제거하는 것이 좋습니다.

   # 모든 서버{} 블록에서 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# POODLE(CVE‑2014‑3566)로 인해 SSLv3 생략

5. 다음 명령을 실행하여 구성을 다시 로드하세요.

   # nginx –s 다시 로드

이 변화의 효과는 무엇입니까?

모든 최신 브라우저와 API 클라이언트는 TLSv1 이상을 지원합니다. SSLv3를 비활성화하면 Internet Explorer 6을 사용하여 웹서핑하는 WindowsXP 사용자에게 불편을 줄 수 있습니다. CloudFlare는 WindowsXP 사용자의 1.12%(트래픽의 3.12%를 차지함)가 영향을 받을 것으로 추정합니다. 이는 약 3000명 중 1명에 해당합니다.

이러한 변경 사항은 웹 크롤러와 기타 자동화된 봇 트래픽에도 영향을 미칠 수 있습니다.

미래

SSL 다운그레이드 공격 에서 공격자는 SSL/TLS 핸드셰이크를 방해하고 클라이언트와 서버가 이전 버전의 SSL/TLS를 선택하도록 할 수 있습니다. SSLv3 선택을 강제로 사용하는 경우 SSL/TLS 연결이 POODLE 공격에 취약해질 수 있습니다. 서버에서 SSLv3를 비활성화하면 이 공격이 불가능해집니다.

Google은 강제 SSL/TLS 다운그레이드를 방지하는 TLS_FALLBACK_SCSV 라는 SSL/TLS 확장을 제안했습니다. [편집자 - 이 확장은 2015년 4월 RFC 7507 로 채택되었습니다.] 이 확장은 결국 OpenSSL에 수용될 수 있으며, 해당 클라이언트 측 지원이 주요 브라우저에 추가될 수 있습니다. 이를 통해 웹 서비스는 SSLv3를 지원할 수 있지만 기존 클라이언트는 여전히 취약할 것입니다.

그럼에도 불구하고 이 취약점은 SSLv3에 대한 최후의 못을 박는 신호일 수 있습니다. 즉, 전반적으로 더 간단하고 안정적인 솔루션입니다.

그 밖에 무엇을 할 수 있나요?

SSLv3를 지원하지 않도록 클라이언트 소프트웨어를 업데이트하는 것이 좋습니다. SSLv3를 비활성화하도록 업데이트되지 않은 서비스에 액세스할 때 이러한 공격으로부터 보호할 수 있습니다.

추가 읽기

• 원래의 취약성 보고서
• ImperialViolet의 더 간결한 설명
• 여러 공급업체가 권장 사항을 게시했습니다. Ubuntu의 권장 사항은 특히 포괄적입니다.