EAP-TLS vs EAP-TTLS: Welches zertifikatsbasierte WiFi Protokoll sollten Sie wählen?

Executive Summary

Die Wahl der richtigen EAP-Methode für Ihre 802.1X Bereitstellung entscheidet darüber, ob Ihr Enterprise WiFi wirklich sicher ist oder nur auf dem Papier den Vorgaben entspricht. EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definiert in RFC 5216, erfordert eine gegenseitige Zertifikatsauthentifizierung: Sowohl das Client-Gerät als auch der RADIUS-Server weisen gültige X.509-Zertifikate vor, bevor der Netzwerkzugriff gewährt wird. Zu keinem Zeitpunkt werden Passwörter ausgetauscht. EAP-TTLS (Tunneled Transport Layer Security), definiert in RFC 5281, erfordert nur ein serverseitiges Zertifikat, um einen verschlüsselten TLS-Tunnel aufzubauen, in dem sich der Client mit vorhandenen Verzeichnis-Anmeldedaten authentifiziert.

Für CTOs und Netzwerkarchitekten, die Infrastrukturen in Einzelhandelsketten, Hotelanlagen und Organisationen des öffentlichen Sektors verwalten, läuft diese Entscheidung auf eine Frage hinaus: Verwalten Sie die Geräte selbst? Wenn Sie die Geräteflotte über ein MDM steuern, ist EAP-TLS die definitive Wahl. Wenn Sie eine heterogene BYOD-Umgebung unterstützen oder keine robuste Public-Key-Infrastruktur (PKI) besitzen, bietet EAP-TTLS eine pragmatische, hochsichere Alternative. Purple unterstützt beide Authentifizierungswege für Staff WiFi in über 80.000 Live-Standorten.

Technische Tiefenanalyse

Architektur von EAP-TLS

EAP-TLS basiert auf einem Modell der gegenseitigen Authentifizierung innerhalb des IEEE 802.1X portbasierten Zugriffskontroll-Frameworks. Jede Authentifizierung umfasst drei Kernkomponenten: den Supplicant (Client-Gerät), den Authenticator (Wireless Access Point) und den Authentifizierungsserver (RADIUS-Server). Der Access Point trifft die Authentifizierungsentscheidung nicht selbst. Er fungiert als transparenter Relay, der EAP-Nachrichten in RADIUS-Pakete kapselt und an den Authentifizierungsserver weiterleitet. Der EAP-TLS-Handshake läuft wie folgt ab. Der Access Point sendet ein EAP-Request/Identity an das verbindende Gerät. Das Gerät antwortet mit seiner Identität. Der RADIUS-Server initiiert den TLS-Handshake mit einer EAP-TLS/Start-Nachricht. Der Client sendet ein ClientHello und teilt die von ihm unterstützten TLS-Cipher-Suites mit. Der RADIUS-Server antwortet mit einem ServerHello, seinem X.509-Serverzertifikat und einer Zertifikatsanforderung. Der Client validiert das Serverzertifikat anhand seines Speichers für vertrauenswürdige Stammzertifizierungsstellen (Root CA). Schlägt die Validierung fehl, wird der Handshake abgebrochen - dies bietet Schutz vor gefälschten Access Points. Der Client legt dann sein eigenes X.509-Zertifikat vor. Der RADIUS-Server validiert das Client-Zertifikat, prüft die Signaturkette bis zur vertrauenswürdigen Root CA, verifiziert, dass das Zertifikat nicht abgelaufen ist, und kontrolliert die Zertifikatssperrliste (CRL) oder fragt OCSP ab. Erst wenn beide Parteien zufriedengestellt sind, wird der TLS-Tunnel aufgebaut und der Netzwerkzugriff gewährt.

