Protección de NGINX y NGINX Plus contra el ataque POODLE contra SSLv3 (CVE-2014-3566)

Una vulnerabilidad recientemente reportada en la versión 3 del protocolo SSL (SSLv3) puede ser explotada en un ataque de intermediario para extraer partes de una transmisión de texto simple que fue cifrada con HTTPS. Los investigadores de Google han publicado una explicación detallada que describe cómo podría llevarse a cabo un ataque de este tipo.

Esta no es una vulnerabilidad en ninguna implementación de SSL/TLS, sino más bien una vulnerabilidad en el diseño del protocolo SSLv3 cuando se utilizan cifrados de bloque. Como todos los cifrados de flujo alternativos también muestran debilidades, la única medida es deshabilitar SSLv3 en sus configuraciones NGINX y NGINX Plus.

Deshabilitar SSLv3 en NGINX

SSLv3 está habilitado de forma predeterminada en NGINX y NGINX Plus, y potencialmente lo utilizan los servicios HTTP y de correo.

[Editor: El proxy y el equilibrio de carga del tráfico TCP no eran totalmente compatibles cuando se publicó originalmente este artículo. Para mayor exhaustividad, se han actualizado los siguientes pasos para incluir protección para el tráfico TCP.]

Realice estos pasos en todas las instancias de NGINX y NGINX Plus:

1. Eliminar SSLv3 del conjunto de protocolos utilizados para el tráfico HTTP. Agregue la siguiente directiva ssl_protocols al bloque http{} si no existe, o edite la directiva existente para eliminar SSLv3 de la lista de parámetros.

   # en los bloques de configuración http{} sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 debido a POODLE (CVE‑2014‑3566)

2. Cree o edite la misma directiva en el bloque de configuración mail{} si sus instancias NGINX o NGINX Plus manejan tráfico de correo.

   # en los bloques de configuración mail{} sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 debido a POODLE (CVE‑2014‑3566)

3. Cree o edite la misma directiva en el bloque de configuración stream{} si sus instancias NGINX o NGINX Plus manejan tráfico TCP.

   # en los bloques de configuración stream{} sl_protocols TLSv1 TLSv1.1 TLSv1.2; # omitir SSLv3 debido a POODLE (CVE‑2014‑3566)

4. Ubique todas las demás instancias de la directiva ssl_protocols en su configuración (se puede incluir en un bloque de configuración server{} dentro de los bloques http{} , mail{} y stream{} ). Recomendamos eliminar estas directivas ssl_protocols , pero como mínimo elimine SSLv3 de la lista de parámetros:

   # en cada bloque server{} ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omitir SSLv3 debido a POODLE (CVE‑2014‑3566)

5. Ejecute el siguiente comando para recargar la configuración:

   # nginx –s recargar

¿Cuál es el efecto de este cambio?

Todos los navegadores modernos y clientes API admiten TLSv1 y versiones posteriores. Deshabilitar SSLv3 causará inconvenientes a los usuarios de Windows XP que navegan utilizando Internet Explorer 6; CloudFlare estima que el 1,12% de los usuarios de Windows XP (que representan el 3,12% de su tráfico) se verán afectados, lo que equivale aproximadamente a 1 de cada 3000 usuarios.

El cambio también podría afectar a los rastreadores web y otro tráfico de bots automatizados.

El futuro

En un ataque de degradación de SSL , el atacante puede interrumpir los protocolos de enlace SSL/TLS y hacer que el cliente y el servidor seleccionen una versión anterior de SSL/TLS. Cuando se utiliza para forzar la selección de SSLv3, puede hacer que la conexión SSL/TLS sea vulnerable al ataque POODLE. Deshabilitar SSLv3 en el servidor hace que este ataque sea imposible.

Google ha propuesto una extensión para SSL/TLS denominada TLS_FALLBACK_SCSV que busca evitar degradaciones forzadas de SSL/TLS. [Editor: La extensión se adoptó como RFC 7507 en abril de 2015]. Esta extensión podría eventualmente ser aceptada en OpenSSL y la correspondiente compatibilidad del lado del cliente podría añadirse a los principales navegadores. Esto permitirá que los servicios web admitan SSLv3, pero los clientes heredados seguirán siendo vulnerables.

Sin embargo, esta vulnerabilidad podría ser el último clavo en el ataúd de SSLv3: una solución más simple y más confiable en general.

¿Qué más puedo hacer?

Le recomendamos que actualice el software de su cliente para que no sea compatible con SSLv3. Esto lo protegerá de este ataque cuando acceda a servicios que no se hayan actualizado para deshabilitar SSLv3.

Más información

• El informe de vulnerabilidad original
• Una explicación más concisa de ImperialViolet
• Varios proveedores han publicado recomendaciones; la de Ubuntu es particularmente completa.