Auch diejenigen die bis jetzt der Meinung waren, dass eine verschlüsselte Übertragung von Inhalten nicht für alle Daten pauschal gilt, sollten dies noch einmal überdenken. Öffentlich zugängliche Inhalte wie dieser Blog zum Beispiel, müssen nicht wegen der Artikel selbst verschlüsselt werden, sondern aus ganz anderen technischen und auch praktischen Überlegungen heraus. Warum die Nutzung von https statt http der richtige Schritt ist, zeigt die Auseinandersetzung mit diesem Thema hier im Artikel. Ziel ist die Beleuchtung einer anderen Gedankenführung zur Verschlüsselung die nicht oder nicht ausschließlich auf dem Inhalt selbst beruht. Der Artikel befasst sich in der Hauptsache mit Webinhalten, was aber nur dem Umfang des Artikels geschuldet ist. Grundsätzlich gilt es aber den Einsatz von Verschlüsselung uneingeschränkt für alle anderen Arten der Kommunikation ebenfalls einzuführen.
Blickt man einmal zurück, so wird eine Verschlüsselung des Übertragungswegs in den meisten Fällen immer an den Daten selbst, also den eigentlichen Inhalten fest gemacht. Aus der Historie heraus gab es Zeiten an denen dies auch völlig ausreichend war so vorzugehen. Sensible Daten, Passwörter, Logins usw. wurden verschlüsselt, der Rest nicht. Die Rahmenbedingung sind schon längst völlig andere und dies gilt es jetzt zu erkennen. Ein ganz wichtiger Aspekt der geänderten Rahmenbedingungen der häufig bei der Betrachtung des reinen Inhalts übersehen wird, ist der Übertragungsweg an sich. Denn hier hilft die Nutzung von https statt http ungemein. Vor allem hinsichtlich zur Identifizierung des Absenders der Inhalte. Als normaler Benutzer vor seinem Browser wird es bei den vielen dynamischen Inhalten immer schwieriger bis fast unmöglich zu wissen, wo denn die Daten wirklich herkommen. Teils kommen die Daten aus irgendwelchen CDN’s und anderen Cloud-Diensten sowie die unzähligen verlinkungen zu den sozialen Netzwerken. Eine aktuelle Webseite ist ein zusammengewürfeltes Sammelsurium von unterschiedlichen Quellen. Je komplexer aber eine solche Seite ist, desto einfacher eröffnet sich auch der Angriffsvektor für kriminelle um Schadcode durch transparente Proxy oder ähnliche Drive By Attacken unterzuschieben.
Der Schutz gegen eine solchen Szenario ist dann die Ende-zu-Ende Verschlüsselung zwischen Client und Webserver bei der Übertragung von Inhalten. So kann sich der Anwender zumindest darin sicher sein, dass die Daten wirklich vom Webserver und keinem Dritten kommen. Dies garantiert auf der andere Seite natürlich nicht, dass nicht schon die Daten auf dem Server selbst kompromittiert sind. Aber an diesem Punkt sind die Betreiber der Webserver in der Pflicht. Regelmäßige Updates inkl. des Schließen von Sicherheitslücken und Überprüfung der Systeme sollten hier selbstverständlich sein. Aber das ist ein gänzlich anderes Thema. Betrachtet man nun die Verschlüsselung unter diesen Gesichtspunkten, ist der Einsatz von http ohne „s“ eigentlich nicht mehr zu empfehlen und die de facto Verschlüsselung in http/2 ist der richtige Weg. Dazu kommt, dass Google das Ranking von Seiten ohne Verschlüsselung schlechter stellen will und Browser in der Zukunft mehr oder weniger nur noch verschlüsselte Verbindungen unterstützen wollen. Aber wie immer, keine Vorteile ohne Nachteile. Als Unternehmen steht man nun vor einem nicht ganz unerheblichen Problem, was im privaten Bereich gar nicht zum tragen kommt. Der durchschnittliche private Internetzugang ist ein Consumer Router mit NAT und im günstigsten Fall mit einer Statefull Inspection Firewall – das war’s dann auch schon in Sachen Sicherheit. Dies ist aber auch ok, denn mehr Sicherheit wird bei den meisten Anwendern zu Hause nicht benötigt und würde auch die meisten völlig überfordern, qualifizierte Entscheidungen zu treffen, wenn das System Optionen zu verschiedenen Einstellungen vorhalten würde.
Völlig anders sieht es beim Schutz des Perimeters von Unternehmen aus. Hier sollten „state of the art“ Next Generation Firewalls das Netzwerk an der Schnittstelle zum Internet schützen. Die Systeme sollen Inhalte kontrollieren und so ihre Clients respektive ihre Benutzer bestmöglich schützen. Dieser Aufgabe können sie aber weniger gut nachkommen, wenn Inhalte Ende-zu-Ende verschlüsselt sind. Daher stellt sich die Frage: Welche Strategie ist hier die richtige? Bricht man die Verschlüsselung grundsätzlich auf und schaut in die Datenströme hinein oder lässt man die Ende-zu-Ende Verschlüsselung unangetastet und diese somit vom Anwender überprüfbar zu? Dies ist auf jeden Fall eine interessante Frage die viele gute Argumente in beiden Lagern zulässt. Vor allem hat sie auch viele Aspekte die es zu beleuchten gilt. Die Integrität und das Vertrauen in die Daten sind die eine Seite, das Schutzbedürfnis der IT Infrastruktur eines Unternehmen die andere. Auch auf der technischen Ebene kommen Herausforderungen auf die IT zu die gelöst werden müssen. Die zusätzliche Last, die das entschlüsseln und verschlüsseln der Daten bereitet, muss auch bewältigt werden. Dazu noch der administrative Aufwand bei der Zertifikatsstruktur im Unternehmen. Unabhängig vom Standpunkt in dieser Diskussion ist der Einsatz von unverschlüsselter Kommunikation keine Option mehr.
Vielleicht braucht es auch einen neuen und anderen Ansatz um Sicherheit des Clients zu gewährleisten. URL Filter und IP Reputation gewinnen so wieder an Bedeutung, wie auch die Überprüfung des Server-Zertifikats auf Gültigkeit am Gateway selbst, um dies nicht (nur) dem Client zu überlassen. Auf der andere Seite verschlüsseln Angreifer ihre Kommunikation selbst auch, um diese zu verschleiern. Als Angreifer will man ja schließlich nicht auffallen bevor man „seine“ Daten abgegriffen hat. Daher ist davon auszugehen, dass ein professioneller Angriff eher nicht durch Klartext-Kommunikation auffällt und eine Verschlüsselung wählt, die nicht mit den aktuellen zur Verfügung stehenden Mechanismen aufgebrochen werden kann.
Alle diejenigen, die selbst Dienste anbieten setzt die komplette Umstellung auf „https“ jetzt auch unter einen gewissen Zugzwang, dem man sich nicht verschließen kann. Es werden immer mehr webbasierende Dienste angeboten die es zu verschlüsseln und gleichzeitig zu schützen gilt. Als Anbieter von Diensten ist die Ende-zu-Ende Kommunikation mit einem Client etwas anders zu sehen. Das „Ende“ auf der Seite des Servers ist vielmehr am SSL Offload Device zu sehen anstatt auf dem Server des Dienstes selbst. Ein IPS oder eine WAF sind außen vor, wenn diese nur den verschlüsselten Datenstrom sehen. Das macht natürlich beim Einsatz solcher Systeme mal gar keinen Sinn. Zwar funktioniert noch ein wenig (D)DoS auf Layer 4, aber dann war es das auch schon mit der Security. Um hier den Schutz trotz Verschlüsselung aufrecht zu erhalten bietet sich der Offload der Verschlüsselung mit einem ADC an und hier vorzugsweise mit einem der zudem noch eine WAF bietet. Steht dann der ADC und die Webserver noch in unterschiedlichen Netzwerksegmenten, kann das vorhandene IPS wieder den kompletten Datenstrom auf unerwünschte Inhalte hin untersuchen. Da diese Netzwerksegmente unter der eigenen Kontrolle liegen und nicht öffentlich zugänglich sind spricht ja auch nichts dagegen, dass hier Klartext-Daten fließen. Ab dem Perimeter in Richtung Internet und somit zum öffentlichen Netz hin, ist alles entsprechend verschlüsselt. Ein weitere Synergieeffekt, der durch ein solches ADC Konstrukt entsteht, ist die Bereitstellung der eigenen Dienste auf der WAN Seite für IPv4 und IPv6 ohne die internen Server der Applikation ebenfalls umstellen zu müssen. Wählt man hier das passende Produkt, so bekommt man je nach nach dem wie man sich entscheidet eine mächtige Sprache zum Beeinflussen und Prüfen der Datenströme für eine echte Deep Packet Inspektion und Manipulation. Was einem dann keine Grenzen setzt, bei all dem was man mit einem ADC noch anstellen kann. Gerade die kommenden Herausforderungen an eine IT mit Verschlüsselung und IPv6 auf der externen Seite lassen ADC’s in einem völlig neuen Licht erscheinen. Auch gilt es beim Einsatz von ADC’s noch folgenden Aspekt zu bedenken; das kommende Protokoll http/2 und ggf. QUIC. Hier ist es dann auch ausreichend dies „nur“ auf dem ADC zur Verfügung zu stellen und zu den realen Servern weiterhin http zu sprechen. Denn je nach eingesetzten Systemen ist ein Wechseln auf einen Webserver die die neuen Protokolle unterstützt auch mit einem Upgrade der Distribution verbunden. Was in vielen Fällen ja gar nicht so einfach ist. Vor allem wenn man hier die komplette Applikation auf die neue Plattform migrieren und natürlich dann komplett testen muss. Den Webserver „mal eben“ austauschen geht einfach nicht und die Versionen die die neuen Protokolle unterstützen muss es ja auch geben. Das http/2 Modul für Apache ist noch im Entwicklerstatus und Nginx will bis Ende 2015 eine entsprechende Version bringen. Bei lighttpd gibt es dazu noch keinen Status.
Für alle die sich fragen, was QUIC für ein Protokoll ist, hier eine wirklich kurze Erklärung:
QUIC ist ein von Google entwickeltes Protokoll, welches statt TCP auf UDP setzt und so gesehen eine Weiterentwicklung auf Basis von TCP-TLS-SPDY ist. QUIC hat eine Forward-Error-Correction, ein verbessertes Multi-Plexing der Anfragen in einer Verbindung und beherrscht Connection Migration. Zudem hat QUIC sehr geringe Latenz beim Aufbau und vor allem beim Wiederverbinden da es auf UDP basiert. Google plant das Protokoll bei der IETF einzureichen. Sollte sich dann QUIC als Standard etablieren, stehen die Chancen gut, dass TCP-Verbindungen bei Webzugriffen verdrängt wird. Was viele vielleicht nicht wissen, QUIC ist schon seit August 2013 im Browser Chrome und bei den Google Webservices im Einsatz. Darunter sind auch Youtube, Blogger.com oder chromium.org. Wer schauen möchte, was sein Chrome schon alles per QUIC so macht, kann dies hier sehen: chrome://net-internals/#quic , wer mehr über QUIC wissen möchte, findet weitere Informationen hier.
[Update]
Bei der aktuelle Firefox Version 39 haben die Entwickler SSLv3 und RC4 komplett entfernt.
[Update]
Google hat den QUIC bei der EITF eingereicht. Aber nur als „individuellen Entwurf“, Hintergrund ist hier, dass so Google die Kontrolle über weitere Änderung für sich behält und nicht von den formalen Vorgängen beim IETF abhängig ist.
Wie immer, wenn Sie Fragen zum Thema haben, stehen wir wie gewohnt zur Verfügung.