Transportverschlüsselung Teil 3 HTTPS mit TLS 1.3 in der Praxis

Wem die Sicherheit von HTTPS-Verbindungen am Herzen liegt, der ist gut beraten, die TLS-Konfiguration zu überdenken, denn ohne eine moderne Transportverschlüsselung sind gute Vorsätze beim Datenschutz nur ein Papiertiger. Zwar ist TLS 1.3 nun offiziell aus den Startlöchern, aber die Implementierung ist leider voller Tücken und Überraschungen.

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

SEPPmail - Deutschland GmbH

TXOne Networks

Da die Verwundbarkeiten des TLS-Protokolls bis einschließlich Version 1.2 allgemein bekannt sind (siehe dazu den Bericht „TLS 1.3 - Viel heiße Luft oder ein großer Wurf?“) ist davon auszugehen, dass das Herumschnüffeln an vermeintlich „verschlüsselten“ HTTPS-Verbindungen öfter vorkommen dürfte als einem lieb sein mag. TLS 1.3 verspricht Abhilfe. Leider ist die Implementierung voller Tücken und Überraschungen.

Es beginnt schon damit, dass ein völliger Verzicht auf TLS 1.2 als einen Fallback für Clients mit fehlender Unterstützung für TLS 1.3 vorerst nicht in Frage kommt.

Bildergalerie

Transportverschlüsselung Teil 2

Webmaster in der HTTPS-Pflicht

Server-Unterstützung für TLS 1.3 mit einem TLS 1.2-Fallback einrichten

Die Umsetzung von TLS 1.3 setzt so Einiges an Handarbeit voraus.

Schritt 1: Ein Kernel-Upgrade installieren:

Der Einsatz von TLS 1.3 steht und fällt mit einem Linux-Kernel ab der Version 4.13 („1600 LoC-Patch“). Linux-Kernel bis einschließlich Version 4.12 unterstützten nur maximal AES-128-GCM (gemäß RFC 5288) und scheiden damit aus. Die AEAD-Verschlüsselung, die TLS 1.3 automatisch erwartet, ist erst mit dem sogenannten 1600 LoC-Patch möglich. Mit diesem Patch kann Linux erstmals die Verschlüsselung für eine bereits bestehende Verbindung intern im Kernel (ab Version 4.13) handhaben. Der User-Space übergibt dem Kernel die Kryptoschlüssel für eine bereits aufgebaute Verbindung, sodass die Verschlüsselung transparent innerhalb des Kernels stattfindet. CentOS/RHEL in der Version 6 bleiben mit ihrem 2.6.x-er Kernel außen vor.

Schritt 2. Ein OpenSSL-Upgrade einspielen:

Linux-Distributionen richten standardmäßig „stabile“ (sprich: veraltete) Versionen der OpenSSL-Bibliothek ein, die mit TLS 1.3 bisher nicht zu Recht kommen. OpenSSL muss in der Version 1.1.1 Beta 4 oder neuer vorliegen.

Schritt 3. Zertifikate von einer Zertifizierungsstelle (CA) beschaffen und einrichten:

Zertifizierungsstellen (CAs) gibt es wie Sand am Meer. Doch in der Vergangenheit waren SSL-Zertifikate ein schmerzhafter Kostenpunkt. Dank der kostenfreien SSL-Zertifikate von Let’s Encrypt hat sich endlich dieses Problem größtenteils erledigt. Die leistungsstarke API sorgt für eine schmerzlose Automatisierbarkeit auf allen Unix/Linux-Derivaten.

Schritt 4. Den Webserver konfigurieren:

