SSTP y SSL 3.0: la etiqueta frente a la versión negociada

Dos personas pueden mirar el mismo despliegue de SSTP y llegar a conclusiones opuestas. Una lee la documentación del producto, ve las letras SSL y supone que el túnel ejecuta un protocolo retirado hace años. La otra señala una negociación TLS moderna y concluye que la cuestión está cerrada. Ambas discuten desde etiquetas y no desde la versión negociada, y solo una de esas cosas es una prueba. La comparación que merece la pena es la que hay entre lo que promete el nombre y lo que el servicio selecciona realmente.

Dos respuestas a la misma pregunta

El argumento de la etiqueta es fácil de enunciar: SSTP se describe como un protocolo de túnel de sockets seguro, el nombre histórico dice SSL, por lo tanto la conexión debe ser SSL 3.0. Sobrevive porque el nombre sí procede de ese linaje y porque la mayoría de quien lo repite nunca ha mirado una negociación. También sobrevive porque la conclusión suena prudente, como si suponer lo peor fuera la opción segura. Suponer lo peor y medir la versión real son actividades distintas, y solo una de ellas cambia algo.

El argumento de la prueba plantea una pregunta más estrecha. ¿En qué versión de protocolo se pusieron de acuerdo este cliente y este servidor, en este extremo, en este momento? La respuesta viene del servicio que termina TLS, no de una página de marketing ni de un navegador que llegó a un sitio de nombre parecido.

Los dos argumentos difieren en lo que pueden demostrar. La etiqueta no distingue un despliegue antiguo de uno corregido, y la negociación no puede decirle qué hace un servicio ajeno en el mismo host. Use la segunda y deje de usar la primera.

Lea la versión que el servicio selecciona realmente

Empiece por nombrar los componentes: la implementación cliente, la implementación servidor, el extremo TLS y todo lo que haya en medio y termine y restablezca TLS. Un balanceador de carga que termina TLS y habla HTTP simple con el backend cambia de qué dispositivo debe leer la política.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Anote el extremo y la hora junto al resultado, porque un cambio posterior de la política hace inútil una observación sin fecha. Repita la sonda desde un cliente en la misma ruta de red que los usuarios que le importan, ya que un dispositivo de interceptación puede terminar TLS con sus propios ajustes. Si las dos posiciones no coinciden, ha encontrado el componente que importa. Si coinciden, tiene una prueba en lugar de un eslogan.

Separe el campo de registro de la negociación

Un número de versión de aspecto antiguo en un campo no es el mismo hecho que una sesión SSL 3.0. RFC 7568 trata la versión de la capa de registro y el protocolo negociado como asuntos distintos, y de esa distinción vienen exactamente las respuestas falsas y seguras. Lea el protocolo negociado, luego el cifrado y solo entonces saque una conclusión sobre la sesión.

El mismo documento es inequívoco sobre el protocolo en sí: no debe usarse SSL 3.0, y se prohíbe la negociación o la caída a él. La razón es la construcción CBC defectuosa que explotó el ataque POODLE, que es una propiedad del protocolo y no la configuración de una aplicación.

Por eso «esta carga de trabajo probablemente sea difícil de explotar» no es un argumento para mantener SSL 3.0 habilitado. El requisito es eliminar el protocolo, no ganar un debate sobre una demostración.

Retire SSL 3.0 con una política que pueda sostener

En Windows, los ajustes de protocolo de Schannel están bajo la clave Protocols y se leen por rol de cliente y de servidor, por lo que un cambio que corrige una dirección puede dejar la otra intacta. Microsoft documenta los ajustes actuales y sus requisitos de reinicio, y una biblioteca TLS de terceros en el mismo host los ignora por completo.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Cambie la política por la vía de administración admitida, confirme que el servicio propietario vuelve a obtener su configuración y conserve una forma aprobada de revertir. Pegar un script de registro amplio de otro entorno es cómo la corrección de un servicio se convierte en una caída para todos los clientes TLS de la máquina. El alcance del reinicio importa aquí: un ajuste que parece aplicado puede seguir en memoria de un servicio que no lo ha recargado.

Un par que aún exige una versión obsoleta necesita una actualización o un plan de migración. Una excepción no documentada que restaura el protocolo antiguo en silencio no es una estrategia de compatibilidad y no sobrevivirá a la próxima auditoría.

Acepte el cambio con conexiones nuevas

Pruebe con sesiones nuevas después del cambio de política, porque una conexión establecida antes del cambio no demuestra nada sobre la configuración vigente ahora. Confirme que el protocolo aprobado funciona y que el prohibido falla mediante el proceso de validación autorizado, y luego deje la identidad del certificado y las comprobaciones de confianza exactamente como estaban.

Recuerde lo que la negociación no cubre. SSTP transporta autenticación PPP después de la capa TLS, así que una versión de protocolo moderna no dice nada sobre qué usuario fue autorizado ni a qué recursos puede llegar la sesión. Son controles separados con pruebas separadas.

Escriba el resultado como servicio, backend, política permitida y versión observada. Ese registro responde con precisión a la pregunta de seguridad, algo que ni el argumento de la etiqueta ni el de la incomodidad logran nunca.