Transportverschlüsselung Teil 2 Webmaster in der HTTPS-Pflicht

Als ob die DSGVO alleine vielen Administratoren nicht schon genug schlaflose Nächte verursacht hätte, möchte Google unter Androhung eigener Sanktionen das Internet zwangsweise auf HTTPS umstellen. IT-Verantwortliche geraten einmal wieder in Zugzwang, wenn sie nicht riskieren wollen durch Google abgestraft zu werden und dadurch wertvollen Traffic aus Deutschlands meistgenutzter Websuche zu verlieren.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FTAPI Software GmbH

Jede zweite Webseite nutzt immer noch HTTP und könnte im Juni oder Juli aus dem Netz verschwinden. Googles Browser Chrome soll in der kommenden Version 68 seinen Nutzern den Zugriff auf unverschlüsselte Webseiten verweigern. Webmaster müssen sich darauf gefasst machen, dass ihre Besucherströme plötzlich dahinschwinden, wenn sie bis dahin unverschlüsseltes HTTP immer noch nicht abgeschafft haben sollten. Auch die Nutzer anderer Browser werden im Endeffekt wegbleiben: durch den Verlust des SEO-Rankings betreffender Domains rutschen diese im Laufe der Zeit zwangsweise in den Abgrund totaler Irrelevanz. Hinzu kommt ja auch noch die DSGVO. Der Einsatz von HTTPS ist zwar in der DSVGO 2018 formal nicht verankert, wird aber indirekt vorausgesetzt. Denn ohne eine robuste Transportverschlüsselung ist der Schutz personenbezogener Daten auf dem Weg übers Internet nicht möglich.

Die .tld-Domainerweiterung .app, die Google als Registrar exklusiv anbietet, setzt auch schon bereits zwingend HTTPS voraus. Ohne HTTPS geht da rein gar nichts. Zu den größten Hindernissen auf dem Weg zur HTTPS-Verschlüsselung zählen die Anschaffung und die Einrichtung von SSL-Zertifikaten, die Bereitstellung zusätzlicher Server-Leistung (insbesondere beim Einsatz von HTTPS mit HTTP 1.1) und nicht zuletzt die Umsetzung der erforderlichen (besser gesagt: umständlichen) Konfiguration.

Bildergalerie

Viele Unternehmen, die bereits HTTPS einsetzen, müssen ihre TLS-Konfiguration gründlich überdenken, und sei es „nur“ im Interesse der Aufrechterhaltung ihrer Sicherheitszertifizierungen. Die PCI DSS-Konformität erfordert das Deaktivieren der Unterstützung für SSL und TLS vor der Version 1.1 spätestens bis zum 30 Juni 2018. Bei PCI DSS, kurz für PCI Data Security Standard, handelt es sich um einen internationaler Standard für die Sicherheit von Zahlungstransaktionen. Cybersicherheitsexperten halten den Einsatz von TLS 1.1 im Übrigen mittlerweile für unverantwortlich, wie schon im ersten Teil unserer Serie zur Transportverschlüsselung „TLS 1.3 - Viel heiße Luft oder ein großer Wurf?“ zu lesen war.

Transportverschlüsselung Teil 1

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

Automatisiert, zertifiziert, verschlüsselt

Mitunter den wichtigsten Kostenpunkt des Wechsels auf HTTPS stellt die Bereitstellung geeigneter SSL-Zertifikate dar. Renommierte Zertifizierungsstellen der „alten Schule“ lassen sich ihre Dienste am liebsten gleich vergolden. Wer mehrere Domains, mehrere Server-Instanzen, mehrere Subdomains und mehrere IPs ausstatten möchte, wird typischerweise zu jedem erdenklichen Anlass erneut zur Kasse gebeten. Abhilfe kann Let's Encrypt schaffen.

Bei Let's Encrypt handelt es sich um eine globale Zertifikatsbehörde einer gemeinnützigen Organisation namens Internet Security Research Group (ISRG) und einen der Projekte der Linux Foundation. Die Let's-Encrypt-Plattform wurde für die Ära automatisierbarer Cybersicherheit konzipiert. Alle Zugriffe erfolgen via API und sind somit leicht automatisierbar. Die Zertifikate gelten jeweils nur 90 Tage (statt wie sonst üblich für mindestens ein Jahr); sie haben sich als robust und zuverlässig erweisen. Dank Let's Encrypt lässt sich die Umstellung eines Webservers auf HTTPS so in der Regel kostenneutral implementieren; die Verlängerung von Zertifikaten lässt sich auf den unterstützten Plattformen (Unices wie Linux, OpenBSD und macOS) mit einem CLI-Tool namens Certbot automatisieren. Derzeit bietet Let's Encrypt nur Zertifikate vom Typ Domain Validation an, weil sich derzeit nur solche zuverlässig automatisieren lassen; bei Organization Validation (OV) und Extended Validation (EV) ist in absehbarer Zukunft Fehlanzeige.

Mit einem Let's-Encrypt-Zertifikat lassen sich bis zu insgesamt 100 SAN-Namen (also explizit genannte Domains und/oder Subdomains) abdecken, und für jede Domain bis zu 20 Zertifikate pro Woche ausstellen. Wer auf einem Wildcard-Zertifikat besteht, um alle Subdomains einer Domäne abzudecken, kann ein solches via ACMEv2 unter Verwendung von DNS-01 anfordern.

