EAP-TLS vs PEAP: Segurança, certificados e adequação
Published
A recomendação mais comum sobre eap tls vs peap é simples e errada. Escolher o EAP-TLS porque é "mais seguro" e deixar o PEAP para equipes que ainda não se atualizaram ignora a questão que realmente define se uma WLAN multilocal continuará funcionando na segunda-feira. Você consegue emitir, renovar e revogar um certificado para cada dispositivo que deveria usá-lo?
Eu não colocaria um único método em toda a propriedade. O EAP-TLS pertence aos dispositivos que você pode inscrever e renovar. O PEAP, quase sempre com EAP-MSCHAPv2 interno, pertence aos casos em que já existe uma senha de diretório e a inscrição de certificado não é viável. O método mais seguro nem sempre é aquele que você consegue executar. Um certificado expirado na administração de um hotel deixa a equipe sem acesso, embora suas contas continuem válidas. Um perfil PEAP que ignora a verificação do servidor pode entregar uma senha de diretório a um access point malicioso. Ambas as falhas são operacionais. Atribua o método à população em vez de procurar uma solução única para toda a rede.
Índice
- EAP-TLS e PEAP Lado a Lado
- Como Cada Método Autentica e Onde Ocorrem Vazamentos de Senhas
- Requisitos de Certificado Antes da Implantação
- Ciclo de Vida do Certificado e Esforço de Implantação
- Revogação, Velocidade de Roaming e Suporte ao Cliente
- Atribua Cada População e Valide a Divisão
EAP-TLS e PEAP Lado a Lado
A diferença prática entre o EAP-TLS e o PEAP é a credencial que cada dispositivo pode suportar e o trabalho necessário para mantê-la utilizável. Use o EAP-TLS para dispositivos nos quais você possa realizar a inscrição e renovação. Use o PEAP onde os usuários já possuem senhas de diretório e a inscrição de certificados não seja prática. Nenhum dos métodos é a resposta certa para todos os perfis de usuários.
| Critério | EAP-TLS | PEAP |
|---|---|---|
| ID do tipo EAP | 13 | 26 |
| Credencial do cliente | Certificado de cliente X.509 | Nome de usuário e senha, geralmente EAP-MSCHAPv2 ou EAP-GTC |
| Credencial do servidor | Certificado do servidor RADIUS | Certificado do servidor RADIUS no túnel TLS externo |
| Autenticação mútua | Certificados de cliente e servidor | Certificado do servidor mais autenticação interna de usuário ou dispositivo |
| Senha na rede | Nenhuma | Sim, dentro do túnel TLS |
| O que um AP malicioso pode roubar se o cliente ignorar as verificações do servidor | Nada semelhante a uma senha; a autenticação falha em modo seguro (closed) | Senha de diretório |
| Revogação de um dispositivo | Revogar ou expirar esse certificado | Desativar a conta ou redefinir uma senha que possa ser reutilizada |
| Trabalho de PKI | Certificados de servidor e cliente, renovação e recuperação | Apenas certificado de servidor |
| Melhor adequação inicial | Funcionários e dispositivos privilegiados gerenciados por MDM | Endpoints não gerenciados que não podem inscrever certificados |
Um artigo técnico da Authentik de 2025 identifica o EAP-TLS como EAP tipo ID 13 e o PEAP como tipo ID 26. Esses IDs identificam os métodos para o RADIUS e para o supplicant. Eles não determinam quais pessoas ou dispositivos devem usá-los.
O que as linhas realmente alteram
A credencial do cliente define o limite operacional. O EAP-TLS apresenta um certificado de cliente X.509. O PEAP usa um nome de usuário e senha, comumente por meio do EAP-MSCHAPv2 ou EAP-GTC. Isso torna o credenciamento e a renovação do certificado o volume de trabalho decisivo, em vez de uma classificação teórica dos métodos.
As verificações de confiança também diferem. O EAP-TLS autentica os certificados do cliente e do servidor. O PEAP valida o certificado do servidor RADIUS no túnel TLS externo e, em seguida, autentica o usuário ou dispositivo com um método interno.
A exposição da senha depende da configuração do supplicant. O EAP-TLS não envia senhas pela rede. O PEAP carrega uma senha dentro do seu túnel, portanto, um cliente que ignora as verificações do servidor pode expor uma senha de diretório para um access point malicioso. Com o EAP-TLS, um certificado de cliente ausente ou não confiável faz com que a autenticação falhe.
O desligamento também depende do que está sendo gerenciado. Um certificado de dispositivo pode ser revogado ou expirar sem a necessidade de redefinir a senha do diretório de uma pessoa. Desativar uma conta ou alterar uma senha reutilizada pode afetar outros logins vinculados a essa credencial.
O equilíbrio operacional é claro: o EAP-TLS exige certificados de cliente, renovação e um caminho de recuperação, enquanto o PEAP exige o certificado do servidor e uma configuração cuidadosa do suplicante. Atribua o EAP-TLS à equipe cadastrada e aos dispositivos privilegiados; mantenha o PEAP para endpoints não gerenciados que não podem ingressar no gerenciamento de certificados. Equipes que executam infraestrutura sem servidor para plataformas de membros podem ter populações distintas de membros, equipe e dispositivos, mas o modelo de hospedagem não escolhe o método de autenticação. A credencial precisa ser compatível com quem você consegue gerenciar.
Como Cada Método Autentica e Onde Ocorrem Vazamentos de Senha
O EAP-TLS não é automaticamente a resposta certa para todos os usuários. A decisão fundamental é se sua equipe consegue emitir, renovar e revogar certificados com segurança para cada grupo. O PEAP mantém o onboarding mais simples para usuários não gerenciados, mas sua senha depende da configuração correta do suplicante.
Ambos os métodos usam 802.1X. O supplicant é o dispositivo que solicita o acesso, o autenticador é o access point ou switch que retransmite essa solicitação, e o servidor RADIUS a aceita ou rejeita. Eles compartilham a estrutura EAP, não uma credencial.
O índice de especificações IETF EAP descreve o EAP-TLS, definido na IETF RFC 5216, como autenticação de cliente e servidor baseada em certificado, com autenticação mútua, negociação de cipher-suite protegida por integridade e derivação de chave. A especificação foi publicada em março de 2008. Na prática, o EAP-TLS exige um certificado de cliente emitido por meio de PKI, juntamente com o certificado do servidor RADIUS.
Duas sequências, uma estrutura
O EAP-TLS autentica ambos os endpoints em uma única troca TLS:
- O suplicante inicia o EAP com o autenticador, que retransmite a solicitação para o RADIUS.
- Os certificados do servidor e do cliente são verificados durante a troca TLS.
- A troca protege a negociação do conjunto de criptografia e deriva chaves, sem enviar uma senha que possa sofrer phishing, reutilização ou ataque de força bruta.
- Um certificado de cliente ausente ou não confiável significa que o dispositivo é rejeitado. Ele não pode recorrer à digitação de uma senha.
O PEAP cria um túnel TLS externo que autentica o servidor e, em seguida, executa um método interno, comumente EAP-MSCHAPv2 ou EAP-GTC. Como o método interno pode usar um nome de usuário e senha, os dispositivos finais geralmente não precisam de certificados de cliente. O índice de especificações EAP do IETF também descreve a estrutura de padrões que esses métodos utilizam.
Os usuários não veem o túnel externo do PEAP. A identidade interna, geralmente um nome de usuário e senha ou um token, é enviada somente após o TLS ser estabelecido. Isso torna o PEAP familiar para suplicantes baseados em diretório, mas deixa a senha exposta se o cliente não verificar o túnel corretamente.
O PEAP com EAP-TLS interno é um caso especial mais complexo, combinando um método de certificado com um túnel TLS externo. Uma implantação rotulada como "PEAP" geralmente significa PEAP-MSCHAPv2.
Onde o suplicante decide o resultado
Um relatório sobre métodos EAP de segurança sem fio empresarial explica a diferença: o EAP-TLS usa autenticação mútua X.509. O RADIUS valida o certificado do cliente, e o cliente valida o certificado do servidor. Nenhuma senha está disponível para ser alvo de phishing, retransmissão ou força bruta. O relatório também destaca que o NIST exige que tanto a estação sem fio quanto o servidor de autenticação possuam certificados válidos.
Com o PEAP, o cliente deve validar a cadeia de certificados RADIUS e o nome de servidor esperado. Se qualquer uma das verificações estiver ausente, um ponto de acesso malicioso poderá solicitar uma senha de diretório. Um perfil de suplicante definido como “não validar” não protege a senha.
Regra prática: Fixe o nome do servidor RADIUS e a CA emissora no perfil de WiFi. Sem essas verificações, o PEAP pode oferecer uma senha a um servidor malicioso.
Respostas MS-CHAPv2 capturadas podem ser quebradas offline após um atacante obtê-las por meio de um túnel malicioso. Validar o túnel é o controle principal; o método interno não salva um perfil que aceita um servidor não confiável. O mesmo risco de senha se estende além do WiFi. Relatórios sobre credenciais comprometidas em pequenas empresas australianas reforçam por que uma senha de diretório reutilizada continua sendo valiosa para um atacante.
Atribua EAP-TLS a dispositivos gerenciados e usuários cujo ciclo de vida do certificado você possa operar. Use PEAP onde usuários ou dispositivos não puderem receber e renovar certificados de forma confiável, mas exija a validação da CA e do nome do servidor por meio do perfil do suplicante. O compromisso operacional é direto: certificados exigem trabalho de registro e recuperação, enquanto senhas deixam você gerenciando reutilizações e alterações de contas. O melhor método depende de quem você pode gerenciar, e não de declarar um único vencedor para cada SSID.
Requisitos de Certificados Antes da Implantação
Confirme estes seis itens em laboratório antes da primeira associação em produção. A falta de uma cadeia de certificados ou um nome incorreto parecerá "WiFi fora do ar", e não um erro de certificado.
- Certificado do servidor RADIUS. Emita-o a partir da sua AC privada. Insira o nome que o perfil do supplicant fixa no assunto ou SAN. Configure o uso de autenticação do servidor e forneça a cadeia intermediária completa com o certificado. Uma AC pública que assine qualquer nome correspondente é o modelo de confiança incorreto para um nome RADIUS interno.
- Certificado do cliente. Um por dispositivo ou usuário, com uso de autenticação de cliente. Insira uma identidade exclusiva no SAN, como um nome principal de usuário ou o número de série de um dispositivo. Armazene a chave privada no TPM ou secure enclave quando a plataforma der suporte.
- Âncora de confiança. Instale a AC raiz interna ou emissora por meio do perfil de MDM. Não aponte os dispositivos para uma raiz pública esperando que a verificação de nome seja suficiente.
- Validade e renovação. Defina um tempo de vida para o certificado do servidor e para os certificados dos clientes. Crie uma janela de sobreposição para que o substituto seja instalado antes que o antigo expire.
- Revogação. Forneça ao servidor RADIUS um ponto de extremidade CRL ou OCSP que ele possa alcançar. Defina, por escrito, se a autenticação falha ou prossegue quando esse ponto de extremidade estiver offline. Teste o cenário offline. Não descubra o comportamento durante uma instabilidade na WAN.
- Canal de inscrição. Entregue certificados com SCEP ou um PKCS#12 por meio do MDM. Valide o processo em um dispositivo, incluindo a renovação, antes de direcionar a um grupo.
Suponha que uma clínica use o Okta para a identidade dos funcionários e o Intune para notebooks. O nome RADIUS no perfil deve corresponder ao certificado, e o grupo do Okta que deve ser direcionado para a VLAN clínica precisa ser o mesmo grupo que o MDM usa para o credenciamento. Nossas notas sobre autenticação de WiFi do Okta orientam essa transferência de identidade sem transformar o laboratório em um SSID com senha.
Conecte um notebook de teste, revogue seu certificado e confirme que a próxima associação falhará antes de mexer no ambiente de produção.
Ciclo de Vida do Certificado e Esforço de Implantação
A segurança do EAP-TLS se transforma em uma interrupção de serviço quando um certificado expira, ou quando um cliente não consegue acessar as informações de revogação, mesmo com a conta do usuário perfeitamente válida. Essa é a questão que vale a pena ponderar. Afirmar que "certificados são mais difíceis" não é um projeto de arquitetura.
A NIST Special Publication 800-120 aborda essa mesma responsabilidade. O EAP-TLS exige emissão, distribuição, renovação, gerenciamento de cadeia de confiança e verificação de revogação confiáveis. Um dispositivo com um certificado expirado, ou um serviço de revogação inacessível, pode perder o acesso à rede mesmo quando a identidade do usuário permanece válida. O PEAP normalmente autentica o servidor na fase TLS externa e um nome de usuário e senha por meio de um método interno, como o MS-CHAPv2, pulando o ciclo de vida do cliente. O primeiro dia mais fácil transfere a carga de trabalho para redefinições de senha e perfis incorretos.
Evite que os certificados se tornem a causa de interrupções
A resposta de projeto é a automação, não um guia de procedimentos mais longo.
- Inscreva via MDM. Envie o perfil, a âncora de confiança e o certificado juntos. A configuração manual de WiFi é onde as verificações de nome do servidor acabam sendo desmarcadas.
- Sobreponha a renovação. Instale o novo certificado antes que o antigo expire. Um fim de semana em que todos os notebooks param de funcionar ao mesmo tempo indica que a sobreposição foi muito curta.
- Teste a revogação offline. Saiba se o RADIUS falha bloqueando (fail-closed) ou liberando (fail-open) o acesso quando o CRL ou OCSP não puder ser obtido.
- Mantenha um caminho de recuperação. Um dispositivo com falha precisa de um meio de retorno que não seja "pegar emprestada a senha PEAP de alguém." Uma porta cabeada de suporte ou um SSID de recuperação altamente restrito é muito melhor do que um segredo compartilhado escrito em um quadro branco.
O Purple Access recebe certificados EAP-TLS do Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru e Addigy, entregues via SCEP, com uma configuração que leva de cinco a dez minutos apenas uma vez para a organização, em vez de por dispositivo. A rede segura é baseada em certificados e sem senha, e um dispositivo que falha na verificação de postura tem o acesso recusado na autenticação por meio do Conditional Access. Trata-se de uma entrada controlada por conformidade, e não de uma segunda solicitação de senha.
O PEAP continua sendo a escolha mais direta quando a PKI é pouco desenvolvida, quando prestadores de serviço não podem ser incluídos no MDM ou quando ambientes BYOD mistos não aceitam um certificado. Setores como saúde, educação, hotelaria e outras estruturas com múltiplos locais frequentemente enfrentam esses três desafios ao mesmo tempo. Use o EAP-TLS para dispositivos corporativos gerenciados, da equipe e de alto risco. Mantenha uma alternativa estritamente controlada para endpoints temporários ou não gerenciados. A identidade em escala para locais físicos é a decisão principal, não apenas um slogan de que o TLS superou as senhas.
Se o próprio RADIUS for o ponto frágil, um backend hospedado elimina a falha de ter "um servidor no armário da matriz". Nosso artigo sobre RADIUS-as-a-Service é o local ideal para verificar o alcance e a redundância antes de culpar o método EAP.
O breve passo a passo abaixo mostra a inscrição de certificados ao lado de um método interno por senha, que é o contraste observado pelas equipes de suporte quando a renovação está atrasada.
Velocidade de Roaming com Revogação e Suporte do Cliente
Suporte e velocidade são problemas de consulta. Os supplicants atuais do Windows, macOS, iOS, Android e ChromeOS suportam ambos os métodos. O modo de falha é o que difere.
O EAP-TLS falha quando o perfil, a AC emissora ou as datas de validade estão incorretos. O PEAP falha quando o método interno, o formato de identidade ou a verificação do nome do servidor não correspondem à política do RADIUS. Nenhuma dessas falhas significa que o ponto de acesso "não suporta enterprise."
A revogação segue a mesma divisão. Desativar o certificado de um dispositivo bloqueia aquele laptop sem afetar os outros logins da pessoa. Redefinir uma senha de diretório afeta todos os clientes não gerenciados que ainda a utilizam. O bloqueio imediato e específico por dispositivo é a vantagem do EAP-TLS. As falhas severas por certificados expirados são o custo.
Handshakes, não nomes de marcas
Um artigo da ACM sobre latência de autenticação sem fio mostra que o desempenho depende mais da contagem de handshakes, roaming, validação de certificado e latência do backend do que do nome do método. O EAP-TLS padrão conclui a autenticação do certificado do cliente e do servidor em sua troca TLS. O PEAP estabelece um túnel TLS e, em seguida, executa a autenticação interna, adicionando uma fase distinta. O material técnico da Cisco mencionado nesse artigo destaca que o PEAP com EAP-TLS interno envolve dois handshakes TLS e pode ser lento quando a reautenticação completa ocorre durante o roaming.
Meça esses itens separadamente. Não defina um vencedor com base em apenas um tempo médio de login.
- Tempo de associação ao IP no percentil 95
- Latência da autenticação completa versus retomada do roam
- Tempo de ida e volta (RTT) do RADIUS
- Taxa de falha de autenticação
- Falhas de renovação de certificado
Retomada de sessão, cache PMK ou 802.11r, alcance do RADIUS local e uma cadeia curta de certificados alteram mais esses números do que a troca de um conjunto de criptografia. O PEAP pode parecer simples no primeiro dia e ainda assim gerar atrasos por meio de repetidas trocas de senha e suporte ao usuário. O EAP-TLS pode parecer instantâneo após o credenciamento e depois falhar gravemente devido a um certificado expirado.
| Sintoma | Método mais provável | Causa comum | Correção prática |
|---|---|---|---|
| Pede a senha novamente perto de um AP desconhecido | PEAP | Suplicante não está validando o nome do servidor ou a cadeia | Envie um perfil que fixe o nome do RADIUS e a CA |
| O acesso cai em um notebook após uma mudança de função | EAP-TLS | Certificado revogado ou dispositivo removido do MDM | Confirme a revogação e reative apenas esse dispositivo |
| Toda a equipe bloqueada em uma segunda-feira | EAP-TLS | Certificados expiraram juntos ou a sobreposição de renovação foi muito curta | Programe a renovação antes do vencimento e mantenha um caminho de recuperação |
| O roaming parece lento apenas na reautenticação completa | PEAP com EAP-TLS interno | Dois handshakes TLS | Dê preferência à retomada, cache de PMK ou 802.11r; evite o EAP-TLS interno, a menos que seja necessário |
| Rejeições aleatórias apenas em um local | Qualquer um dos dois | Rounds-trips de RADIUS ou busca de cadeia, não o nome EAP | Meça o RTT e o percentil 95 da associação para IP antes de alterar o método |
Um roaming lento em um local geralmente se deve à distância do RADIUS ou à busca de cadeia de certificados, e não uma prova de que você escolheu o tipo de EAP errado.
Atribua Cada População e Comprove a Divisão
Um mesmo edifício pode abrigar laptops da equipe, um convidado de conferência, o Mac de um prestador de serviços e um caixa. Eles não devem compartilhar o mesmo tipo de credencial. Mapeie cada população, faça um piloto em um local ao lado da rede que você já opera e avalie os chamados e o log de autenticação antes de replicar o projeto.
| População | Usar | Não usar | Motivo |
|---|---|---|---|
| Funcionários gerenciados por MDM e usuários privilegiados | EAP-TLS em um SSID WPA-Enterprise | PSK compartilhado ou PEAP | Identidade por certificado, VLAN por grupo, o acesso termina quando a conta é desativada |
| Hóspedes e visitantes de curta permanência | Captive Portal ou Passpoint em uma VLAN de convidados | Inscrição PEAP ou EAP-TLS na recepção | Sem ciclo de vida de certificado e sem senha de diretório para sofrer phishing |
| Laptops não gerenciados e prestadores de serviços | Apenas PEAP-MSCHAPv2 com validação forçada de servidor | EAP-TLS se você não puder inscrevê-los ou renová-los | As senhas já existem, mas o perfil deve verificar o certificado RADIUS |
| Impressoras, TVs, caixas registradoras, CFTV e sensores | PSK por dispositivo com sua própria VLAN | EAP-TLS ou uma senha PEAP compartilhada | Esses dispositivos geralmente não conseguem armazenar certificados, e uma chave compartilhada é difícil de alternar |
| Local misto em um único prédio | Divisão por identidade em VLANs separadas | Um SSID e um método para todos | Funcionários, convidados e dispositivos falham de maneiras diferentes e não devem compartilhar um tipo de credencial |
Quem permanece em senhas e quem não deve
Funcionários gerenciados e usuários privilegiados obtêm EAP-TLS em um SSID WPA-Enterprise. As equipes de limpeza, recepção e operações podem se autenticar com certificados de um MDM via SCEP, ser alocadas em uma VLAN por grupo de diretório e perder o acesso quando a conta for desativada. Um PSK compartilhado ou uma senha PEAP recria exatamente aquilo que você estava tentando eliminar.
Hóspedes e visitantes permanecem em um Captive Portal ou Passpoint, em uma VLAN de convidados. Não cadastre certificados na recepção e não os coloque em PEAP. Não há um ciclo de vida que você vá gerenciar, e há uma senha de diretório que você não quer que seja vítima de phishing. Um perfil Passpoint pode se reconectar na próxima visita sem a necessidade de um novo chamado.
Laptops não gerenciados e prestadores de serviços podem permanecer no PEAP-MSCHAPv2, e somente se o perfil forçar a validação do servidor. Se você não puder cadastrá-los ou renová-los, o EAP-TLS os deixará sem acesso. Se você não puder forçar a verificação do servidor, o risco da senha supera a conveniência, e eles não deveriam estar no SSID de funcionários de forma alguma.
Impressoras, TVs, caixas, EPOS, CFTV, sensores e controladores de acesso recebem uma PSK por dispositivo e sua própria VLAN. Eles geralmente não conseguem armazenar certificados. Uma senha PEAP compartilhada traz de volta o problema da chave compartilhada. O requisito PCI DSS v4.0.1 Req 2.3.2 exige que as chaves sem fio sejam alteradas quando qualquer pessoa que as conheça se desligar, algo que uma chave compartilhada torna inviável. A iPSK é a solução ideal para esses dispositivos. TVs de quartos, termostatos e caixas pertencem a VLANs vinculadas a chaves que os visitantes nunca veem.
Prove em um local
Aplique o novo projeto nos access points que o local já possui, ao lado da rede atual. Avalie os resultados com base em chamados e evidências de auditoria, não em um login de demonstração.
Exija um log de autenticação que registre cada aceite e rejeição com identidade, dispositivo, status de credenciamento MDM, método, ponto de acesso, SSID, local, VLAN, função, motivo e horário. Esse mesmo log é o conjunto de evidências para os controles de acesso e registro do ISO 27001 e para os requisitos 8 e 10 do PCI-DSS. Sem MDM, bloqueie os perfis PEAP primeiro e agende certificados apenas para a população gerenciada.
Podemos executar essa divisão como três redes por propriedade. Os hóspedes usam o portal, incluindo uma verificação de quarto via PMS quando a propriedade possuir um. A equipe usa EAP-TLS ou Passpoint. Os dispositivos utilizam chaves por dispositivo. O RADIUS base do Cloud RADIUS direciona cada dispositivo para a rede e VLAN corretas por identidade e rejeita quem sai e tem sua conta desativada. O caminho de migração para deixar de usar uma senha compartilhada pela equipe é o mesmo descrito em nosso guia para migrar o WiFi da equipe de vários locais para 802.1X.
Eu iniciaria o piloto com o SSID da equipe gerenciada e as chaves por dispositivo para os caixas, e manteria os prestadores de serviço em um perfil PEAP validado até que a integração esteja consolidada. Um método único para todos parece mais simples em um diagrama, mas falha de três maneiras diferentes na prática.
O Purple Access executa WiFi de funcionários baseado em certificado e chaves por dispositivo para equipamentos nos pontos de acesso que você já possui, de modo que eap tls vs peap se torna uma escolha de população em vez de uma aposta em toda a propriedade. Você pode comprovar conexões abertas, seguras e xPSK em um único local, e então avaliar os chamados e o log de autenticação antes de uma implantação mais ampla. Visite Purple Access para mapear suas redes de funcionários, visitantes e dispositivos.
