Deshabilitando Protocolos SSL/TLS Obsoletos en Apache Tomcat

La seguridad en las comunicaciones a través de redes es fundamental, y protocolos como Secure Socket Layer (SSL) y Transport Layer Security (TLS) juegan un papel crucial en garantizar la confidencialidad e integridad de los datos transmitidos entre clientes y servidores. Sin embargo, con el avance de la tecnología y el descubrimiento continuo de vulnerabilidades, es imperativo mantener actualizados los protocolos de seguridad y deshabilitar aquellos que se consideran obsoletos o inseguros. Este artículo se centrará en cómo deshabilitar específicamente los protocolos SSLv2 y SSLv3 en Apache Tomcat, asegurando así una comunicación más robusta y segura.

Comprendiendo SSL y TLS

SSL (Secure Socket Layer) y su sucesor, TLS (Transport Layer Security), son protocolos criptográficos diseñados para proporcionar seguridad en las comunicaciones a través de una red. Cuando un cliente se conecta a un servidor utilizando estos protocolos, se lleva a cabo un proceso conocido como "apretón de manos" (handshake). Durante este apretón de manos, el cliente y el servidor negocian los cifrados y algoritmos hash mutuos que ambos soportan, estableciendo así un canal de comunicación seguro. TLS es, en esencia, la evolución de SSL, abordando muchas de sus debilidades.

Vulnerabilidades en Protocolos Obsoletos

A lo largo de los años, se han descubierto y continúan descubriéndose vulnerabilidades en las versiones antiguas de SSL y TLS. Un ejemplo notorio es la vulnerabilidad POODLE (Padding Oracle On Downgraded Legacy Encryption) (CVE-2014-3566), que afectaba al protocolo SSLv3. Esta vulnerabilidad permitía a un atacante "man-in-the-middle" descifrar el texto cifrado mediante un ataque de "padding oracle".

Debido a estas y otras debilidades inherentes, el uso de SSLv2 y SSLv3 ya no se recomienda. De hecho, a partir de las versiones de actualización de parche crítico del 20 de enero de 2015 (JDK 8u31, JDK 7u75, JDK 6u91 y posteriores), Java Runtime Environment (JRE) desactiva SSLv3 por defecto.

Configuración de SSL/TLS en Apache Tomcat

Apache Tomcat, un servidor de aplicaciones web Java popular, utiliza conectores para gestionar la comunicación. La configuración de seguridad, incluyendo los protocolos SSL/TLS permitidos, se realiza principalmente en el archivo server.xml.

Modificación del Archivo server.xml

El archivo server.xml se encuentra típicamente en el directorio $TOMCAT_HOME/conf/. Para configurar los protocolos SSL/TLS, se deben localizar los elementos Connector que manejan las conexiones HTTPS.

Si el archivo server.xml no contiene un bloque <Connector> para HTTPS después de <Service name="Catalina">, es necesario añadir uno. Un ejemplo básico para configurar HTTPS sería:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLSv1.2" />

Sin embargo, para deshabilitar protocolos específicos como SSLv2 y SSLv3, se debe prestar atención a los atributos sslProtocols (para JSSE connectors) o SSLProtocol (para APR/Native connectors).

Utilizando Conectores JSSE

Cuando se utilizan los conectores JSSE para la configuración HTTPS, el protocolo SSL/TLS a emplear se configura a través del atributo sslEnabledProtocols o sslProtocols en el archivo $TOMCAT_HOME/conf/server.xml.

Si estos atributos se especifican, solo se habilitarán los protocolos que se listen y que sean compatibles con la implementación SSL. Si no se especifican, se utilizará la configuración predeterminada de la JVM.

Para deshabilitar SSLv2 y SSLv3 y permitir únicamente TLSv1.2 (disponible a partir de JDK 7 y superior), se configuraría el conector de la siguiente manera:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1.2" />

Si se desea habilitar TLSv1.1 y TLSv1.2, y permitir TLSv1.0 para compatibilidad hacia atrás, se utilizaría:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" />

Esta modificación desactiva las características no seguras de Tomcat, dejando solo HTTPS habilitado.

Utilizando Conectores APR/Native

Con los conectores APR/Native, el protocolo SSL/TLS se configura mediante el atributo SSLProtocol en $TOMCAT_HOME/conf/server.xml.

El valor predeterminado para SSLProtocol suele ser ALL, lo que habilita todos los protocolos. Los valores aceptables incluyen SSLv2, SSLv3, TLSv1 y SSLv2+SSLv3. A partir de la versión 1.1.21 de la biblioteca Tomcat native, se admite cualquier combinación de los tres protocolos concatenados con un signo más (+).