Da keine Passwörter ausgetauscht werden, ist EAP-TLS sicher vor Offline-Wörterbuchangriffen, Credential Stuffing und Phishing. Es ist die einzige EAP-Methode, die die Anforderungen von WPA3-Enterprise 192-Bit (Suite B) erfüllt, und sie wird von PCI-DSS 4.0 für Karteninhaber-Datenumgebungen sowie von NIST SP 800-120 für hochsichere Wireless-Bereitstellungen zwingend vorgeschrieben oder dringend empfohlen.

EAP-TLS erfordert eine PKI. Sie benötigen mindestens eine Offline-Root-CA und eine Online-Aussteller-CA. Die Root-CA muss physisch vom Netzwerk getrennt (air-gapped) sein, da ihr privater Schlüssel der zentrale Vertrauensanker für Ihre gesamte Zertifikatshierarchie ist. Die Aussteller-CA übernimmt die tägliche Zertifikatsausstellung und veröffentlicht CRLs. Client-Zertifikate werden für einzelne Geräte ausgestellt, nicht für Benutzer - dies ist ein Geräte-Identitätsmodell. Diese Unterscheidung ist entscheidend für IoT-Geräte, gemeinsam genutzte Terminals und bildschirmlose (headless) Systeme.

Struktur von EAP-TTLS

EAP-TTLS wurde entwickelt, um robuste 802.1X-Sicherheit zu bieten, ohne den betrieblichen Aufwand für die Bereitstellung von Zertifikaten auf jedem Client-Gerät zu verursachen. Es funktioniert in zwei Phasen. In der ersten Phase präsentiert der RADIUS-Server sein Zertifikat und baut einen sicheren TLS-Tunnel auf. Nur der Server benötigt ein Zertifikat. In der zweiten Phase wird der Client innerhalb dieses verschlüsselten Tunnels mithilfe einer internen Authentifizierungsmethode autorisiert. Zu den gängigen internen Methoden gehören PAP (Password Authentication Protocol), CHAP und MS-CHAPv2. Der Client sendet seinen Benutzernamen und sein Passwort, aber da dieser Austausch innerhalb des TLS-Tunnels stattfindet, werden die Zugangsdaten bei der Übertragung verschlüsselt und sind niemals über die Luft ungeschützt.

EAP-TTLS bietet eine hervorragende plattformübergreifende Unterstützung für macOS, Linux, Android und iOS. Der Haken liegt bei Windows: Der integrierte Windows-Supplicant unterstützt EAP-TTLS für kabelloses 802.1X standardmäßig nicht nativ. Umgebungen mit einer hohen Anzahl von Windows-Geräten erfordern möglicherweise einen Supplicant eines Drittanbieters, was die betriebliche Komplexität erhöht. Für Windows-zentrierte Umgebungen ist PEAP mit MS-CHAPv2 oft die pragmatischere Wahl.

Die größte Einschränkung von EAP-TTLS besteht darin, dass es die inhärenten Risiken von Passwörtern nicht beseitigt. Wenn ein Benutzer ein schwaches Passwort wählt, bleibt es anfällig für Offline-Brute-Force-Angriffe. Wenn die interne Authentifizierung PAP verwendet, wird das Passwort im Klartext innerhalb des Tunnels gesendet - was akzeptabel ist, wenn Sie Ihrer RADIUS-Infrastruktur vertrauen, aber es bleibt ein wesentliches Vertrauensmodell, das man verstehen muss.

Direkter Vergleich

Implementierungsleitfaden

Bereitstellung von EAP-TLS für verwaltete Geräteflotten

Die Bereitstellung von EAP-TLS erfordert eine funktionierende PKI und eine MDM-Plattform. Die manuelle Installation von Zertifikaten ist auf Unternehmensebene nicht praktikabel. Sie müssen Ihre PKI mithilfe von SCEP (Simple Certificate Enrolment Protocol) oder EST (Enrolment over Secure Transport) in Ihr MDM integrieren. Wenn ein firmeneigenes Gerät registriert wird, fordert es sein Zertifikat automatisch an und erhält es ohne Interaktion des Benutzers.

