IT-Sicherheit für Privatanwender: Grundsätze: Transportverschlüsselung

Hoch zum Abschnitt Grundsätze

Wir haben bereits darüber gesprochen, was Verschlüsselung bedeutet. Im Zusammenhang mit TLS wird aber oftmals über Transportverschlüsselung gesprochen und auch den Begriff Ende-zu-Ende-Verschlüsselung findet man häufig.

Transportverschlüsselung im Internet

Das grundlegende Problem des Internets ist, dass standardmäßig sämtliche Kommunikation unverschlüsselt erfolgt. Dies liegt an der historischen Entwicklung, während der man den Fokus auf Funktion und nicht auf Sicherheit legte. Ein Angreifer könnte jedes einzelne Paket im Internet im Klartext sehen, beliebig verändern oder nochmals senden (Replay-Angriff). Die Schutzziele Vertraulichkeit, Integrität und Authentizität sind nicht erfüllt.

Seit Mitte der 90er Jahre gab es SSL (Secure Sockets Layer) und etwa aus derselben Zeit stammt IPsec (Internet Protocol Security). Der SSL-Nachfolger TLS sowie IPsec stellen bis heute eine sogenannte Transportverschlüsselung dar. Hierbei werden IP-Pakete zwischen zwei Kommunikationspunkten verschlüsselt. Diese Punkte müssen aber nicht gleichzeitig die tatsächlichen Endpunkte der Kommunikation sein. In dem Fall spricht man von einer Ende-zu-Ende-Verschlüsselung.

TLS als Transportverschlüsselung

ISO-OSI-7-Schichten-Modell

TLS kennen sicherlich die meisten Privatanwender als grünes Schlosssymbol bzw. https:// in ihrem Webbrowser. Je nach Netzwerk-Referenzmodell findet diese Verschlüsselung als Teil der Transportschicht bzw. Anwendungsschicht statt.

Grundidee

Die Grundidee ist, dass der Client zuerst an den Server einige Parameter für die Verschlüsselung und unterstützte Cipher-Suites sendet. Der Server antwortet dann mit der Cipher-Suite, die er ausgewählt hat, sendet ebenfalls Parameter sowie sein digitales Zertifikat zurück. Der Client überprüft die Gültigkeit des Zertifikats (Gültigkeitszeitraum, Signatur der CA, Widerruf, Domainname usw.). Wenn beide Seiten zufrieden sind, wird nach dem asymmetrischen Schlüsselaustausch die symmetrische Verschlüsselung gestartet.

Vorteilhaft ist hierbei, dass TLS je Anwendung festlegbar ist. Im Webbrowser bedeutet dies, dass jede Verbindung zwischen Client und Server mit anderen Parametern und anderen Schlüsseln ausgehandelt werden kann. Weiterhin ist es möglich, TLS als Basis für höhere Protokolle zu nutzen. Außerdem wird TLS als weltweit verbreiteter Standard von allen gängigen Betriebssystemen und Webbrowsern unterstützt.

Nachteile ergeben sich vor allem durch unsichere Cipher-Suites und veraltete Protokolle. Sowohl Client als auch Server müssen letztendlich moderne Protokolle und Cipher-Suites zulassen, damit die Sicherheit der Transportverschlüsselung nicht beeinträchtigt wird. Daneben verursacht TLS zusätzlichen Overhead, was allerdings bei modernen Computern nur Auswirkungen im Bereich von Millisekunden hat.

Cipher-Suites

Wichtiges Element von TLS sind sogenannte Cipher-Suites. Diese definieren einzelne Algorithmen für:

• Schlüsselaustausch (bspw. ECDHE)
• Nachweis der Authentizität (bspw. ECDSA oder RSA)
• Verschlüsselung (bspw. AES256-GCM oder ChaCha20)
• Integritätssicherung (bspw. SHA-384 oder Poly1305)