Wer die benötigten SSL-Zertifikate installiert hat, kann sich im nächsten Schritt der Server-Konfiguration widmen. Die Details der Implementierung hängen von der Art und Versionsnummer des Webservers ab. Grundlegende Parameter zum Aktivieren der SSL-Verschlüsselung in Apache, Nginx, Lighttpd, HAProxy und AWS ELB lassen sich einem Online-Assistenten wie dem SSL Configuration Generator von Mozilla entnehmen. Leider halten sich die Fähigkeiten dieses Werkzeugs in argen Grenzen. Es fehlt hier u.a. die Unterstützung für TLS 1.3 und auch TLS 1.2 leidet unter mangelnder Beachtung (Diffie-Hellman gefälligst? Fehlanzeige). Die Übernahme von Konfigurationsparametern für die TLS-Verschlüsselung nach dem Fertiggericht-Prinzip gehen nach hinten los.

Sicherheitsbewussten Administratoren bleibt nichts anderes übrig als die fehlenden Parameter für den eigenen Webserver samt der passenden Syntax selbst zu eruieren. Zu den wichtigsten Ergänzungen bzw. Korrekturen zählen:

• Aktivieren der Unterstützung für HTTP/2

• Umlenkung von HTTP-Anfragen auf HTTPS

• Unterbinden von Protokoll-Downgrades auf HTTP unter Verwendung von HSTS

• Einrichtung von Browser-Anweisungen mit Hilfe von Sicherheits-Headern (HTTP Security Headers, verfügbar nur mit HTTPS): HTTPS-Sicherheitsheader sorgen für die Übergabe von Anweisungen durch den Webserver an einen (kompatiblen) Webbrowser, um sein Verhalten zu beeinflussen. Zum Schutz gegen Downgrade-Attacken und Cookie-Hijacking lässt sich unverschlüsselte Kommunikation mit dem so genannten HSTS-Header deaktivieren (HSTS steht für HTTP Strict Transport Security). Gegen Clickjacking-Attacken hilft ein X-Frame-Options-Header. Um das Aushebeln von deklarierten Mime-Typen zu verhindern, kommen X-Content-Type-Optionen zum Einsatz. Für den Schutz gegen Cross-Site-Request Forgeries (kurz: X-XSS) zeichnet der X-XSS-Protection-Header verantwortlich. Diese Einstellungen können die verfügbare Angriffsfläche stark reduzieren.

• Deaktivieren verwundbarer Protokollversionen: Als sicher gelten derzeit nur TLS 1.2 und TLS 1.3

• Optimieren der TLS 1.2-Konfiguration zur Härtung durch den Verzicht auf verwundbare Cipher-Suites: Als verwundbar gelten alle Cipher-Suites außer ECDHE- und DHE-basierter Varianten

Eine nicht zu unterschätzende Verwundbarkeit, die sich durch die Umstellung auf HTTPS nicht von selbst erledigt, stellt JavaScript-Code von externen Domains dar. Ein klassisches Beispiel sind Werbeeinblendungen. Mit einer aktivierten CSP-Richtlinie (kurz für Content Security Policy) können Website-Betreiber für eine erhöhte Sicherheit sorgen. Bei CSPs handelt es sich um Sicherheitsrichtlinien, welche unsichere Web-Inhalte aus externen Quellen und Verbindungen über HTTP unterdrücken können. So lassen sich nicht zuletzt auch Clickjacking- und andere Code-Injection-Attacken unterbinden.

Schritt 5. Konfiguration testen:

Zu guter Letzt gilt es, die Konfiguration mit einem Dienst wie der SSL Server Test von Qualys SSL Labs auf ihre Vollständigkeit hin zu überprüfen.

Bildergalerie

Encrypted Traffic Analytics

Eine robuste Transportverschlüsselung hat jedoch auch ihre Schattenseiten: Malware kann jetzt einfach unbemerkt durchsegeln.

Beim Einsatz von TLS bis einschließlich der Version 1.2 (insbesondere mit RSA-Ciphern) konnten IT-Fachkräfte den Datentransfer z.B. vor dem Eingang ins firmeneigene Datencenter auf bösartige Payloads hin überprüfen. Die Kommunikation wurde in diesem Fall durch sogenannte Middleboxes eingelesen, dechiffriert, analysiert und weitergeleitet. Mit TLS 1.3 gehört diese Art von Monitoring der Vergangenheit an. Denn beim Verbindungsaufbau über TLS 1.3 mit ephemeralen Diffie-Hellman-Schlüsseln schlägt die sogenannte „Deep-Packet Inspection“ fehl, weil sich die Kommunikation in Echtzeit nicht ohne Weiteres dechiffrieren lässt — und schon erst recht nicht in Echtzeit. Das Bedürfnis an adäquaten Sicherheitsmaßnahmen für die Unternehmens-IT besteht jedoch weiter.