Für das Identitätsmanagement fungiert Purple unter der Connect-Lizenz als kostenloser Identitätsanbieter für Dienste wie OpenRoaming und ermöglicht so sicheres Roaming über verschiedene Standorte hinweg unter Nutzung der zugrunde liegenden Zertifikats- und Identitätsstrukturen.

Konfigurieren Sie auf der RADIUS-Seite Ihren Server so, dass er Client-Zertifikate mit Ihrer internen CA abgleicht und CRLs prüft oder OCSP für die Sperrungsprüfung in Echtzeit verwendet. Zu den unterstützten RADIUS-Plattformen gehören FreeRADIUS, Microsoft NPS und Cisco ISE. Das Cloud-Overlay von Purple lässt sich in Hardware von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet integrieren.

Bereitstellung von EAP-TTLS für gemischte Umgebungen

EAP-TTLS ist die optimale Wahl für Umgebungen mit unverwalteten Geräten. Sie müssen lediglich ein vertrauenswürdiges Zertifikat auf Ihrem RADIUS-Server bereitstellen. Stellen Sie sicher, dass Ihr RADIUS-Server direkt in Ihren Verzeichnisdienst - Microsoft Entra ID, Okta oder Google Workspace - integriert ist, um interne Authentifizierungsdaten zu validieren. Konfigurieren Sie Ihre per MDM bereitgestellten WiFi-Profile so, dass sie die Validierung von Server-Zertifikaten mit Ihrer spezifischen vertrauenswürdigen CA erzwingen. Ohne diesen Schritt bietet der TLS-Tunnel keinen Schutz vor Rogue Access Points.

Best Practices

Server-Zertifikatsvalidierung auf jedem Client erzwingen

Der wichtigste Konfigurationsschritt sowohl für EAP-TLS als auch für EAP-TTLS besteht darin, die Validierung des Server-Zertifikats auf den Client-Geräten zu erzwingen. Wenn ein Gerät das Zertifikat des RADIUS-Servers nicht mit einer bestimmten vertrauenswürdigen CA abgleicht, verbindet es sich mit jedem Server, der ein beliebiges Zertifikat vorweist - einschließlich eines Rogue Access Points. Geben Sie in Ihren über MDM bereitgestellten WiFi-Profilen immer die vertrauenswürdige CA und den erwarteten Servernamen an. Diese einzige Konfigurationsprüfung ist die effektivste Sicherheitsverbesserung, die Sie heute implementieren können.

Zertifikats-Lebenszyklus-Management automatisieren

Zertifikate laufen ab. Wenn Sie keinen automatisierten Erneuerungsprozess haben, müssen Sie mit massenhaften Authentifizierungsfehlern rechnen, wenn Zertifikate gleichzeitig ablaufen. Nutzen Sie SCEP oder EST, um Erneuerungen zu automatisieren, und konfigurieren Sie Überwachungswarnungen weit vor dem Ablaufdatum. Wenn ein Gerät verloren geht oder ein Mitarbeiter das Unternehmen verlässt, widerrufen Sie das Zertifikat sofort. Konfigurieren Sie Ihren RADIUS-Server so, dass er CRLs prüft oder OCSP für die Echtzeit-Validierung nutzt.

Segmentieren Sie Ihr Netzwerk nach Authentifizierungsmethode

In großen oder verteilten Umgebungen sollten Sie in Erwägung ziehen, beide Protokolle auf separaten SSIDs auszuführen. Verwaltete Unternehmensgeräte authentifizieren sich über EAP-TLS auf einer dedizierten WiFi-SSID für Mitarbeiter. Auftragnehler und BYOD-Geräte authentifizieren sich über EAP-TTLS auf einer separaten SSID mit entsprechender VLAN-Segmentierung. Dieses Muster ist in Hotelgruppen wie Premier Inn und Whitbread üblich, wo Mitarbeitergeräte verwaltet werden und Zertifikate erhalten, während die Infrastruktur für Gäste einen separaten Authentifizierungspfad nutzt. Weitere Informationen zur SSID-Architektur finden Sie in unserem Leitfaden Drei SSIDs, sie alle zu beherrschen: Das WiFi-Design für Gäste, Mitarbeiter und IoT.