Die einzelnen Algorithmen können dabei nicht beliebig kombiniert werden, sondern kommen als „Paket“. Ein Beispiel ist ECDHE-ECDSA-CHACHA20-POLY1305, ein weiteres ECDHE-ECDSA-AES256-GCM-SHA384.

Je nach Client kann man selbst konfigurieren, welche Cipher-Suites der Client generell dem Server anbietet. Hier ist es empfehlenswert, unsichere Cipher-Suites zu deaktivieren. Allerdings kann dies dazu führen, dass man sich mit vermeintlich unsicher konfigurierten Servern nicht mehr verbinden kann.

Sicherheit von TLS

Es gibt viele Angriffe auf TLS und SSL, die mehr oder weniger bekannt geworden sind. Unter anderem BREACH, POODLE, Heartbleed, CRIME und Lucky13. Es gibt einen RFC, der diese Angriffe bis Anfang 2015 zusammenfasst. Teilweise waren Angriffe aufgrund fehlerhafter Implementierung möglich, teils aber auch wegen Protokollschwächen oder nicht mehr sicheren Algorithmen.

Als Privatanwender kann man letztendlich nur seine Software (wie den Webbrowser) aktuell halten, weil diese im Rahmen der regulären Updates neue Protokollversionen und Cipher-Suites unterstützen oder diese deaktiviert werden. Auf Serverseite hat man keinen Einfluss, wenn man nicht selbst Betreiber ist.

Die kommende Version 1.3 von TLS ist die erste, die ohne unsichere Algorithmen kommen wird (MD5, SHA-1, RC4, AES-CBC wurden entfernt). Daneben wird es weitere Verbesserungen der Sicherheit und weniger Overhead geben. Allerdings ist es (Stand 2018) ungewiss, ob TLS 1.3 wieder „unsicherer“ gemacht wird bzw. wann es überhaupt erscheint. Da bis heute noch viele Server nicht einmal TLS 1.2 anbieten (laut BSI die einzig empfehlenswerte Protokollversion) oder noch unsichere Protokollversionen/Cipher-Suites zulassen, kann man sich auch fragen, wie lange es dauern wird, bis TLS 1.3 wirklich der Standard bei der Transportverschlüsselung wird.

Widerruf von Zertifikaten und Privatsphäre

Wir haben bisher über digitale Zertifikate gesprochen. Ein Beispiel dazu war, dass Person B (Bob) bei Person A (Alice) Alkohol kaufen will und sich mit einem Dokument ausweisen muss. Das Dokument wurde von einer Behörde ausgestellt, die zu einem Staat gehört. Obwohl Alice Bob nicht vertraut, vertraut sie der Behörde und Bob darf den Alkohol kaufen. Genauso ist es bei digitalen Zertifikaten: Obwohl der Client (Webbrowser) den Server nicht kennt, vertraut er seinem öffentlichen Schlüssel auf einem Zertifikat, da der Client der Zertifizierungsstelle vertraut, die diesen Schlüssel mit dem eigenen signiert hat.

Allerdings kann es ein Problem geben: Ein Angreifer erhält den privaten Schlüssel von Bob (Server). Wie wir bereits erklärt hatten, werden diese privaten Schlüssel heutzutage nicht mehr für die Verschlüsselung verwendet, sondern nur, damit Bob seine Identität gegenüber Alice nachweisen kann. Ein Angreifer kann sich folglich als Bob ausgeben. Wieder im ungefähren Vergleich: Bob verliert seinen Ausweis, der Angreifer findet ihn und gibt sich damit als Bob aus. Der Ausweis bzw. der öffentliche Schlüssel (und somit das Zertifikat) müssen widerrufen werden.

Hier gibt es derzeit keine Universallösung. Eine Idee waren Certificate Revocation Lists (CRL). Hierbei trägt die Zertifizierungsstelle widerrufene Zertifikate auf eine Liste ein. Allerdings muss nun jeder Client erst einmal diese Liste abrufen und nachsehen, ob das gezeigte Zertifikat widerrufen ist. Dies dauert lange, verursacht viel Overhead und erfordert, dass die Liste sofort aktualisiert wird, wenn irgendjemand im Internet sein Zertifikat widerrufen hat.

