EAP-TLS vs EAP-TTLS: Qual Protocolo de WiFi Baseado em Certificados Deve Escolher?

Resumo Executivo

A escolha do método EAP correto para a sua implementação de 802.1X determina se o seu WiFi empresarial é verdadeiramente seguro ou apenas em conformidade no papel. O EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido na RFC 5216, requer autenticação mútua por certificado: tanto o dispositivo cliente como o servidor RADIUS apresentam certificados X.509 válidos antes de ser concedido o acesso à rede. Em momento algum são trocadas palavras-passe. O EAP-TTLS (Tunneled Transport Layer Security), definido na RFC 5281, requer apenas um certificado do lado do servidor para estabelecer um túnel TLS encriptado, dentro do qual o cliente se autentica utilizando as credenciais de diretório existentes.

Para CTOs e arquitetos de rede que gerem infraestruturas em cadeias de retalho, locais de hotelaria e organizações do setor público, esta decisão resume-se a uma pergunta: gere os dispositivos? Se controla a frota de dispositivos através de MDM, o EAP-TLS é a escolha definitiva. Se suporta um ambiente BYOD diversificado ou carece de uma Public Key Infrastructure (PKI) robusta, o EAP-TTLS oferece uma alternativa pragmática e altamente segura. A Purple suporta ambos os caminhos de autenticação para Staff WiFi em mais de 80.000 locais ativos.

Análise Técnica Profunda

Arquitetura do EAP-TLS

O EAP-TLS opera num modelo de autenticação mútua dentro da estrutura de controlo de acesso baseada em portas IEEE 802.1X. Cada troca de autenticação envolve três componentes principais: o suplicante (dispositivo cliente), o autenticador (ponto de acesso sem fios) e o servidor de autenticação (servidor RADIUS). O ponto de acesso não toma a decisão de autenticação por si mesmo. Funciona como um retransmissor transparente, encapsulando mensagens EAP em pacotes RADIUS e encaminhando-as para o servidor de autenticação. O handshake EAP-TLS funciona da seguinte forma. O ponto de acesso envia um EAP-Request/Identity para o dispositivo que se está a ligar. O dispositivo responde com a sua identidade. O servidor RADIUS inicia o handshake TLS com uma mensagem EAP-TLS/Start. O cliente envia um ClientHello, anunciando as cipher suites TLS que suporta. O servidor RADIUS responde com um ServerHello, o seu certificado de servidor X.509 e um pedido de certificado. O cliente valida o certificado do servidor contra a sua lista de ACs raiz fidedignas. Se a validação falhar, o handshake termina - fornecendo proteção contra pontos de acesso falsos. O cliente apresenta então o seu próprio certificado X.509. O servidor RADIUS valida o certificado do cliente, verificando a cadeia de assinaturas até à AC raiz fidedigna, confirmando que o certificado não expirou e consultando a lista de revogação de certificados (CRL) ou efetuando uma consulta OCSP. Apenas quando ambas as partes estiverem satisfeitas é que o túnel TLS é estabelecido e o acesso à rede é concedido.

Como não são partilhadas palavras-passe, o EAP-TLS é imune a ataques de dicionário offline, credential stuffing e phishing. É o único método EAP que cumpre os requisitos WPA3-Enterprise de 192 bits (Suite B), sendo obrigatório ou fortemente recomendado pela PCI-DSS 4.0 para ambientes de dados de titulares de cartões e pela NIST SP 800-120 para implementações sem fios de elevada segurança.

O EAP-TLS requer uma PKI. Precisa, no mínimo, de uma AC raiz offline e de uma AC emissora online. A AC raiz deve estar isolada da rede (air-gapped), uma vez que a sua chave privada é a âncora de confiança mestre para toda a sua hierarquia de certificados. A AC emissora trata da emissão diária de certificados e publica as CRLs. Os certificados de cliente são emitidos para dispositivos individuais e não para utilizadores - este é um modelo de identidade de dispositivo. Esta distinção é crítica para dispositivos IoT, terminais partilhados e sistemas sem interface gráfica.

Estrutura do EAP-TTLS

O EAP-TTLS foi concebido para fornecer uma segurança robusta 802.1X sem o fardo operacional de implementar certificados em cada dispositivo cliente. Funciona em duas fases. Na primeira fase, o servidor RADIUS apresenta o seu certificado e estabelece um túnel TLS seguro. Apenas o servidor necessita de um certificado. Na segunda fase, o cliente é autorizado dentro desse túnel encriptado utilizando um método de autenticação interno. Os métodos internos comuns incluem o PAP (Password Authentication Protocol), CHAP e MS-CHAPv2. O cliente envia o seu nome de utilizador e palavra-passe, mas como esta troca ocorre dentro do túnel TLS, as credenciais são encriptadas em trânsito e nunca são expostas pelo ar.

O EAP-TTLS oferece um excelente suporte multiplataforma em macOS, Linux, Android e iOS. A ressalva reside no Windows: o suplicante nativo do Windows não suporta nativamente o EAP-TTLS para 802.1X sem fios de forma imediata. Ambientes com um volume elevado de dispositivos Windows podem necessitar de um suplicante de terceiros, o que aumenta a complexidade operacional. Para ambientes centrados em Windows, o PEAP com MS-CHAPv2 é frequentemente a escolha mais pragmática.

