EAP-TLS vs. EAP-TTLS: ¿Qué protocolo WiFi basado en certificados debería elegir?

Resumen Ejecutivo

Elegir el método EAP adecuado para su despliegue 802.1X determina si su WiFi empresarial es verdaderamente segura o meramente conforme sobre el papel. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido en RFC 5216, requiere autenticación mutua mediante certificados: tanto el dispositivo cliente como el servidor RADIUS presentan certificados X.509 válidos antes de que se conceda el acceso a la red. En ningún momento se intercambian contraseñas. EAP-TTLS (Tunneled Transport Layer Security), definido en RFC 5281, requiere únicamente un certificado en el lado del servidor para establecer un túnel TLS cifrado, dentro del cual el cliente se autentica utilizando las credenciales de directorio existentes.

Para los CTO y arquitectos de red que gestionan la infraestructura en cadenas de retail, establecimientos de hostelería y organizaciones del sector público, esta decisión se reduce a una sola pregunta: ¿gestiona usted los dispositivos? Si controla la flota de dispositivos a través de un MDM, EAP-TLS es la opción definitiva. Si da soporte a un entorno BYOD diverso o carece de una infraestructura de clave pública (PKI) robusta, EAP-TTLS proporciona una alternativa práctica y altamente segura. Purple admite ambas vías de autenticación para el WiFi del personal a través de más de 80.000 puntos activos.

Análisis Técnico Detallado

Arquitectura de EAP-TLS

EAP-TLS opera bajo un modelo de autenticación mutua dentro del marco de control de acceso basado en puertos IEEE 802.1X. Cada intercambio de autenticación involucra tres componentes principales: el suplicante (dispositivo cliente), el autenticador (punto de acceso inalámbrico) y el servidor de autenticación (servidor RADIUS). El punto de acceso no toma la decisión de autenticación por sí mismo. Actúa como un relé transparente, encapsulando los mensajes EAP en paquetes RADIUS y reenviándolos al servidor de autenticación. El protocolo de enlace EAP-TLS se realiza de la siguiente manera. El punto de acceso envía un EAP-Request/Identity al dispositivo que se conecta. El dispositivo responde con su identidad. El servidor RADIUS inicia el protocolo de enlace TLS con un mensaje EAP-TLS/Start. El cliente envía un ClientHello, anunciando los conjuntos de cifrado TLS que admite. El servidor RADIUS responde con un ServerHello, su certificado de servidor X.509 y una solicitud de certificado. El cliente valida el certificado del servidor comparándolo con su almacén de CA raíz de confianza. Si la validación falla, el protocolo de enlace finaliza, proporcionando protección contra puntos de acceso no autorizados. A continuación, el cliente presenta su propio certificado X.509. El servidor RADIUS valida el certificado del cliente, verificando la cadena de firma hasta la CA raíz de confianza, comprobando que el certificado no haya caducado y consultando la lista de revocación de certificados (CRL) o mediante OCSP. El túnel TLS se establece y se concede el acceso a la red únicamente cuando ambas partes están conformes.

Dado que no se intercambian contraseñas, EAP-TLS es seguro frente a ataques de diccionario sin conexión, relleno de credenciales (credential stuffing) y phishing. Es el único método EAP que cumple con los requisitos de WPA3-Enterprise de 192 bits (Suite B), y está recomendado u ordenado de forma estricta por PCI-DSS 4.0 para entornos de datos de titulares de tarjetas y por NIST SP 800-120 para despliegues de WiFi de alta seguridad.

EAP-TLS requiere una PKI. Se necesita al menos una CA raíz sin conexión y una CA emisora en línea. La CA raíz debe estar aislada físicamente (air-gapped), ya que su clave privada es el ancla de confianza maestra para toda la jerarquía de certificados. La CA emisora se encarga de la emisión diaria de certificados y de publicar las CRL. Los certificados de cliente se emiten para dispositivos individuales, no para usuarios; se trata de un modelo de identidad de dispositivo. Esta distinción es fundamental para dispositivos IoT, terminales compartidos y sistemas sin cabezal (headless).

Estructura de EAP-TTLS

EAP-TTLS se diseñó para proporcionar una seguridad robusta de 802.1X sin la carga operativa de tener que implementar certificados en cada dispositivo cliente. Funciona en dos fases. En la primera fase, el servidor RADIUS presenta su certificado y establece un túnel TLS seguro. Solo el servidor requiere un certificado. En la segunda fase, el cliente se autoriza dentro de ese túnel cifrado utilizando un método de autenticación interno. Los métodos internos comunes incluyen PAP (Password Authentication Protocol), CHAP y MS-CHAPv2. El cliente envía su nombre de usuario y contraseña, pero dado que este intercambio ocurre dentro del túnel TLS, las credenciales se cifran en tránsito y nunca quedan expuestas en el aire.

