¿Cómo desactivar los protocolos TLS antiguos en una configuración HTTPS conforme?

Una configuración HTTPS conforme suele deshabilitar TLS 1.0, TLS 1.1 y las versiones anteriores del protocolo SSL, mantener TLS 1.2 y habilitar TLS 1.3 cuando sea compatible con el servidor. Sin embargo, el cumplimiento también depende de la línea base de seguridad aplicable, las suites de cifrado, los certificados y el alcance efectivo de la configuración; no puede determinarse únicamente por la versión del protocolo.

Antes de actuar, confirme dónde termina exactamente la conexión TLS del navegador. Si el sitio utiliza una CDN, un WAF o un balanceador de carga, modificar solo la configuración del servidor de origen puede dejar los protocolos antiguos habilitados en el punto de entrada público.

Identifique todos los puntos de entrada HTTPS que debe modificar

Los sitios web corporativos de comercio exterior, las tiendas transfronterizas y las páginas de destino publicitarias suelen utilizar una ruta de acceso del tipo «visitante—CDN/WAF—balanceador de carga—servidor de origen». Cada conexión TLS establecida de forma independiente tiene su propia configuración de protocolo. Si un dispositivo intermedio solo retransmite el tráfico, la configuración la controla el componente de backend que termina realmente la conexión TLS.

Se recomienda revisar los puntos de entrada por dominio y puerto de escucha, en lugar de limitarse a contar los servidores:

• Puntos de entrada públicos: dominio principal, subdominio www, sitios multilingües, tienda en línea, API y páginas de destino publicitarias.
• Conexiones con el servidor de origen: conexiones HTTPS entre la CDN y el balanceador de carga, y entre el proxy inverso y los servicios de la aplicación.
• Puntos de entrada alternativos: direcciones del servidor de origen accesibles directamente, dominios de respaldo, puntos de acceso de administración y otros puertos HTTPS.

La opción «versión mínima de TLS» de la CDN suele controlar la conexión de los visitantes; el protocolo de conexión con el servidor de origen debe configurarse por separado. Si esta conexión sigue usando HTTP, superar una prueba pública no permite concluir que toda la ruta esté cifrada.

Especifique qué protocolos se permiten en la configuración

En lugar de excluir las versiones antiguas una por una, resulta más claro especificar explícitamente los protocolos permitidos. Antes de configurar, confirme que el servidor web y la biblioteca TLS vinculada sean compatibles con las versiones previstas. Incluir TLS 1.3 en el archivo de configuración no significa que el entorno actual pueda ofrecerlo.

Ejemplo de configuración de Nginx

Establezca la siguiente directiva en el contexto de configuración adecuado:

ssl_protocols TLSv1.2 TLSv1.3;

Si todos los sitios deben seguir la misma política, puede gestionarla de forma centralizada en el nivel http y comprobar si algún bloque server sobrescribe la configuración. Cuando varios hosts virtuales HTTPS comparten la misma dirección y puerto, revise también el host virtual predeterminado: la negociación del protocolo puede verse afectada por la configuración del servidor predeterminado, por lo que no basta con modificar el bloque correspondiente al dominio deseado.

Después de guardar los cambios, compruebe primero la sintaxis y, a continuación, vuelva a cargar el servicio:

nginx -t
nginx -s reload

Ejecute la recarga solo si la comprobación de sintaxis se completa correctamente. En contenedores, clústeres o entornos alojados, actualice la configuración mediante el mecanismo de implementación correspondiente y asegúrese de que todas las instancias utilicen la misma configuración, para evitar que algunas solicitudes sigan llegando a nodos con la configuración anterior.

Cómo configurar Apache y las plataformas alojadas

En Apache, la directiva SSLProtocol permite limitar los protocolos. Por ejemplo, en un entorno compatible con las versiones correspondientes, puede utilizarse:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Revise también la configuración global, la de los hosts virtuales y sus relaciones de herencia. Si utiliza una CDN, un balanceador de carga en la nube o una plataforma SaaS de creación de sitios web, ajuste la versión mínima en la consola que gestiona realmente TLS y confirme por separado la conexión de los visitantes y la conexión con el servidor de origen.

