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

Management-Zusammenfassung

Die Wahl der richtigen EAP-Methode für Ihre 802.1X Implementierung entscheidet darüber, ob Ihr Enterprise WiFi wirklich sicher oder nur auf dem Papier konform ist. 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 legen 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 die Infrastruktur in Einzelhandelsketten, Hotel- und Gastronomiebetrieben sowie Organisationen des öffentlichen Sektors verwalten, läuft diese Entscheidung auf eine Frage hinaus: Verwalten Sie die Geräte? Wenn Sie die Geräteflotte über MDM kontrollieren, ist EAP-TLS die definitive Wahl. Wenn Sie eine vielfältige BYOD-Umgebung unterstützen oder keine robuste Public Key Infrastructure (PKI) besitzen, bietet EAP-TTLS eine pragmatische, hochsichere Alternative. Purple unterstützt beide Authentifizierungswege für Mitarbeiter-WiFi an über 80.000 Live-Standorten.

Technischer Deep-Dive

Architektur von EAP-TLS

EAP-TLS basiert auf einem gegenseitigen Authentifizierungsmodell innerhalb des IEEE 802.1X portbasierten Zugriffskontroll-Frameworks. Jeder Authentifizierungsaustausch 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 transparentes Relay, kapselt EAP-Nachrichten in RADIUS-Pakete und leitet diese an den Authentifizierungsserver weiter. Der EAP-TLS Handshake läuft wie folgt ab. Der Access Point sendet einen 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 kündigt seine unterstützten TLS-Verschlüsselungssammlungen an. 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 Root-CAs. Schlägt die Validierung fehl, wird der Handshake abgebrochen - was Schutz vor betrügerischen Access Points bietet. 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 prüft die Zertifikatssperrliste (CRL) oder fragt OCSP ab. Erst wenn beide Parteien zufrieden sind, wird der TLS-Tunnel etabliert 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 WPA3-Enterprise 192-Bit (Suite B) Anforderungen 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-Ausstellungs-CA. Die Root-CA muss physisch vom Netzwerk getrennt sein (Air-Gap), da ihr privater Schlüssel der Hauptvertrauensanker für Ihre gesamte Zertifikatshierarchie ist. Die ausstellende CA übernimmt die tägliche Zertifikatsausstellung und veröffentlicht CRLs. Client-Zertifikate werden für einzelne Geräte und nicht für Benutzer ausgestellt - 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 eine robuste 802.1X Sicherheit ohne den operativen Aufwand einer Zertifikatsbereitstellung auf jedem Client-Gerät zu bieten. Es arbeitet 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 mit 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, sind die Anmeldedaten bei der Übertragung verschlüsselt und werden niemals über die Luft übertragen.

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 operative 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 ein wesentliches Vertrauensmodell bleibt, das man verstehen muss.

Vergleich im direkten Vergleich

Implementierungshandbuch

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

Die Bereitstellung von EAP-TLS erfordert eine funktionierende PKI und eine MDM-Plattform. Eine manuelle Zertifikatsinstallation ist auf Unternehmensebene nicht praktikabel. Sie müssen Ihre PKI über 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 Benutzereingriff.

Für das Identitätsmanagement fungiert Purple als kostenloser Identitätsanbieter für Dienste wie OpenRoaming unter der Connect-Lizenz und erleichtert das sichere Roaming über verschiedene Standorte hinweg unter Verwendung der zugrunde liegenden Zertifikats- und Identitäts-Frameworks.

Konfigurieren Sie auf der RADIUS-Seite Ihren Server so, dass er Client-Zertifikate mit Ihrer internen CA abgleicht und CRLs überprüft oder OCSP für die Echtzeit-Sperrprüfung 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 die internen Anmeldedaten zu validieren. Konfigurieren Sie Ihre über MDM bereitgestellten WiFi-Profile so, dass sie die Validierung des Server-Zertifikats anhand Ihrer spezifischen vertrauenswürdigen CA erzwingen. Ohne diesen Schritt bietet der TLS-Tunnel keinen Schutz vor gefälschten 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 Server-Zertifikatsvalidierung auf den Client-Geräten zu erzwingen. Wenn ein Gerät das Zertifikat des RADIUS-Servers nicht anhand einer bestimmten vertrauenswürdigen CA validiert, verbindet es sich mit jedem Server, der ein beliebiges Zertifikat vorlegt - einschließlich eines gefälschten 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.

Automatisiertes Zertifikats-Lifecycle-Management

Zertifikate laufen ab. Wenn Sie keinen automatisierten Erneuerungsprozess haben, müssen Sie mit massiven Authentifizierungsfehlern rechnen, sobald Zertifikate gleichzeitig ablaufen. Nutzen Sie SCEP oder EST zur Automatisierung von Erneuerungen und konfigurieren Sie Überwachungswarnungen rechtzeitig 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 nutzen Sie OCSP für eine Echtzeit-Validierung.