Um die benötigten SSL-Zertifikate von Let's Encrypt anfordern zu können gilt es, die betreffenden IP-Adressen des Webservers in den DNS-Einstellungen der zugehörigen Domains zu verzeichnen. (Einer Server-IP lässt sich maximal ein Zertifikat zuweisen; bei Let's Encrypt kann ein solches Zertifikat bis zu 100 SAN-Namen abdecken.)

Auf den von Let's Encrypt unterstützten Systemen zeichnet für die Installation des Zertifikats ein Tool namens Certbot verantwortlich. Detaillierte Anweisungen hierzu liefert der Online-Assistent von Let's Encrypt unter der Adresse: https://certbot.eff.org/

Gratis-SSL-Zertifikat in der Praxis

Wordpress-Website mit Let‘s Encrypt verschlüsseln

HTTPS-Spitzenperformance mit HTTP/2

Seit Tim Berners-Lee das Web vor 27 Jahren aus der Taufe hob, hat sich an dem Übertragungsprotokoll HTTP (Hypertext Transfer Protocol) kaum etwas geändert. Die gängige Version 1.1 von HTTP wurde für den Einsatz mit TLS nicht konzipiert; das Resultat einer Umstellung auf HTTPS ist ein massiver Performance-Einbruch. Dieser lässt sich nicht bloß durch die Bereitstellung zusätzlicher Rechenleistung kompensieren, einfach weil HTTP 1.1 viel zu träge ist. Abhilfe schafft hier HTTP/2.

Zu den wichtigsten Verbesserungen des Kommunikationsablaufs in HTTP/2 zählen die folgenden Features:

• Persistente Datenverbindungen: Dadurch entfällt die Notwendigkeit, den Kommunikationsaufbau zur Bereitstellung einzelner Seitenelemente zwischen dem Server und dem Client jedes Mal aufs Neue zu verhandeln; Multiplexing reduziert die Anzahl der benötigten Verbindungen auf eine pro Webseite und führt zu einer besseren Auslastung der Bandbreite.

• Multiplexing: Der Browser kann im Rahmen einer einzigen Verbindung gleich mehrere Anfragen an den Server senden und mehrere Website-Ressourcen vom Server empfangen.

• Server-Push: In HTTP/1.1 muss der Browser jede Ressource explizit anfragen; in HTTP/2 sendet der Webserver bei absehbaren Folgeanforderungen relevante Daten schon mal vorab, auf Verdacht, direkt in den Cache des Webbrowsers, um eine schnellere Bereitstellung dieser Ressourcen zu ermöglichen.

• Schrumpfkur für den Nachrichtenkopf: In HTTP/1.1 wurden alle Header, einschließlich Cookies, für jedes Objekt einzeln und stets unkomprimiert im Klartext übertragen; In HTTP/2 werden alle Header in einem Block zusammengefasst, zur Vermeidung von Redundanzen dedupliziert, mit einem Verfahren namens HPACK komprimiert und nach dem Übertragen schließlich ausgepackt und ausgewertet.

• Optimierungen: Eine gezielte Gewichtung von Datenbeständen unter Berücksichtigung interner Abhängigkeiten ermöglicht eine intelligente Priorisierung von Datenströmen durch den Browser und damit eine schnellere Bereitstellung der Webseite.

• Umstellung auf ein Binärformat: Binäre Datenpakete sind kompakter und lassen sich ohne eine Konversion verarbeiten.

Eine typische Webseite lässt sich durch die bloße Umstellung auf HTTP/2 (also ohne sonstige Verbesserungen) um mindestens 30 Prozent beschleunigen.

Bildergalerie

Fazit

Mit der Androhung von Sanktionen für die fehlende Transportverschlüsselung sorgte Google vielerorts für hektische Betriebsamkeit im Zuge einer chaotischen Umstellung auf HTTPS. Für die letzten Zweifler ist die DSGVO mit ihren drakonischen Strafen ein überzeugendes wirtschaftliches Argument für den Einsatz von HTTPS.

Die Erkenntnis, dass die TLS-Verschlüsselung über HTTP 1.1 die Performance für die Besucher massiv verschlechtert, ist dennoch längst noch nicht überall angekommen. Zu den Verlierern zählen auf der einen Seite die Webbesucher, weil sie beim Surfen unnötige Latenzzeiten in Kauf nehmen müssen, auf der anderen Seite aber auch die Website-Betreiber selbst, weil ihre Server unter der Last von TLS über HTTP 1.1 plötzlich träge wirken und ihr SEO-Ranking einbüßen.

Wer bei der Zwangsumstellung auf HTTPS nicht unnötig Leistungseinbuße in Kauf nehmen möchte, sollte beim Aktivieren von TLS-Verschlüsselung von HTTP 1.1 auf HTTP/2 umschalten. Wem die Sicherheit von HTTPS-Verbindungen wirklich am Herzen liegt, ist gut beraten, auch die TLS-Konfiguration zu überdenken. Den technischen Details der Umstellung widmet sich der nächste Beitrag aus unserer Serie zur Transportverschlüsselung „HTTPS-Praxis mit TLS 1.3“.

An HTTPS kommen Website-Betreiber jedenfalls jetzt nicht mehr vorbei.

Ü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:45291298)