Zeitsynchronisierung über die gesamte Infrastruktur hinweg

Die Zertifikatsvalidierung basiert auf einer genauen Systemzeit. Zeitabweichungen auf Client-Geräten oder RADIUS-Servern führen zu Fehlern wie "noch nicht gültig" oder "abgelaufen", die nur schwer zu diagnostizieren sind. Stellen Sie sicher, dass alle Infrastrukturkomponenten mit zuverlässigen NTP-Servern synchronisiert sind.

Fehlerbehebung und Risikominderung

Unbekannte CA-Fehler (Unknown CA)

Wenn die RADIUS-Protokolle "unknown CA" anzeigen, vertraut das Client-Gerät der CA nicht, die das Zertifikat des RADIUS-Servers ausgestellt hat. Überprüfen Sie, ob Ihr MDM-Profil das Root-CA-Zertifikat enthält und der Supplikant so konfiguriert ist, dass er diesem vertraut. Führen Sie nach einer CA-Rotation oder einer Zertifikatserneuerung ein erneutes Deployment des aktualisierten CA-Bundles auf alle Geräte durch.

EAP-Methodenkonflikt (EAP Method Mismatch)

Wenn sich Geräte mit dem Access Point verbinden, aber die Authentifizierung fehlschlägt, überprüfen Sie, ob die auf dem Client konfigurierte EAP-Methode mit der vom RADIUS-Server akzeptierten Methode übereinstimmt. Ein für EAP-TLS eingerichtetes Geräteprofil schlägt auf einem RADIUS-Server fehl, der nur für PEAP konfiguriert ist.

Massenausfälle aufgrund abgelaufener Zertifikate

Wenn eine große Anzahl von Geräten gleichzeitig die Authentifizierung fehlschlägt, überprüfen Sie zuerst die Ablaufdaten der Zertifikate. Dies ist die häufigste Ursache für massenhafte 802.1X-Fehler in EAP-TLS-Bereitstellungen. Implementieren Sie ein Monitoring-System, das 60 Tage, 30 Tage und sieben Tage vor Ablauf Warnmeldungen sendet.

RADIUS-Client-Fehlkonfiguration

Jeder Access Point oder Wireless Controller muss als RADIUS-Client mit der korrekten IP-Adresse und dem gemeinsamen Geheimnis definiert sein. Abweichungen verursachen Authentifizierungs-Timeouts, die oft fälschlicherweise der EAP-Methode zugeschrieben werden. Aktivieren Sie detailliertes RADIUS-Logging vom ersten Tag an. Weitere Ratschläge zur Behebung von WiFi-Problemen finden Sie in unserem Leitfaden Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures.

-

Compliance und Einhaltung gesetzlicher Vorschriften

