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

Owen GarrettDirector sénior de Gestión de Producto

Una vulnerabilidad detectada recientemente en la versión 3 del protocolo SSL (SSLv3) puede aprovecharse mediante un ataque de intermediario para extraer partes de una transmisión de texto sin formato cifrada con HTTPS. Investigadores de Google han publicado una explicación detallada sobre cómo podría llevarse a cabo un ataque de este tipo.

No se trata de una vulnerabilidad en ninguna implementación de SSL/TLS, sino de una vulnerabilidad en el diseño del protocolo SSLv3 cuando se utilizan cifrados por bloques. Dado que todos los cifrados de flujo alternativos también presentan debilidades, la única medida posible es deshabilitar SSLv3 en las configuraciones de NGINX y NGINX Plus.

Deshabilitar SSLv3 en NGINX

SSLv3 está habilitado de forma predeterminada en NGINX y NGINX Plus, y puede ser utilizado por los servicios HTTP y de correo.

[Nota del editor: El uso de proxy y el balanceo de carga del tráfico TCP no eran totalmente compatibles cuando se publicó originalmente este artículo. Para que la información esté completa, se han actualizado los pasos siguientes a fin de incluir la protección del tráfico TCP.]

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

1. Elimine SSLv3 del conjunto de protocolos utilizados para el tráfico HTTP. Añada 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.

# in the http{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

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

# in the mail{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

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

# in the stream{} configuration blockssl_protocols TLSv1 TLSv1.1 TLSv1.2; # omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Localice todas las demás instancias de la directiva ssl_protocols en su configuración (puede estar incluida 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:

# in every server{} block ssl_protocols TLSv1 TLSv1.1 TLSv1.2;# omit SSLv3 because of POODLE (CVE‑2014‑3566)

1. Ejecuta el siguiente comando para volver a cargar la configuración:

# nginx –s reload

¿Qué efecto tiene este cambio?

Todos los navegadores modernos y clientes de API son compatibles con TLSv1 y versiones posteriores. Deshabilitar SSLv3 causará inconvenientes a los usuarios de WindowsXP que naveguen con Internet Explorer 6; CloudFlare estima que el 1,12 % de los usuarios de WindowsXP (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 a otro tráfico automatizado de bots.

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. Si 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 impide este ataque.

Google ha propuesto una extensión para SSL/TLS denominada TLS_FALLBACK_SCSV cuyo objetivo es evitar la degradación forzada de SSL/TLS. [Nota del editor: la extensión se adoptó como RFC 7507 en abril de 2015.] Es posible que esta extensión acabe incorporándose a OpenSSL y que se añada la compatibilidad correspondiente en el lado del cliente a los principales navegadores. Esto permitirá que los servicios web sean compatibles con SSLv3, pero los clientes antiguos seguirán siendo vulnerables.

No obstante, esta vulnerabilidad podría suponer el golpe de gracia para SSLv3, lo que constituiría una solución más sencilla y fiable en general.

¿Qué más puedo hacer?

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

Lecturas adicionales

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

Sobre el autor

Owen GarrettDirector sénior de Gestión de Producto

Más artículos de Owen Garrett