Questão de Segurança da Informação — Protocolos Seguros para Redes Sem Fio e Controle de Acesso (WPA, WPA2, WEP, EAP, 802.1X) — FCC 2025

EAP-TLS: autenticação mútua com certificados em redes sem fio

Gabarito: letra C. O fluxo capturado mostra a sequência típica do EAP-TLS: após a identificação do cliente (EAP-Response/Identity), o servidor RADIUS inicia uma negociação TLS (EAP-Request/TLS Start) e o cliente responde com o Client Hello — é exatamente essa troca que evidencia o uso de certificados digitais para autenticação mútua. As demais alternativas descrevem métodos que não correspondem ao fluxo apresentado.

O EAP (Extensible Authentication Protocol) é um framework de autenticação que permite a utilização de diversos métodos. No contexto de redes sem fio corporativas, ele é transportado pelo protocolo EAPOL (EAP over LAN), que opera sobre o padrão IEEE 802.1X. O 802.1X define três papéis: o requerente (cliente/STA), o autenticador (ponto de acesso) e o servidor de autenticação (RADIUS). O fluxo começa com o cliente enviando um EAPOL-Start, o AP responde com EAP-Request/Identity, e o cliente envia sua identidade. A partir daí, o AP encapsula as mensagens EAP no protocolo RADIUS e as encaminha ao servidor de autenticação, que decide qual método EAP será usado.

O EAP-TLS (Transport Layer Security) é um dos métodos mais seguros, pois exige certificados digitais tanto do servidor quanto do cliente — é a chamada autenticação mútua. No fluxo, após o servidor receber a identidade do cliente, ele envia um EAP-Request/TLS Start, indicando que a negociação TLS será iniciada. O cliente responde com EAP-Response/TLS Client Hello, que é o primeiro passo do handshake TLS. Essa troca é a assinatura característica do EAP-TLS. Outros métodos, como PEAP e EAP-TTLS, também usam TLS, mas criam um túnel seguro antes de autenticar o cliente — o que não ocorre no fluxo apresentado, pois a negociação TLS começa imediatamente após a identificação.

A alternativa B menciona que o servidor RADIUS solicitou o certificado do cliente "através do protocolo TCP". Isso está incorreto por dois motivos: primeiro, o RADIUS tradicionalmente usa UDP (porta 1812 para autenticação), não TCP; segundo, a solicitação do certificado ocorre dentro da negociação TLS, não como uma mensagem RADIUS separada. O fluxo mostra apenas o início da negociação TLS, e a solicitação do certificado do cliente viria em etapas posteriores do handshake.

A alternativa A sugere WPA2-PSK, mas o PSK (Pre-Shared Key) não utiliza servidor RADIUS nem EAP — é uma chave compartilhada usada diretamente entre cliente e AP. A presença do RADIUS e do fluxo EAP indica claramente o modo Enterprise, não o Personal. A alternativa D menciona EAP-MD5, que é um método baseado em senha sem certificados, mas o fluxo mostra uma negociação TLS, o que descarta o MD5. A alternativa E sugere PEAP, que também usa TLS, mas a diferença crucial é que no PEAP o túnel TLS é estabelecido antes da autenticação do cliente — no fluxo, a negociação TLS começa imediatamente após a identidade, sem uma fase de túnel separada, o que é típico do EAP-TLS.

A pegadinha central desta questão é distinguir os métodos EAP que usam TLS: no EAP-TLS, tanto cliente quanto servidor precisam de certificados, e a negociação TLS é o próprio mecanismo de autenticação; no PEAP e no EAP-TTLS, o TLS cria um túnel protegido e a autenticação do cliente ocorre dentro dele, geralmente com senha. O fluxo apresentado mostra o início da negociação TLS logo após a identificação, sem uma fase de túnel separada — isso aponta diretamente para o EAP-TLS.

Alternativa A — ❌ Incorreta

Afirma que a rede opera com WPA2-PSK, indicado pelo fluxo simplificado. O erro: o fluxo mostra a presença de um servidor RADIUS e mensagens EAP, o que é característico do modo Enterprise (802.1X), não do PSK. No PSK, a autenticação é feita diretamente entre cliente e AP com uma chave compartilhada, sem servidor RADIUS e sem o fluxo EAPOL/EAP descrito.

Alternativa B — ❌ Incorreta

Afirma que o servidor RADIUS solicitou o certificado do cliente via TCP. Dois erros: (1) o RADIUS tradicionalmente usa UDP (porta 1812), não TCP; (2) a solicitação do certificado ocorre dentro da negociação TLS, não como uma mensagem RADIUS separada. O fluxo mostra apenas o início do handshake TLS (Client Hello), e a solicitação do certificado viria em etapas posteriores.

Alternativa C — ✅ Correta ⟵ GABARITO

O fluxo mostra a sequência típica do EAP-TLS: após a identificação do cliente, o servidor RADIUS envia EAP-Request/TLS Start, e o cliente responde com EAP-Response/TLS Client Hello. Essa negociação TLS é a assinatura do EAP-TLS, que exige certificados digitais de ambos os lados (autenticação mútua). A alternativa está correta ao afirmar que o processo utiliza EAP-TLS, evidenciado pela negociação TLS iniciada após a identificação.

Alternativa D — ❌ Incorreta

Afirma que a autenticação ocorre via EAP-MD5, baseada em troca de identidade sem certificados. O erro: o fluxo mostra uma negociação TLS (EAP-Request/TLS Start e Client Hello), o que descarta o EAP-MD5, que é um método baseado em senha sem uso de TLS ou certificados.

Alternativa E — ❌ Incorreta

Afirma que o método é PEAP, pois o servidor estabelece um túnel seguro antes da autenticação. O erro: no PEAP, o túnel TLS é estabelecido antes da autenticação do cliente, e o fluxo mostra a negociação TLS começando imediatamente após a identificação, sem uma fase de túnel separada. Essa sequência é típica do EAP-TLS, não do PEAP.

Gabarito: letra C