A maior limitação do EAP-TTLS é que não elimina os riscos inerentes às palavras-passe. Se um utilizador escolher uma palavra-passe fraca, esta permanece vulnerável a ataques de força bruta offline. Se a autenticação interna utilizar PAP, a palavra-passe é enviada em texto simples dentro do túnel - o que é aceitável se confiar na sua infraestrutura RADIUS, mas continua a ser um modelo de confiança essencial a compreender.

Comparação Lado a Lado

Guia de Implementação

Implementar EAP-TLS para Frotas Geridas

A implementação do EAP-TLS requer uma PKI funcional e uma plataforma de MDM. A instalação manual de certificados não é viável à escala empresarial. Deve integrar a sua PKI com o seu MDM utilizando SCEP (Simple Certificate Enrolment Protocol) ou EST (Enrolment over Secure Transport). Quando um dispositivo corporativo é registado, este solicita e recebe automaticamente o seu certificado sem a intervenção do utilizador.

Para a gestão de identidades, a Purple atua como um fornecedor de identidade gratuito para serviços como o OpenRoaming sob a licença Connect, facilitando o roaming seguro entre diferentes locais utilizando estruturas subjacentes de certificados e identidade.

Do lado do RADIUS, configure o seu servidor para validar certificados de cliente face à sua CA interna e verificar CRLs ou utilizar OCSP para verificação de revogação em tempo real. As plataformas RADIUS suportadas incluem FreeRADIUS, Microsoft NPS e Cisco ISE. A sobreposição na nuvem da Purple integra-se com hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Implementar EAP-TTLS para Ambientes Mistos

O EAP-TTLS é a escolha ideal para ambientes com dispositivos não geridos. Apenas necessita de implementar um certificado de confiança no seu servidor RADIUS. Certifique-se de que o seu servidor RADIUS se integra diretamente com o seu serviço de diretório - Microsoft Entra ID, Okta ou Google Workspace - para validar as credenciais de autenticação interna. Configure os perfis de WiFi implementados por MDM para impor a validação do certificado do servidor face à sua CA fidedigna específica. Sem este passo, o túnel TLS não oferece qualquer proteção contra pontos de acesso fraudulentos.

Melhores Práticas

Impor a Validação de Certificado do Servidor em Todos os Clientes

O passo de configuração mais crítico tanto para EAP-TLS como para EAP-TTLS é impor a validação de certificado do servidor nos dispositivos clientes. Se um dispositivo não validar o certificado do servidor RADIUS face a uma CA confiável específica, ele ligar-se-á a qualquer servidor que apresente qualquer certificado - incluindo um access point falso. Especifique sempre a CA confiável e o nome de servidor esperado nos seus perfis de WiFi implementados por MDM. Esta simples verificação de configuração é a melhoria de segurança mais eficaz que pode implementar hoje.

Automatizar a Gestão do Ciclo de Vida dos Certificados

Os certificados expiram. Se não tiver um processo de renovação automatizado, enfrentará falhas massivas de autenticação quando os certificados expirarem simultaneamente. Utilize SCEP ou EST para automatizar as renovações e configure alertas de monitorização com bastante antecedência em relação às datas de expiração. Se um dispositivo se perder ou um colaborador sair, revogue o certificado imediatamente. Configure o seu servidor RADIUS para verificar CRLs ou utilize OCSP para validação em tempo real.

Segmentar a Sua Rede por Método de Autenticação

Em ambientes grandes ou distribuídos, considere executar ambos os protocolos em SSIDs separados. Os dispositivos corporativos geridos autenticam-se via EAP-TLS num SSID de WiFi dedicado para o pessoal. Os prestadores de serviços e dispositivos BYOD autenticam-se via EAP-TTLS num SSID separado com a segmentação de VLAN adequada. Este padrão é comum em grupos hoteleiros como o Premier Inn e a Whitbread, onde os dispositivos do pessoal são geridos e emitem-se certificados, enquanto a infraestrutura de convidados utiliza um caminho de autenticação separado. Para mais detalhes sobre a arquitetura de SSID, consulte o nosso guia Three SSIDs to rule them all: the WiFi design for guest, staff and IoT.

Sincronizar a Hora em Toda a Infraestrutura

A validação de certificados depende da hora precisa do sistema. O desvio de relógio nos dispositivos clientes ou servidores RADIUS gera erros de certificado "ainda não válido" ou "expirado" que são difíceis de diagnosticar. Certifique-se de que todos os componentes da infraestrutura estão sincronizados com servidores NTP fiáveis.

Resolução de Problemas e Mitigação de Riscos

Erros de CA Desconhecida (Unknown CA)

Se os registos do RADIUS mostrarem "unknown CA", o dispositivo cliente não confia na CA que emitiu o certificado do servidor RADIUS. Verifique se o seu perfil de MDM inclui o certificado de CA raiz e se o suplicante está configurado para confiar nele. Após uma rotação de CA ou renovação de certificado, volte a enviar o pacote de CA atualizado para todos os dispositivos.

