EAP-TLS vs EAP-TTLS: Qual Protocolo 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 no 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 no 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 questão: 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 Detalhada

Arquitetura do EAP-TLS

O EAP-TLS opera num modelo de autenticação mútua dentro do framework de controlo de acesso baseado em portas IEEE 802.1X. Cada troca de autenticação envolve três componentes fundamentais: 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 próprio. Atua como um repetidor transparente, encapsulando mensagens EAP em pacotes RADIUS e encaminhando-as para o servidor de autenticação. O handshake EAP-TLS processa-se da seguinte forma. O ponto de acesso envia um EAP-Request/Identity para o dispositivo de ligação. 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 suas suites de cifra TLS suportadas. 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 em relação ao seu armazenamento de CA de raiz fidedigna. Se a validação falhar, o handshake termina - proporcionando proteção contra pontos de acesso fraudulentos. 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é à CA de raiz fidedigna, verificando se o certificado não expirou e consultando a lista de revogação de certificados (CRL) ou consultando o OCSP. O túnel TLS só é estabelecido e o acesso à rede concedido quando ambas as partes estiverem satisfeitas.

Como não são partilhadas palavras-passe, o EAP-TLS está protegido contra ataques de dicionário offline, roubo de credenciais e phishing. É o único método EAP que cumpre os requisitos do WPA3-Enterprise de 192 bits (Suite B) e é mandatório ou fortemente recomendado pelo PCI-DSS 4.0 para ambientes de dados de titulares de cartões e pelo NIST SP 800-120 para implementações sem fios de alta segurança.

O EAP-TLS requer uma PKI. Precisa de, pelo menos, uma CA de raiz offline e uma CA emissora online. A CA de 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 CA emissora trata da emissão diária de certificados e publica CRLs. Os certificados de cliente são emitidos para dispositivos individuais, não para utilizadores - este é um modelo de identidade de dispositivo. Esta distinção é fundamental para dispositivos IoT, terminais partilhados e sistemas sem ecrã.

Estrutura do EAP-TTLS

O EAP-TTLS foi concebido para fornecer uma segurança 802.1X robusta 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 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 por via aérea.

O EAP-TTLS oferece um excelente suporte multiplataforma em macOS, Linux, Android e iOS. A ressalva é com o Windows: o suplicante incorporado do Windows não suporta nativamente o EAP-TTLS para 802.1X sem fios de forma imediata. Ambientes com um elevado volume de dispositivos Windows podem necessitar de um suplicante de terceiros, o que aumenta a complexidade operacional. Para ambientes centrados no 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 de 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 intervenção do utilizador.

Para a gestão de identidade, o 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 os certificados de cliente face à sua CA interna e verificar as 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 do Purple integra-se com hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Implementar EAP-TTLS para Ambientes Misto

O EAP-TTLS é a escolha ideal para ambientes com dispositivos não geridos. Apenas necessita de implementar um certificado fidedigno 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 seus 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 do Certificado de Servidor em Todos os Clientes

O passo de configuração mais crítico para EAP-TLS e EAP-TTLS é impor a validação do certificado de servidor nos dispositivos clientes. Se um dispositivo não validar o certificado do servidor RADIUS contra uma CA fidedigna específica, ele irá ligar-se a qualquer servidor que apresente qualquer certificado - incluindo um ponto de acesso malicioso. Especifique sempre a CA fidedigna 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 de autenticação em massa 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 for perdido ou um colaborador sair, revogue o certificado imediatamente. Configure o seu servidor RADIUS para verificar as 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 geridos corporativos 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 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 exata do sistema. O desvio do relógio nos dispositivos clientes ou nos 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

Se os registos do RADIUS mostrarem "CA desconhecida", 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 da 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 do Método EAP

Se os dispositivos se ligarem ao ponto de acesso 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 em Massa 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 de 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 limite 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 a 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 Regulatório

Para CISOs e arquitetos de rede, compreender o panorama regulatório é essencial ao decidir entre EAP-TLS e EAP-TTLS. A escolha do método EAP tem um impacto direto na sua postura de conformidade em vários quadros regulamentares fundamentais.

O 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 a autenticação multi-fator para todo o acesso 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 definitivamente este requisito. O EAP-TTLS com MS-CHAPv2 é aceitável se a autenticação interna for devidamente protegida e a validação do certificado do servidor for aplicada, mas o EAP-TLS é a escolha mais robusta e mais simples de auditar. O HIPAA (Health Insurance Portability and Accountability Act) exige que as entidades abrangidas implementem salvaguardas técnicas que protejam as informações eletrónicas de saúde protegidas (ePHI) transmitidas através de redes de comunicações eletrónicas. A HIPAA Security Rule não impõe protocolos específicos, mas a expectativa de encriptação e controlo de acesso para redes WiFi que transportam ePHI pende fortemente a favor do EAP-TLS para frotas geridas de dispositivos médicos e do EAP-TTLS com validação obrigatória do certificado do servidor para dispositivos dos funcionários. WPA3-Enterprise 192-bit (também conhecido como Suite B ou modo CNSA) é o nível de segurança mais elevado da certificação WPA3 da Wi-Fi Alliance. Exige obrigatoriamente o EAP-TLS como único método de autenticação permitido, requer o 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 WPA3-Enterprise 192-bit para aplicações governamentais, de defesa ou de infraestruturas críticas devem utilizar EAP-TLS. O ISO 27001 não impõe protocolos específicos, mas exige que as organizações implementem 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) satisfaz os requisitos de controlo de acesso à rede do Anexo A.9.1 e A.13.1.

-

ROI e Impacto no Negócio

A migração para o EAP-TLS requer 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 toda a infraestrutura. O EAP-TLS elimina completamente esse vetor de ataque.

Para ambientes multi-inquilino e hubs de transportes, a autenticação segura garante que apenas os 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 aplicada de forma criptográfica, 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 da 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 toda a sua infraestrutura. Para obter orientações de implementação específicas do setor, explore os nossos recursos para Hospitality , Retail , Healthcare e Transport .