EAP-TTLS proporciona un excelente soporte multiplataforma en macOS, Linux, Android e iOS. La advertencia es con Windows: el suplicante integrado de Windows no admite de forma nativa EAP-TTLS para WiFi 802.1X de forma predeterminada. Los entornos con un gran volumen de dispositivos Windows pueden requerir un suplicante de terceros, lo que aumenta la complejidad operativa. Para entornos centrados en Windows, PEAP con MS-CHAPv2 suele ser la opción más pragmática.La mayor limitación de EAP-TTLS es que no elimina los riesgos inherentes de las contraseñas. Si un usuario elige una contraseña débil, esta sigue siendo vulnerable a ataques de fuerza bruta fuera de línea. Si la autenticación interna utiliza PAP, la contraseña se envía en texto plano dentro del túnel, lo cual es aceptable si confía en su infraestructura RADIUS, pero sigue siendo un modelo de confianza esencial que debe comprender.

Comparación Directa

Guía de Implementación

Despliegue de EAP-TLS para Flotas Gestionadas

El despliegue de EAP-TLS requiere una PKI funcional y una plataforma de MDM. La instalación manual de certificados no es viable a escala empresarial. Debe integrar su PKI con su MDM utilizando SCEP (Simple Certificate Enrolment Protocol) o EST (Enrolment over Secure Transport). Cuando se registra un dispositivo corporativo, este solicita y recibe automáticamente su certificado sin intervención del usuario.

Para la gestión de identidades, Purple actúa como un proveedor de identidad gratuito para servicios como OpenRoaming bajo la licencia Connect, facilitando un roaming seguro en diferentes ubicaciones mediante marcos de identidad y certificados subyacentes.

En el lado de RADIUS, configure su servidor para validar los certificados de cliente contra su CA interna y verifique las CRL o utilice OCSP para la verificación de revocación en tiempo real. Las plataformas RADIUS soportadas incluyen FreeRADIUS, Microsoft NPS y Cisco ISE. La capa de nube de Purple se integra con hardware de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet.

Despliegue de EAP-TTLS para Entornos Mixtos

EAP-TTLS es la opción óptima para entornos con dispositivos no gestionados. Solo necesita desplegar un certificado de confianza en su servidor RADIUS. Asegúrese de que su servidor RADIUS se integre directamente con su servicio de directorio - Microsoft Entra ID, Okta o Google Workspace - para validar las credenciales de autenticación interna. Configure sus perfiles de WiFi desplegados por MDM para exigir la validación del certificado del servidor frente a su CA de confianza específica. Sin este paso, el túnel TLS no ofrece protección contra puntos de acceso no autorizados.

Mejores prácticas

Forzar la validación del certificado de servidor en cada cliente

El paso de configuración más crítico tanto para EAP-TLS como para EAP-TTLS es forzar la validación del certificado de servidor en los dispositivos cliente. Si un dispositivo no valida el certificado del servidor RADIUS frente a una CA de confianza específica, se conectará a cualquier servidor que presente cualquier certificado - incluyendo un punto de acceso no autorizado. Especifique siempre la CA de confianza y el nombre de servidor esperado en sus perfiles WiFi implantados mediante MDM. Esta única comprobación de configuración es la mejora de seguridad más eficaz que puede implementar hoy en día.

Automatizar la gestión del ciclo de vida de los certificados

Los certificados caducan. Si no dispone de un proceso de renovación automatizado, se enfrentará a fallos masivos de autenticación cuando los certificados caduquen simultáneamente. Utilice SCEP o EST para automatizar las renovaciones y configure alertas de monitorización con suficiente antelación a las fechas de caducidad. Si se pierde un dispositivo o un empleado se marcha, revoque el certificado inmediatamente. Configure su servidor RADIUS para comprobar las CRL o utilice OCSP para la validación en tiempo real.

Segmentar la red por método de autenticación

En entornos grandes o distribuidos, considere la posibilidad de ejecutar ambos protocolos en SSIDs independientes. Los dispositivos corporativos gestionados se autentican mediante EAP-TLS en un SSID dedicado para el WiFi del personal. Los contratistas y los dispositivos BYOD se autentican mediante EAP-TTLS en un SSID independiente con la segmentación de VLAN adecuada. Este patrón es común en grupos hoteleros como Premier Inn y Whitbread, donde los dispositivos del personal están gestionados y se les emiten certificados, mientras que la infraestructura de invitados utiliza una ruta de autenticación independiente. Para obtener más detalles sobre la arquitectura de SSID, consulte nuestra guía Tres SSIDs para gobernarlos a todos: el diseño de WiFi para invitados, personal e IoT .

Sincronizar la hora en toda la infraestructura

La validación de certificados depende de una hora de sistema precisa. El desvío de la hora en los dispositivos cliente o en los servidores RADIUS genera errores de certificado "aún no válido" o "caducado" que son difíciles de diagnosticar. Asegúrese de que todos los componentes de la infraestructura estén sincronizados con servidores NTP fiables.

Resolución de problemas y mitigación de riesgos

Errores de CA desconocida