Incompatibilidade de Método EAP

Se os dispositivos se ligarem ao access point mas a autenticação falhar, verifique se o método EAP configurado no cliente corresponde ao método aceite pelo servidor RADIUS. Um perfil de dispositivo configurado para EAP-TLS falhará num servidor RADIUS configurado apenas para PEAP.

Falhas Massivas Devido a Certificados Expirados

Se um grande número de dispositivos falhar a autenticação em simultâneo, verifique primeiro as datas de expiração dos certificados. Esta é a causa mais comum de falhas em massa do 802.1X em implementações EAP-TLS. Implemente um sistema de monitorização que envie alertas 60 dias, 30 dias e sete dias antes da expiração.

Configuração Incorreta do Cliente RADIUS

Cada ponto de acesso ou controlador sem fios deve ser definido como um cliente RADIUS com o endereço IP correto e o segredo partilhado. Incompatibilidades causam tempos de espera de autenticação que são frequentemente atribuídos de forma incorreta ao método EAP. Ative o registo detalhado de RADIUS desde o primeiro dia. Para obter mais orientações sobre resolução de problemas de WiFi, consulte o nosso guia Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures.

-

Conformidade e Alinhamento Regulamentar

Para os CISOs e arquitetos de rede, compreender o panorama regulamentar é essencial ao decidir entre EAP-TLS e EAP-TTLS. A escolha do método EAP tem um impacto direto no seu nível de conformidade em vários quadros regulamentares importantes.

PCI DSS 4.0 (Payment Card Industry Data Security Standard) exige uma autenticação criptográfica forte para redes sem fios em ambientes de dados de titulares de cartões. O Requisito 8.3 exige autenticação multifator para todos os acessos ao CDE, e as redes sem fios abrangidas devem utilizar mecanismos de autenticação forte. O EAP-TLS, com autenticação mútua baseada em certificados, cumpre este requisito de forma definitiva. O EAP-TTLS com MS-CHAPv2 é aceitável se a autenticação interna estiver devidamente protegida e se for imposta a validação do certificado do servidor, mas o EAP-TLS é a escolha mais robusta e preferida pelos auditores. HIPAA (Health Insurance Portability and Accountability Act) exige que as entidades abrangidas implementem salvaguardas técnicas que protejam as informações de saúde eletrónicas protegidas (ePHI) transmitidas através de redes de comunicações eletrónicas. A Regra de Segurança HIPAA não exige protocolos específicos, mas a expectativa de encriptação e controlo de acesso para redes sem fios que transportam ePHI inclina-se fortemente a favor do EAP-TLS para frotas de dispositivos médicos geridos e do EAP-TTLS com validação obrigatória de certificado de servidor para dispositivos dos colaboradores.

WPA3-Enterprise de 192 bits (também conhecido como modo Suite B ou CNSA) é o nível de segurança mais elevado da certificação WPA3 da Wi-Fi Alliance. Este determina o EAP-TLS como o único método de autenticação permitido, exige TLS 1.2 ou superior com conjuntos de cifras específicos (ECDHE com P-384, AES-256-GCM) e exige certificados ECDSA ou RSA-3072. As organizações que implementam o WPA3-Enterprise de 192 bits para aplicações governamentais, de defesa ou de infraestruturas críticas devem utilizar o EAP-TLS. A ISO/IEC 27001 não exige protocolos específicos, mas obriga as organizações a implementar controlos de acesso adequados para os recursos de rede. Uma implementação 802.1X com EAP-TLS ou EAP-TTLS (com validação obrigatória do certificado do servidor) cumpre os requisitos de controlo de acesso à rede do Anexo A.9.1 e A.13.1.

-

Retorno do Investimento (ROI) e Impacto no Negócio

A migração para EAP-TLS exige um investimento inicial na integração de PKI e MDM, mas elimina os custos operacionais de reposição de palavras-passe e o risco financeiro de violações de rede devido a credenciais comprometidas. Para uma cadeia de retalho com 400 lojas, uma única palavra-passe comprometida numa rede PSK partilhada pode colocar em risco todo o património. O EAP-TLS elimina completamente esse vetor de ataque.

Para ambientes multi-inquilino e hubs de transportes, a autenticação segura garante que apenas utilizadores autorizados acedam à largura de banda da rede, otimizando assim a utilização da infraestrutura. A atribuição dinâmica de VLAN através de atributos de certificado RADIUS permite uma segmentação de rede criptograficamente reforçada, garantindo que os dispositivos são colocados no segmento de rede correto com base nas propriedades do certificado, em vez de depender da seleção de SSID ou de filtragem de endereços MAC.

A plataforma de WiFi Analytics da Purple integra-se com ambos os caminhos de autenticação, proporcionando visibilidade sobre o número de dispositivos, a duração das sessões e a utilização da rede em todo o seu património. Para obter orientações de implementação específicas para o seu setor, explore os nossos recursos para Hotelaria, Retalho, Saúde e Transportes.