Die nächstbessere Lösung ist das Online Certificate Status Protocol (OCSP). Die Idee ist hier, dass der Client vom Server das Zertifikat erhält und dann bei einem Dritten (OCSP-Responder) nachfragt, ob genau dieses Zertifikat noch gültig ist. Der Vorteil zu CRLs ist offensichtlich: wenig Overhead, schnelle Antworten und widerrufene Zertifikate können unmittelbar in einer Datenbank vermerkt werden. Es gibt aber auch Nachteile: Einerseits muss sichergestellt werden, dass der OCSP-Responder sofort in Echtzeit antwortet, und andererseits offenbart der Client bei jeder Anfrage seine IP-Adresse und seinen Kommunikationspartner gegenüber dem OCSP-Responder.

Hier setzt Online Certificate Status Protocol stapling an. Bei dem Verfahren übernimmt der Server periodisch die Abfrage seiner Zertifikatsinformationen bei einem OCSP-Responder und erhält eine signierte Antwort mit Zeitstempel. Sobald ein Client bei der TLS-Aushandlung das Zertifikat vom Server erhält, „heftet“ dieser die vom OCSP-Responder signierte Antwort an. Der Client muss nicht mehr direkt mit dem OCSP-Responder kommunizieren und auch nicht auf ihn warten.

Allerdings bleibt das Problem, dass der Client gar nicht weiß, ob der Server OCSP stapling unterstützt. Der Client muss den Server aktiv danach fragen. Hier setzt OCSP Must-Staple an. Dies ist eine Markierung auf dem Zertifikat, welche von der Zertifizierungsstelle beim Ausstellen gesetzt wird. Wenn der Client das Zertifikat mit dieser Markierung erhält, weiß er, dass OCSP stapling unterstützt wird und eine gültige OCSP-Antwort vom Server gesendet werden muss. Erfolgt diese nicht, wird die Verbindung abgebrochen.

Zwei Probleme bleiben: Der Server muss OCSP einschalten und der Client muss die OCSP-Antwort beachten. Derzeit beachtet beispielsweise Firefox OCSP-Antworten, Chrome/Chromium ignorieren diese aber.

Certificate Transparency

Eine andere Idee verfolgt Certificate Transparency (CT). Ein System aus Logging, Überwachung und Überprüfung soll sicherstellen, dass Clients und Server versehentlich oder böswillig ausgestellte Zertifikate erkennen können. Dabei werden alle von einer Zertifizierungsstelle ausgestellten Zertifikate revisionssicher protokolliert.

IPsec als Transportverschlüsselung

IPsec ist eher unbekannt, da es im Privatbereich nicht so verbreitet wie TLS ist. Es ist dabei im Tunnel- oder im Transport-Modus verwendbar. Man kann entweder nur die Schutzziele Integrität und Authentizität erfüllen (AH) oder zusätzlich auch Vertraulichkeit (ESP). Während IPsec bei IPv4 noch eine eigene Schicht zwischen Internetschicht und Transportschicht darstellt, ist es in IPv6 eine Header-Erweiterung.

IPsec kann ohne Weiteres keine Schlüssel mit dem Kommunikationspartner austauschen. Dies erfolgt entweder durch manuelle Konfiguration beider Kommunikationspartner oder durch Protokolle wie ISAKMP.

Tunnel-Modus

Vergleich zwischen Transport- und Tunnelmodus

Wird IPsec im Tunnel-Modus eingesetzt, erfolgt die IPsec-geschützte Kommunikation zwischen zwei Routern/Gateways. Dies hat den Vorteil, dass einzelne Clients, die sich mit den Routern/Gateways verbinden, keinerlei zusätzliche Konfiguration benötigen. Für sie ist IPsec transparent, wird also nicht wahrgenommen. Sinnvoll ist dieser Modus in Unternehmen, die zwischen zwei festen Unternehmensnetzwerken eine geschützte Verbindung herstellen wollen.

