EAP-TLS vs EAP-TTLS: ¿Qué protocolo de 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 simplemente cumple sobre el papel. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido en el 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 el 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 infraestructuras en cadenas de tiendas, establecimientos de hostelería y organizaciones del sector público, esta decisión se reduce a una pregunta: ¿gestiona usted los dispositivos? Si controla la flota de dispositivos a través de un MDM, EAP-TLS es la elección definitiva. Si da soporte a un entorno BYOD diverso o carece de una infraestructura de clave pública (PKI) robusta, EAP-TTLS ofrece una alternativa pragmática y muy segura. Purple admite ambas vías de autenticación para Staff WiFi en más de 80.000 espacios activos.

Análisis Técnico Detallado

Arquitectura de EAP-TLS

EAP-TLS funciona 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 intercambio 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 intercambio 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 con su almacén de CA raíz de confianza. Si la validación falla, el intercambio 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, comprobando la cadena de firmas hasta la CA raíz de confianza, verificando que el certificado no haya caducado y comprobando la lista de revocación de certificados (CRL) o consultando el OCSP. El túnel TLS se establece y se concede el acceso a la red solo cuando ambas partes están conformes.

Dado que no se intercambian contraseñas, EAP-TLS es seguro frente a ataques de diccionario offline, relleno de credenciales y phishing. Es el único método EAP que cumple con los requisitos de WPA3-Enterprise de 192 bits (Suite B), y está recomendado encarecidamente u obligado 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. Necesita al menos una CA raíz offline y una CA emisora online. La CA raíz debe estar aislada físicamente, 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 publica las CRL. Los certificados de cliente se emiten para dispositivos individuales, no para usuarios; este es un modelo de identidad de dispositivo. Esta distinción es fundamental para los dispositivos IoT, los terminales compartidos y los sistemas sin cabezal.

Estructura de EAP-TTLS

EAP-TTLS se diseñó para proporcionar una seguridad 802.1X sólida sin la carga operativa de desplegar 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 (protocolo de autenticación de contraseña), CHAP y MS-CHAPv2. El cliente envía su nombre de usuario y contraseña, pero debido a que este intercambio se produce dentro del túnel TLS, las credenciales se cifran en tránsito y nunca se exponen por 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 802.1X inalámbrico de serie. 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 práctica.

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 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 un dispositivo corporativo se registra, 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 identidades gratuito para servicios como OpenRoaming bajo la licencia Connect, facilitando el roaming seguro a través de diferentes ubicaciones utilizando marcos subyacentes de certificados e identidad.

En el lado de RADIUS, configure su servidor para validar los certificados de cliente contra su CA interna y verificar las CRL o utilizar OCSP para la verificación de revocación en tiempo real. Las plataformas RADIUS soportadas incluyen FreeRADIUS, Microsoft NPS y Cisco ISE. La superposición en la nube de Purple se integra con el 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 aplicar la validación del certificado del servidor contra su CA de confianza específica. Sin este paso, el túnel TLS no ofrece protección contra puntos de acceso no autorizados.

Prácticas recomendadas

Forzar la validación de certificados 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 del servidor en los dispositivos de los clientes. 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, incluido un punto de acceso malicioso. Especifique siempre la CA de confianza y el nombre de servidor esperado en sus perfiles de WiFi implementados a través de 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 de autenticación masivos cuando los certificados caduquen simultáneamente. Utilice SCEP o EST para automatizar las renovaciones y configure alertas de supervisió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 SSID independientes. Los dispositivos corporativos gestionados se autentican a través de EAP-TLS en un SSID WiFi dedicado para el personal. Los contratistas y los dispositivos BYOD se autentican a través de EAP-TTLS en un SSID independiente con la segmentación de VLAN adecuada. Este patrón es común en grupos de hostelería 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 SSID 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 del sistema precisa. El desfase horario en los dispositivos clientes 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.

Disparidad de métodos EAP

Si los dispositivos se conectan al punto de acceso pero falla la autenticación, compruebe 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 se autentica de forma simultánea, 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 provocan tiempos de espera de autenticación que a menudo se atribuyen de forma incorrecta al método EAP. Active el registro RADIUS detallado desde el primer día. Para obtener más informació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 normativo es esencial a la hora de decidir entre EAP-TLS y EAP-TTLS. La elección del método EAP afecta directamente a su postura de cumplimiento en varios marcos clave.

PCI-DSS 4.0 (estándar de seguridad de datos de la industria de tarjetas de pago) requiere una autenticación criptográfica sólida para redes inalámbricas en entornos de datos de titulares de tarjetas. El requisito 8.3 exige la autenticación multifactor para todos los accesos 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 este requisito. EAP-TTLS con MS-CHAPv2 es aceptable si la autenticación interna está protegida adecuadamente y se aplica la validación del certificado del servidor, pero EAP-TLS es la opción más sólida y sencilla de cara a las auditorías. HIPAA (ley de portabilidad y responsabilidad de seguros de salud) exige que las entidades cubiertas implementen salvaguardas técnicas que protejan la información de salud 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 los dispositivos del personal.

WPA3-Enterprise de 192 bits (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 el único método de autenticación permitido, requiere TLS 1.2 o superior con conjuntos de cifrado específicos (ECDHE con P-384, AES-256-GCM) y requiere certificados ECDSA o RSA-3072. Las organizaciones que desplieguen WPA3-Enterprise de 192 bits para aplicaciones gubernamentales, de defensa o de infraestructuras críticas deben utilizar EAP-TLS. ISO 27001 no impone protocolos específicos, pero exige que las organizaciones implementen controles de acceso adecuados para los recursos de red. Un despliegue de 802.1X con EAP-TLS o bien EAP-TTLS (con validación obligatoria del certificado del servidor) cumple con los requisitos de control de acceso a la red del Anexo 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 seguridad de la red debido a credenciales comprometidas. Para una cadena de tiendas con 400 establecimientos, una única contraseña comprometida en una red PSK compartida puede poner en peligro todo el patrimonio. EAP-TLS elimina por completo ese vector de ataque.

Para entornos multi-inquilino y nodos 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 mediante 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 WiFi Analytics de Purple se integra con ambas vías de autenticación, proporcionando visibilidad sobre el recuento de dispositivos, la duración de las sesiones y la utilización de la red en todo su patrimonio. Para obtener orientación sobre despliegues específicos de cada sector, explore nuestros recursos para Hospitality, Retail, Healthcare y Transport.