Segmentieren Sie Ihr Netzwerk nach Authentifizierungsmethode

In großen oder verteilten Umgebungen sollten Sie in Betracht ziehen, beide Protokolle auf separaten SSIDs zu betreiben. Vom Unternehmen verwaltete Geräte authentifizieren sich über EAP-TLS auf einer dedizierten WiFi-SSID für Mitarbeiter. Externe Mitarbeiter 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 weit verbreitet, wo Mitarbeitergeräte verwaltet und mit Zertifikaten versehen werden, während die Infrastruktur für Gäste einen separaten Authentifizierungspfad nutzt. Weitere Informationen zur SSID-Architektur finden Sie in unserem Leitfaden Three SSIDs to rule them all: the WiFi design for guest, staff and IoT .

Zeitsynchronisation in der gesamten Infrastruktur

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

Fehlerbehebung und Risikominimierung

Unknown CA (Unbekannte CA) Fehler

Wenn 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 Supplicant so konfiguriert ist, dass er diesem vertraut. Senden Sie nach einer CA-Rotation oder einer Zertifikatsverlängerung das aktualisierte CA-Bundle erneut an alle Geräte.

EAP-Methoden-Fehlanpassung

Wenn sich Geräte mit dem Access Point verbinden, aber die Authentifizierung fehlschlägt, prü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 verweigert, überprüfen Sie zuerst die Ablaufdaten der Zertifikate. Dies ist die häufigste Ursache für Massenausfälle von 802.1X in EAP-TLS-Bereitstellungen. Implementieren Sie ein Überwachungssystem, das 60 Tage, 30 Tage und sieben Tage vor dem Ablauf Warnmeldungen sendet.

Fehlkonfiguration des RADIUS-Clients

Jeder Access Point oder Wireless-Controller muss als RADIUS-Client mit der korrekten IP-Adresse und dem gemeinsamen Geheimnis (Shared Secret) definiert sein. Abweichungen führen zu Authentifizierungs-Timeouts, die oft fälschlicherweise der EAP-Methode zugeschrieben werden. Aktivieren Sie von Tag eins an eine detaillierte RADIUS-Protokollierung. Weitere Anleitungen zur Fehlerbehebung bei WiFi 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 bei der Entscheidung zwischen EAP-TLS und EAP-TTLS von entscheidender Bedeutung. Die Wahl der EAP-Methode wirkt sich direkt auf Ihren Compliance-Status in verschiedenen wichtigen Frameworks aus.

PCI-DSS 4.0 (Payment Card Industry Data Security Standard) erfordert eine starke kryptografische Authentifizierung für drahtlose Netzwerke in Karteninhaber-Datenumgebungen. Anforderung 8.3 schreibt eine Multi-Faktor-Authentifizierung für jeden Zugriff auf die CDE vor, und im Geltungsbereich befindliche drahtlose Netzwerke 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 ist und die Validierung des Serverzertifikats erzwungen wird, aber EAP-TLS ist die robustere und auditorenfreundlichere Wahl. HIPAA (Health Insurance Portability and Accountability Act) verlangt von betroffenen Organisationen die Implementierung technischer Sicherheitsvorkehrungen zum Schutz elektronischer, geschützter Gesundheitsdaten (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 Mitarbeitergeräten. 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) und setzt ECDSA- oder RSA-3072-Zertifikate voraus. Organisationen, die WPA3-Enterprise 192-bit für Regierungs-, Verteidigungs- oder kritische Infrastrukturanwendungen bereitstellen, müssen EAP-TLS verwenden. ISO 27001 schreibt keine bestimmten Protokolle vor, verlangt jedoch von Organisationen, angemessene Zugriffskontrollen für Netzwerkressourcen zu implementieren. 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, beseitigt jedoch den betrieblichen Aufwand für Passwortzurücksetzungen und das finanzielle Risiko von Netzwerkverletzungen durch kompromittierte Anmeldedaten. 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 Auslastung der Infrastruktur 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 im richtigen Netzwerksegment platziert werden, anstatt sich auf die SSID-Auswahl oder MAC-Adressfilterung zu verlassen.

Die WiFi Analytics -Plattform von Purple lässt sich in beide Authentifizierungspfade integrieren und bietet Transparenz über Geräteanzahl, Sitzungsdauer und Netzwerkauslastung in Ihrer gesamten Infrastruktur. Für branchenspezifische Bereitstellungsrichtlinien finden Sie weitere Informationen in unseren Ressourcen für Hospitality , Retail , Healthcare und Transport .