Im Unterschied zum Transport-Modus sieht ein Angreifer zwischen den Gateways nur verschlüsselte IP-Pakete (wenn ESP verwendet wird) und die jeweiligen IP-Adressen der Gateways. Er kann auf diese Weise nicht direkt sehen, welche Clients in den Netzwerken hinter den Gateways kommunizieren. Werden Pakete nur signiert (AH), kann der Angreifer weiter alle Paketinhalte inklusive IP-Adressen der Clients sehen.

Transport-Modus

Beim Transport-Modus kommunizieren zwei Endpunkte direkt miteinander. Dies ist zum Beispiel sinnvoll, wenn ein Administrator direkt auf einen Server zugreifen will, um diesen zu konfigurieren. Offensichtlich ist die Notwendigkeit, dass beide Endpunkte entsprechend für IPsec konfiguriert werden müssen. Hier sieht der Angreifer weiter, wer mit wem kommuniziert, da die IP-Adressen sowohl mit ESP als auch mit AH sichtbar bleiben.

Ende-zu-Ende-Verschlüsselung

Neben der vorgestellten Transportverschlüsselung gibt es auch eine Ende-zu-Ende-Verschlüsselung. Hintergrund ist, dass bei TLS die Verschlüsselung immer nur zwischen zwei Stationen erfolgt.

Beispiel: Alice und Bob nutzen einen Instant Messenger und sind jeweils auf anderen Servern registriert. Wenn Alice an Bob eine Nachricht senden will, sendet ihr Client über eine TLS-geschützte Verbindung die Nachricht an ihren Server A. Dieser Server sendet die Nachricht über eine unverschlüsselte Verbindung an Server B. Bobs Client bekommt dann wieder die Nachricht über eine TLS-geschützte Verbindung von seinem Server B. Selbst wenn alle Verbindungen in diesem Szenario durch TLS gesichert wären (Client Alice > Server A > Server B > Client Bob) können beide Server die Nachricht im Klartext sehen.

Besser ist es, wenn Alice und Bob ihre Kommunikation mit einer weiteren Schicht verschlüsseln, sodass nur die beteiligten Clients (Endpunkte) in diesem Szenario die Nachricht entschlüsseln können. Hierzu sind beispielsweise GnuPG im E-Mail-Bereich oder OTR/Signal-Protokoll im Instant-Messenger-Bereich geeignet.

Zusammenfassung

Während TLS vielseitig einsetzbar und verbreitet ist, kann man mit IPsec vor allem zwei entfernte Netzwerke sicher miteinander verbinden. Wie alle Verschlüsselungsverfahren müssen aber alle beteiligten Kommunikationspartner die verwendeten Verfahren unterstützen. Hier liegt es besonders in den Händen von Serverbetreibern, dass diese moderne TLS-Protokolle und Cipher-Suites anbieten.

Dabei darf man nicht vergessen, dass eine Transportverschlüsselung nicht notwendigerweise eine Ende-zu-Ende-Verschlüsselung darstellt und dass der Widerruf von Zertifikaten bei TLS ein nicht einheitlich gelöstes Problem darstellt, welches auch zum Tracking missbraucht werden kann.

Weiterführende Links

• HTTPS Certificate Revocation is broken, and it’s time for some new tools, abgerufen am 12.2.2018
• CryptCheck, Tool zur Überprüfung von Cipher-Suites einer Webseite, abgerufen am 12.2.2018
• Empfehlungen von Mozilla zur Konfiguration von TLS, abgerufen am 12.2.2018

Weiterführende Literatur

• Aumasson: Serious Cryptography – A Practical Introduction to Modern Encryption (Kapitel 13). ISBN 978-1-59327-826-7, No Starch Press, 2018.