En escenarios de uso de plataformas integrales de creación de sitios y servicios de marketing como 易营宝, distintos responsables pueden gestionar las páginas del sitio, los dominios de marketing, la CDN y el servidor de origen. Antes de implementar los cambios, defina quién es responsable de la configuración de cada punto de entrada y cómo se verificará. No dé por hecho que «la plataforma ya ha instalado el certificado» significa que «se han deshabilitado los protocolos antiguos en todos los puntos de entrada».

La verificación debe demostrar tanto el rechazo de las versiones antiguas como la disponibilidad de las actuales

Que un sitio se abra en el navegador solo indica que se ha negociado correctamente algún protocolo; no demuestra que se hayan deshabilitado las versiones antiguas. Inicie conexiones de prueba con versiones específicas para el mismo dominio:

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Sustituya el dominio de ejemplo por el dominio real. Se espera que TLS 1.0 y TLS 1.1 no puedan completar la conexión, mientras que TLS 1.2 funcione correctamente. Si se prevé ofrecer TLS 1.3, también debe verificarse que la conexión se establezca correctamente. -servername permite enviar el SNI y evita que la solicitud llegue a un host virtual equivocado.

Un error en una prueba con un protocolo antiguo no significa necesariamente que el servidor lo haya rechazado. Es posible que la versión local de OpenSSL ya tenga deshabilitados los protocolos antiguos o que no disponga de suites de cifrado antiguas compatibles. Si el cliente falla antes de enviar la solicitud de conexión, el resultado no demuestra que el servidor haya deshabilitado el protocolo. Analice el mensaje de error y realice una verificación cruzada con herramientas de análisis TLS que permitan sondear las versiones correspondientes.

Compruebe por separado el dominio público y el servidor de origen. Para conectarse directamente al servidor de origen, cambie -connect por la IP del servidor y siga especificando el dominio mediante -servername. Incluya también IPv4, IPv6, los puntos de entrada alternativos y los distintos nodos de implementación. Registre la hora de la prueba, la dirección de destino y el resultado de la negociación para facilitar la aceptación y la resolución de problemas posterior.

Confirme la compatibilidad en toda la ruta de servicio

Es posible que los sistemas operativos antiguos, los dispositivos integrados o los clientes de API que lleven mucho tiempo sin actualizarse no puedan conectarse tras el cambio. Antes de la puesta en producción, identifique las dependencias mediante los registros de conexión, el inventario de consumidores y las pruebas funcionales. Preste especial atención al envío de consultas, las redirecciones de pago, las notificaciones de pedidos, las interfaces de datos de marketing y las tareas de sincronización con terceros.

Priorice la actualización del cliente, el entorno de ejecución o el componente de interfaz para resolver los problemas de compatibilidad. Si realmente se necesita un periodo de transición, evalúe el uso de un punto de entrada específico y aislado, limite su alcance de acceso y establezca una fecha de retirada. No vuelva a habilitar los protocolos antiguos en todo el sitio principal por un único consumidor antiguo. Durante el despliegue gradual, supervise los errores de conexión, los fallos de notificación y los resultados de los formularios clave: que la página se abra no significa que las operaciones comerciales o la captación de clientes funcionen correctamente.

Deshabilitar las versiones antiguas de TLS no cubre todo el trabajo relacionado con HTTPS. También es necesario revisar las suites de cifrado de TLS 1.2 y gestionar por separado la cadena de certificados, la correspondencia de dominios, las renovaciones y el contenido mixto. Las redirecciones HTTP y HSTS cumplen funciones distintas y no sustituyen la restricción de protocolos. Al finalizar, conserve el inventario de puntos de entrada, la configuración aplicada y los registros de verificación. Compruebe los nuevos dominios de marketing y las migraciones de CDN con la misma línea base.