SSLv3 에 대한 POODLE 공격으로부터 NGINX 및 NGINX Plus 보호
최근에 보고된 SSL 프로토콜 버전 3(SSLv3)의 취약점은 NGINX 웹 공격에 악용될 수 있어 HTTPS로 암호화된 일부 텍스트 전송을 추출할 수 있다고 합니다. Google 연구원들은 이러한 공격이 어떻게 실행될 수 있는지 자세히 설명했습니다.
이 취약점은 SSL/TLS 구현의 취약점이 아니라 블록 암호를 사용할 때 SSLv3 프로토콜 설계의 취약점입니다. 모든 대체 스트림 암호에도 취약점이 있으므로 유일한 대책은 NGINX 및 NGINX Plus 구성에서 SSLv3를 비활성화하는 것입니다.
목차
1. NGINX에서 SSLv3 비활성화
2. 비활성화로 인한 영향
3. SSLv3 에 대한 미래
4. SSLv3 공격에 대한 기타 해결책
1. NGINX 에서 SSLv3 비활성화
SSLv3 는 NGINX에서 기본적으로 사용되며 HTTP 및 메일 서비스에서 사용될 수 있습니다.
모든 NGINX 인스턴스에서 다음 단계를 수행하세요.
1. HTTP 트래픽에 사용되는 프로토콜 세트에서 SSLv3 를 제거하세요. http{} 블록에 ssl_protocols 지시어가 없는 경우, 매개변수 목록에서 SSLv3를 제거하기 위해 지시어를 추가하거나 편집하세요.
# in the http{} configuration block
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)2. NGINX 인스턴스가 메일 트래픽을 처리하는 경우, mail{} 구성 블록에서 동일한 지시문을 생성하거나 편집하세요.
# in the mail{} configuration block
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)3. NGINX 인스턴스가 TCP 트래픽을 처리하는 경우, stream{} 구성 블록에서 동일한 지시문을 생성하거나 편집하세요.
# in the stream{} configuration block
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)4. 구성에서 ssl_protocols 지시문의 다른 모든 인스턴스를 찾으세요 (http{}, mail{} 및 stream{} 블록 내의 server{} 구성 블록에 포함될 수 있음). 이러한 ssl_protocols 지시문을 제거하세요. 그러나 최소한 매개변수 목록에서 SSLv3를 제거하는 것이 좋습니다:
# in every server{} block
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)5. 구성을 다시 로드하기 위해 다음 명령을 실행하세요.
nginx -s reload2. 비활성화로 인한 영향
모든 최신 브라우저와 API 클라이언트는 TLSv1 이상을 지원합니다. SSLv3 를 비활성화하면 WindowsXP 사용자가 인터넷 익스플로러 6을 사용하여 브라우징할 때 불편을 겪을 수 있습니다. CloudFlare는 WindowsXP 사용자 중 약 1.12%가 전체 트래픽의 3.12%를 차지하며, 이는 약 3000명 중 1명에 해당하는 비율입니다.
이 변경은 웹 크롤러 및 기타 자동화된 봇 트래픽에도 영향을 줄 수 있습니다.
3. SSLv3 에 대한 미래
SSL 다운그레이드 공격에서 공격자는 SSL/TLS 핸드셰이크를 방해하여 클라이언트와 서버가 이전 버전의 SSL/TLS를 선택하도록 유도할 수 있습니다. 만약 SSLv3 를 강제로 선택하게 되면, SSL/TLS 연결은 POODLE 공격에 취약해질 수 있습니다. 그러나 서버에서 SSLv3를 비활성화하면 이러한 공격을 방지할 수 있습니다.
Google은 강제 SSL/TLS 다운그레이드를 방지하기 위해 TLS_FALLBACK_SCSV라는 SSL/TLS 확장을 제안했습니다. 이 확장 기능은 결국 OpenSSL에서도 채택될 수 있으며, 주요 브라우저에서 해당 클라이언트 측 지원이 추가될 것입니다. 이렇게 되면 웹 서비스는 SSLv3를 지원할 수 있지만, 레거시 클라이언트는 여전히 취약할 수 있습니다.
그럼에도 불구하고, 이 취약점은 SSLv3의 마지막 관문을 닫는 안정적인 솔루션으로 여겨질 수 있습니다.
4. SSLv3 공격에 대한 기타 해결책
SSLv3를 지원하지 않도록 클라이언트 소프트웨어를 업데이트하는 것이 좋습니다. 이렇게 하면 SSLv3을 비활성화하도록 업데이트되지 않은 서비스에 액세스할 때 이러한 공격으로부터 사용자를 보호할 수 있습니다.
SSLv3 공격에 대한 자세한 대응 및 방어 방법은 NGINX STORE에 문의하여 확인해보세요.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
