Si tu herramienta de captura de paquetes denuncia «TLS 1.0» cuando tu servidor está configurado para negociar solo TLS 1.2 y 1.3, probablemente no estás ante un fallo de Windows Server 2025, sino ante una interpretación engañosa de Wireshark. A continuación verás por qué ocurre y cómo confirmarlo.
Contexto de la confusión
Durante una prueba de hardening, un desarrollador detectó que, al invocar ldapsslinit y posteriormente ldapconnect desde Windows Server 2025 Standard (24H2), Wireshark mostraba un registro Client Hello etiquetado como TLS 1.0
. Dado que la máquina tenía TLS 1.0 y 1.1 deshabilitados por directiva y registro, la alerta resultaba alarmante. En Windows 11, la misma operación aparecía como TLS 1.2, lo que reforzaba la sospecha de un “retroceso” de versión en el servidor.
Por qué Wireshark puede mostrar “TLS 1.0” siendo realmente TLS 1.2/1.3
Las versiones modernas de Windows emplean la pila SChannel, que en Windows Server 2025 negocia TLS 1.2 y 1.3 de manera predeterminada. Sin embargo, Wireshark deduce la versión principalmente del primer byte del Client Hello Legacy Version y de ciertos valores de compatibilidad mantendidos por el estándar (la mayor parte de los clientes envían todavía 0x0301, correspondiente a TLS 1.0, como “número señuelo” para no romper infraestructura antigua). La versión real se declara después dentro de la extensión supported_versions.
Por compatibilidad, SChannel conserva ese valor legado y, salvo que analices el campo correcto de la extensión, Wireshark seguirá poniendo “TLS 1.0”. Si expandes el paquete y revisas el apartado Supported Versions, verás que incluye 0x0304 (TLS 1.3) y 0x0303 (TLS 1.2), lo que demuestra que la oferta real es la que esperas. Cuando el servidor responde, observarás la negociación final con TLS 1.2 o 1.3.
Cómo verificar la versión de TLS de forma inequívoca
- Actualiza Wireshark. Las versiones más recientes resaltan explícitamente el campo supported_versions en el árbol de análisis.
- Expande el paquete Client Hello y revisa:
- Record Layer Version (puede ser 0x0301 por compatibilidad).
- Handshake Protocol Version.
- Extension: supported_versions → Client’s Supported Versions List.
- Confirma desde el lado del servidor. En un controlador de dominio Windows o servidor LDAP, los Event IDs de SChannel reflejan la versión de TLS negociada; también muchos directorios LDAP de terceros escriben la versión en su propio log.
Registro y directivas: valores predeterminados en Windows Server 2025
Microsoft ha endurecido la configuración base de TLS en esta versión, dejando deshabilitados TLS 1.0 y TLS 1.1 salvo que el administrador los revele manualmente. No obstante, conviene verificar:
| Zona | Clave/Directiva | Valor esperado | Comentarios |
|---|---|---|---|
| Registro | HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server\Enabled | 0 | 0 = deshabilitado; la subclave puede no existir |
| Registro | HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server\Enabled | 0 | Igual que la anterior |
| GPO | Computer Configuration → Administrative Templates → Network → SSL Configuration Settings → Turn off encryption support | No configurada / Disabled | Permite forzar protocolos concretos; déjala sin definir si tu registro ya bloquea los antiguos |
Análisis paso a paso de un paquete LDAP sobre TLS
- Filtra el tráfico usando
(tcp.port==636) || (tcp.port==389 && ssl)para ver solo LDAPS y StartTLS. - En cada Client Hello, observa:
- Campo Random: útil para correlacionar mensajes.
- Extensión
supported_versions: aquí reside la verdad. - Extensión
signature_algorithms: confirma que no uses suites SHA-1 obsoletas.
- Comprueba el Server Hello y verifica el Cipher Suite elegido (en 2025, SChannel prefiere suites AES‑GCM y ChaCha20‑Poly1305).
- Observa la extensión
key_sharepara validar si se emplea Diffie‑Hellman (TLS 1.3) o ECDHE (TLS 1.2).
¿Qué cambios no solucionan esta falsa alarma?
- Habilitar explícitamente TLS 1.0 en la GPO para “validar” la teoría: no cambia nada, el encabezado legado seguirá diciendo 1.0.
- Borrar y volver a crear claves de registro para TLS 1.0/1.1: perderás tiempo, la pila ya las ignora si no están habilitadas.
- Modificar
LDAPOPTSSLo usarLDAPOPTPROTOCOL_VERSION = 3: son independientes de la versión TLS.
Buenas prácticas al programar conexiones LDAP en C/C++
1. Emplea la inicialización Unicode. Usa ldap_initW en vez de la variante ANSI para evitar problemas de codificación y para acceder a opciones recientes.
2. Deja que SChannel negocie. Evita llamadas a ldapsetoption(…, LDAPOPTSSL, LDAPSSLOFF) salvo para escenarios de depuración. La pila seleccionará por defecto la versión más alta compatible entre cliente y servidor.
3. Configura “server name indication” (SNI) si procede. A partir de Windows Server 2022, la API LDAP troca datos con la pila SChannel usando SNI si añades LDAPOPTHOST_NAME.
4. Valida certificados. Implementa manejo de la llamada CertGetNameString o WinVerifyTrust dentro de un callback si necesitas lógica especial; no deshabilites la validación por comodidad.
Herramientas para doble verificación
- Schannel event logging: activa
340 (0x154)Logging level en SChannel para capturar negociaciones fallidas. - Microsoft Message Analyzer (o Sysmon con regla para protocolo TLS): ofrece vistas alternativas a Wireshark.
- OpenSSL s_client en modo interactivo: permite probar la misma dirección LDAPS; si colapsa por versión, la salida mostrará “wrong version” o “protocol mismatch”.
Auditoría y cumplimiento
Para entornos sujetos a PCI DSS 4.0, HIPAA o ENS Alta, debes documentar la configuración de cada host. Adjunta:
- Captura TLS con el campo supported_versions resaltado.
- Extracto de –
reg querySChannel. - Listado de event IDs 36882, 36884 (conexiones TLS fallidas) y 36874 (exitosas).
Un auditor que conozca la mecánica de TLS entenderá por qué el encabezado legado figura como 1.0, pero agradecerá la evidencia documental.
Preguntas frecuentes
¿Puede inhabilitarse el envío del “legacy version” 0x0301?
No. TLS 1.3 mantiene esa práctica por compatibilidad con middleboxes. Cambiarla rompería clientes y dispositivos antiguos que esperan dicho valor.
¿TLS 1.3 está habilitado en todos los roles de Windows Server 2025?
Sí, pero algunos componentes (por ejemplo, IIS con módulos externos) pueden seguir relegándose a TLS 1.2 hasta que el módulo soporte 1.3. Compruébalo con Get-TlsCipherSuite en PowerShell.
¿Por qué mi controlador de dominio aún muestra suites RSA?
Las conexiones LDAP de máquinas con Windows anteriores a 10 v1909 no soportan ECDHE; para esos clientes SChannel anuncia suites RSA solo en TLS 1.2. Lo correcto es modernizar o limitar el acceso.
Recomendaciones finales
- Confía en los campos Handshake Protocol Version y supported_versions; ignora la etiqueta “TLS 1.0” en la capa de registro.
- Mantén Wireshark actualizado y usa filtros de pantalla personalizados para resaltar la negociación real.
- Evita cambios precipitados en directivas o claves de registro que introduzcan regresiones de compatibilidad.
- Documenta siempre la configuración y la evidencia para tu equipo de seguridad y auditoría.
Conclusión
Lo que parecía un retroceso a TLS 1.0 resultó ser un falso positivo producido por la forma en que Wireshark interpreta la versión “de cortesía” que la especificación TLS mantiene por razones históricas. Windows Server 2025 cumple su promesa de ofrecer TLS 1.2 y 1.3 de forma nativa y deshabilitar los protocolos obsoletos. La lección es clara: antes de lanzar la voz de alarma, inspecciona los detalles del Client Hello y corrobora desde el servidor; el problema probablemente no está en tu sistema, sino en cómo se presenta la información.