Para deshabilitar SSLv2 y SSLv3 y habilitar solo TLSv1.2, la configuración sería:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" SSLProtocol="TLSv1.2" />

Para una configuración que incluya compatibilidad con versiones anteriores de TLS:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11AprProtocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" SSLProtocol="TLSv1+TLSv1.1+TLSv1.2" />

Es importante recordar que el protocolo SSLv2 es inherentemente inseguro, y SSLv3 es significativamente menos seguro que su sucesor TLS.

Configuración de Certificados SSL/TLS

Además de configurar los protocolos, es necesario contar con certificados SSL/TLS para establecer conexiones HTTPS seguras. Tomcat utiliza un archivo de almacén de claves (keystore) para almacenar certificados.

Generación de Certificados Autofirmados

Para entornos de desarrollo o pruebas, se puede generar un certificado autofirmado. Esto permite configurar SSL en Tomcat sin necesidad de obtener un certificado de una Autoridad Certificadora (CA) pública. Sin embargo, los navegadores web mostrarán advertencias de seguridad al acceder a sitios con certificados autofirmados, ya que no son emitidos por una entidad de confianza.

El proceso general implica crear un almacén de claves y generar un certificado dentro de él. Por ejemplo, usando keytool de Java:

keytool -genkeypair -alias tomcat -keyalg RSA -keysize 2048 -validity 365 -keystore tomcat.keystore

Luego, se debe exportar el certificado y configurarlo en server.xml, especificando la ruta al archivo del almacén de claves y su contraseña:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLSv1.2" keystoreFile="/ruta/a/tu/tomcat.keystore" keystorePass="tu_contraseña_del_keystore" />

Es crucial generar un nuevo certificado para cada instancia de Tomcat si se tienen múltiples instancias, para garantizar que si un certificado se ve comprometido, las demás instancias de Tomcat sigan siendo seguras.

Uso de Certificados de Let's Encrypt

Para entornos de producción, se recomienda encarecidamente el uso de certificados emitidos por Autoridades Certificadoras de confianza, como Let's Encrypt. Let's Encrypt ofrece certificados SSL/TLS gratuitos y automatizados para dominios específicos.

El proceso implica obtener un certificado para tu dominio utilizando herramientas como Certbot. Una vez que tienes los archivos del certificado (por ejemplo, fullchain.pem y privkey.pem), necesitas combinarlos en un formato compatible con Tomcat, como un archivo PKCS12 (.pfx o .keystore).

openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out tomcat.pfx -name tomcat

Luego, se configura Tomcat para usar este archivo PKCS12 en server.xml:

<Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLSv1.2" keystoreFile="/ruta/a/tu/tomcat.pfx" keystorePass="tu_contraseña_del_pfx" />

Consideraciones Adicionales

• Puertos: Si se encuentra con el mensaje de advertencia "¡Utilizando conexión no cifrada!" o el error "¡Utilizando conexión no cifrada! Por favor, configure el servidor web para utilizar HTTPS", esto indica que se está accediendo a través de HTTP (generalmente puerto 80 o 8080) en lugar de HTTPS. Para impedir el acceso por el puerto 8080 y forzar el uso de HTTPS, se pueden realizar ajustes en el archivo server.xml y, si se utiliza Alfresco, modificar archivos de configuración específicos. La redirección del puerto 8080 al 8443 (puerto HTTPS) o el uso del protocolo AJP (puerto 8009) a través de un proxy inverso como Apache HTTP Server son estrategias comunes.

• SELinux: En sistemas que utilizan SELinux (como algunas distribuciones de Red Hat), es posible que necesite deshabilitar SELinux temporalmente o configurar las políticas adecuadas para permitir que Tomcat acceda a los archivos del almacén de claves. El comando restorecon puede ser útil para restaurar los contextos de seguridad de los archivos.

• Permisos de Puerto: Los puertos por debajo de 1024 (como el puerto 80 para HTTP o 443 para HTTPS) generalmente requieren privilegios de root para ser utilizados. Si Tomcat se ejecuta como un usuario no root, puede ser necesario cambiar la configuración del puerto a un valor superior a 1024 (por ejemplo, 8443 para HTTPS) o utilizar herramientas como stunnel para redirigir el tráfico de un puerto privilegiado a un puerto no privilegiado.

• Actualizaciones de Java: Mantener el JRE actualizado es crucial, ya que las versiones más recientes incluyen parches de seguridad importantes y desactivan por defecto protocolos vulnerables.

Al seguir estos pasos, se puede configurar Apache Tomcat para utilizar protocolos SSL/TLS modernos y seguros, deshabilitando eficazmente las versiones obsoletas como SSLv2 y SSLv3, y fortaleciendo así la seguridad de las comunicaciones.

tags: #como #deshabilito #ssl #2 #y #3