So mussten sich die Anbieter von Sicherheitslösungen für Traffic-Analytics bei TLS 1.3 nach alternativen Wegen zur Gewährleistung der Integrität der internen Systeme umschauen. Die ersten konkreten Produkte sind bereits auf dem Markt. Alleine Cisco hat vier interessante Lösungen im Köcher:

• Cisco Umbrella untersucht den DNS-Traffic, um einen Verbindungsaufbau, bei dem ein Verdacht auf Malware-Übermittlung besteht, gleich im Vorfeld zu unterbinden.

• Cisco Encrypted Traffic Analytics (ETA) kann bedrohliche Kommunikationsverbindungen aufspüren, ohne die Verschlüsselung der betreffenden Daten aufzuheben. Anstatt zu versuchen, TLS-1.3-Verschlüsselung auf Biegen und Brechen zu dekodieren, nimmt ETA „sichtbare“ Telemetrie-Daten von Switches und Routern unter die Lupe. Anhand der Analyse von Informationen wie der Länge von Datenpaketen, ihren Ankunftszeiten und diverser Merkmale der anfänglichen Handshakes kann ETA verdächtige Aktivitäten identifizieren.

• Cisco Stealthwatch Cloud nutzt maschinelles Lernen, um in den verfügbaren Metadaten auffällige Anomalien aufzuspüren. Cisco kam in den Besitz dieser Technologie mit der Übernahme von Observable Networks mit ihrer gleichnamigen Software.

• AMPE (Advanced Malware Protection for Endpoints) nimmt sich eingehende Datenpakete nach dem Dechiffrieren auf dem Endgerät vor (da es in den Middleboxes ja nicht mehr geht). Es schützt unter anderem PCs, Laptops, Tablets und Smartphones.

Cisco ist bei Weitem nicht der einzige Anbieter.

Der Trend zu immer komplizierteren Algorithmen hält an. Professor Bill Buchanan von der Edinburgh Napier-Universität argumentiert, dass quantum-resistente Ciphern spätestens mit Supersingular-Isogeny Diffie-Hellman (SIDH) möglich wären. SIDH-basierte Lösungen sind ja bereits bei Unternehmen wie Cloudflare im Einsatz. Microsoft hat ein entsprechendes Add-on ja auch schon bereits zu OpenSSL beigesteuert. Der Trend zeigt eindeutig, dass der Bedarf an Encrypted Traffic Analytics ohne die Echtzeit-Entschlüsselung von Kommunikationsverbindungen in Zukunft nur noch weiter eskalieren wird.

Fazit

Inzwischen scheuen Webseitenbetreiber keine Mühe, um die Sicherheit ihrer Systeme mit Blick auf die EU-DSVGO zu verbessern. In einer wirklich sicheren Konfiguration von HTTPS sind lediglich die beiden neuesten Versionen des Protokolls, TLS 1.2 und TLS 1.3, zugelassen. Bei TLS 1.2 gilt es außerdem, unsichere Cipher-Suites und Protokoll-Downgrades zu unterbinden.

Transportverschlüsselung Teil 1

TLS 1.3 - Viel heiße Luft oder ein großer Wurf?

Transportverschlüsselung Teil 2

Webmaster in der HTTPS-Pflicht

Über die Autoren: Filipe Pereira Martins und Anna Kobylinska von McKinley Denali Inc. sind als IT-Consultants auf Cybersecurity spezialisiert und sind für die Leser auf Twitter via @RealPro4Real, @CloudInsidr und @D1gitalInfo erreichbar.

(ID:45295578)