Für CISOs und Netzwerkarchitekten ist das Verständnis der regulatorischen Landschaft von entscheidender Bedeutung bei der Entscheidung zwischen EAP-TLS und EAP-TTLS. Die Wahl der EAP-Methode wirkt sich direkt auf Ihre Compliance-Position in mehreren wichtigen Frameworks aus.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) erfordert eine starke kryptografische Authentifizierung für drahtlose Netzwerke in Umgebungen mit Karteninhaberdaten. Die Anforderung 8.3 schreibt eine Multi-Faktor-Authentifizierung für jeden Zugriff auf die CDE vor, und drahtlose Netzwerke im Geltungsbereich müssen starke Authentifizierungsmechanismen nutzen. EAP-TLS mit zertifikatsbasierter gegenseitiger Authentifizierung erfüllt diese Anforderung definitiv. EAP-TTLS mit MS-CHAPv2 ist akzeptabel, wenn die innere Authentifizierung ordnungsgemäß gesichert und die Serverzertifikatsvalidierung erzwungen wird, aber EAP-TLS ist die robustere und auditorenfreundlichere Wahl. HIPAA (Health Insurance Portability and Accountability Act) verpflichtet betroffene Stellen zur Implementierung technischer Sicherheitsvorkehrungen zum Schutz elektronischer geschützter Gesundheitsinformationen (ePHI), die über elektronische Kommunikationsnetze übertragen werden. Die HIPAA-Sicherheitsregel schreibt keine bestimmten Protokolle vor, aber die Erwartung von Verschlüsselung und Zugriffskontrolle für WiFi-Netzwerke, die ePHI übertragen, spricht stark für EAP-TLS bei verwalteten medizinischen Geräteflotten und für EAP-TTLS mit erzwungener Serverzertifikatsvalidierung bei Geräten des Personals.

WPA3-Enterprise 192-Bit (auch bekannt als Suite B oder CNSA-Modus) ist die höchste Sicherheitsstufe der WPA3-Zertifizierung der Wi-Fi Alliance. Sie schreibt EAP-TLS als einzig zulässige Authentifizierungsmethode vor, erfordert TLS 1.2 oder höher mit spezifischen Verschlüsselungssammlungen (ECDHE mit P-384, AES-256-GCM) sowie ECDSA- oder RSA-3072-Zertifikate. Organisationen, die WPA3-Enterprise 192-Bit für Behörden-, Verteidigungs- oder kritische Infrastrukturanwendungen bereitstellen, müssen EAP-TLS verwenden.ISO 27001 schreibt keine bestimmten Protokolle vor, verlangt jedoch von Organisationen die Implementierung angemessener Zugriffskontrollen für Netzwerkressourcen. Eine 802.1X-Bereitstellung mit entweder EAP-TLS oder EAP-TTLS (mit erzwungener Serverzertifikatsvalidierung) erfüllt die Anforderungen an die Netzwerkzugriffskontrolle der Anhänge A.9.1 und A.13.1.

-

ROI und geschäftliche Auswirkungen

Die Migration zu EAP-TLS erfordert eine Anfangsinvestition in die PKI- und MDM-Integration, eliminiert jedoch den operativen Aufwand für Passwortzurücksetzungen und das finanzielle Risiko von Netzwerkeinbrüchen durch kompromittierte Zugangsdaten. Für eine Einzelhandelskette mit 400 Filialen kann ein einziges kompromittiertes Passwort in einem gemeinsam genutzten PSK-Netzwerk das gesamte Unternehmen gefährden. EAP-TLS eliminiert diesen Angriffsvektor vollständig.

In mandantenfähigen Umgebungen und Verkehrsknotenpunkten stellt eine sichere Authentifizierung sicher, dass nur autorisierte Benutzer auf die Netzwerkbandbreite zugreifen, wodurch die Infrastrukturnutzung optimiert wird. Die dynamische VLAN-Zuweisung über RADIUS-Zertifikatsattribute ermöglicht eine kryptografisch erzwungene Netzwerksegmentierung. Dies stellt sicher, dass Geräte basierend auf den Zertifikatseigenschaften dem richtigen Netzwerksegment zugewiesen werden, anstatt sich auf die SSID-Auswahl oder MAC-Adressfilterung zu verlassen.

Die Plattform von Purple für WiFi Analytics lässt sich in beide Authentifizierungspfade integrieren und bietet Einblicke in Geräteanzahlen, Sitzungsdauern und die Netzwerkauslastung in Ihrem gesamten Unternehmen. Branchenspezifische Bereitstellungsrichtlinien finden Sie in unseren Ressourcen für Hospitality, Retail, Healthcare und Transport.