Si los registros de RADIUS muestran "CA desconocida", el dispositivo cliente no confía en la CA que emitió el certificado del servidor RADIUS. Verifique que su perfil de MDM incluya el certificado de la CA raíz y que el suplicante esté configurado para confiar en él. Tras una rotación de CA o una renovación de certificados, vuelva a enviar el paquete de CA actualizado a todos los dispositivos.

Incompatibilidad de método EAP

Si los dispositivos se conectan al punto de acceso pero la autenticación falla, verifique que el método EAP configurado en el cliente coincida con el método aceptado por el servidor RADIUS. Un perfil de dispositivo configurado para EAP-TLS fallará en un servidor RADIUS configurado únicamente para PEAP.

Fallos masivos debido a certificados caducados

Si un gran número de dispositivos no logra autenticarse simultáneamente, compruebe primero las fechas de caducidad de los certificados. Esta es la causa más común de fallos masivos de 802.1X en despliegues EAP-TLS. Implemente un sistema de monitorización que envíe alertas 60 días, 30 días y siete días antes de la caducidad.

Configuración incorrecta del cliente RADIUS

Cada punto de acceso o controlador inalámbrico debe definirse como un cliente RADIUS con la dirección IP y el secreto compartido correctos. Las discrepancias causan tiempos de espera de autenticación que a menudo se atribuyen incorrectamente al método EAP. Active el registro detallado de RADIUS desde el primer día. Para obtener más orientación sobre la resolución de problemas de WiFi, consulte nuestra guía Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures .

Cumplimiento y alineación regulatoria

Para los CISO y arquitectos de red, comprender el panorama regulatorio es esencial al decidir entre EAP-TLS y EAP-TTLS. La elección del método EAP afecta directamente a su estado de cumplimiento en varios marcos clave.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) requiere una autenticación criptográfica sólida para las redes inalámbricas en entornos de datos de titulares de tarjetas. El requisito 8.3 exige la autenticación multifactor para todo acceso al CDE, y las redes inalámbricas dentro del alcance deben utilizar mecanismos de autenticación sólidos. EAP-TLS, con autenticación mutua basada en certificados, cumple definitivamente con este requisito. EAP-TTLS con MS-CHAPv2 es aceptable si la autenticación interna está debidamente protegida y se aplica la validación del certificado del servidor, pero EAP-TLS es la opción más sólida y preferida por los auditores. HIPAA (Health Insurance Portability and Accountability Act) exige a las entidades cubiertas que implementen salvaguardas técnicas que protejan la información médica protegida electrónica (ePHI) transmitida a través de redes de comunicaciones electrónicas. La norma de seguridad HIPAA no impone protocolos específicos, pero la expectativa de cifrado y control de acceso para las redes inalámbricas que transportan ePHI se inclina fuertemente a favor de EAP-TLS para flotas de dispositivos médicos gestionados y de EAP-TTLS con validación obligatoria de certificados de servidor para dispositivos del personal. WPA3-Enterprise 192-bit (también conocido como Suite B o modo CNSA) es el nivel de seguridad más alto de la certificación WPA3 de la Wi-Fi Alliance. Exige EAP-TLS como único método de autenticación permitido, requiere TLS 1.2 o superior con suites de cifrado específicas (ECDHE con P-384, AES-256-GCM) y requiere certificados ECDSA o RSA-3072. Las organizaciones que despliegan WPA3-Enterprise 192-bit para aplicaciones gubernamentales, de defensa o de infraestructuras críticas deben utilizar EAP-TLS. ISO 27001 no exige protocolos específicos, pero requiere que las organizaciones implementen controles de acceso adecuados para los recursos de red. Un despliegue de 802.1X con EAP-TLS o EAP-TTLS (con validación forzada del certificado del servidor) cumple los requisitos de control de acceso a la red de los Anexos A.9.1 y A.13.1.

-

ROI e impacto empresarial

La migración a EAP-TLS requiere una inversión inicial en la integración de PKI y MDM, pero elimina los costes operativos de los restablecimientos de contraseñas y el riesgo financiero de las violaciones de red debidas a credenciales comprometidas. Para una cadena minorista con 400 tiendas, una sola contraseña comprometida en una red PSK compartida puede poner en peligro todo el negocio. EAP-TLS elimina por completo ese vector de ataque.

Para entornos multi-inquilino y centros de transporte, la autenticación segura garantiza que solo los usuarios autorizados accedan al ancho de banda de la red, optimizando así la utilización de la infraestructura. La asignación dinámica de VLAN a través de los atributos de certificado RADIUS permite una segmentación de red reforzada criptográficamente, lo que garantiza que los dispositivos se ubiquen en el segmento de red correcto en función de las propiedades del certificado, en lugar de depender de la selección de SSID o del filtrado de direcciones MAC.

La plataforma de WiFi Analytics de Purple se integra con ambas rutas de autenticación, proporcionando visibilidad sobre el número de dispositivos, la duración de las sesiones y la utilización de la red en todas sus instalaciones. Para obtener una guía de despliegue específica para su sector, explore nuestros recursos para Hospitality , Retail , Healthcare y Transport .