8

Im Februar werden wir einige veraltete Verschlüsselungs-Technologien für unsere Webseiten deaktivieren. Dadurch werden bestimmte ältere Browser und Systeme nicht mehr in der Lage sein, auf diese Webseiten zuzugreifen – eine kurze Liste gibt es weiter unten in diesem Artikel. Wenn Sie den folgenden Link aufgrund einer HTTPS-Fehlermeldung in Ihrem Browser nicht aufrufen können, sollten Sie dringend Ihren Browser bzw. Ihr System aktualisieren:

ssltest.sipgate.de

Von SSL zu TLS: Verschlüsselung und Sicherheitslücken

In den vergangenen Jahren haben immer wieder Sicherheitslücken Aufmerksamkeit erregt, die in Verbindung mit der verschlüsselten Übertragung von Webseiten standen. Das dabei zwischen Browsern und Servern eingesetzte Protokoll nennt sich HTTPS (also die sichere Variante von HTTP), was allerdings das Rad nicht neu erfindet: die eigentliche Verschlüsselung in diesem Protokoll übernimmt eine ganze weitere Protokollfamilie, die in älteren Versionen auf den Namen SSL (Secure Sockets Layer) und heute auf den Namen TLS (Transport Layer Security) hört. Dabei wird zwischen den Varianten SSL Version 2 und 3 sowie TLS Version 1.0, 1.1 und 1.2 unterschieden. Während des Verbindungsaufbaus wählen Browser und Webserver nun die jeweils beste Version aus, die beide Seiten unterstützen.

Warum Updates so wichtig sind

In der Vergangenheit sind verschiedene Sicherheitslücken aufgetaucht, die zuletzt 2015 das Deaktivieren der älteren SSL Varianten erforderlich machten – ansonsten wäre nicht mehr zu gewährleisten, dass die Verschlüsselung nicht ausgehebelt oder dem Besucher nicht eine falsche Webseite untergeschoben werden könnte. Da unsere Kunden auch Zahlungsdaten über unsere Webseiten eingeben, ist eine bekanntermaßen ausgehebelte Verschlüsselung für uns natürlich keine Option.

Wo ist denn nun der Haken an dieser Sache? Wenn ein Hersteller ein Handy oder einen Internet Browser auf den Markt bringt, verpflichtet er sich in der Regel, für einen gewissen Zeitraum Aktualisierungen zu veröffentlichen. Natürlich läuft dieser Support irgendwann aus und der Benutzer muss dann entweder mit einem potentiell unsicheren Gerät bzw. unsicherer Software leben oder sich etwas Neues anschaffen. Das bedeutet aber auch, dass Software, die vor einigen Jahren und damit beispielsweise vor TLS 1.2 entwickelt wurde, diese neue Protokoll-Variante nie beherrschen wird. Für uns als Webseitenbetreiber bedeutet das nun, dass wir mit der Abschaltung einer alten Protokoll-Version potentiell Kunden zu ihrem eigenen Schutz aussperren, während sich für diejenigen mit aktuellen Systemen oder Browsern gar nichts ändert.

Muss ich updaten?

Das PCI Security Council, das die Sicherheits-Standards für Kreditkartendaten speichernde oder verarbeitende Unternehmen festlegt, hatte ursprünglich angekündigt, dass TLS 1.0 ab Mitte 2016 nicht mehr im Einsatz sein darf. Nach einer Überarbeitung dieser Angabe wurde die Deadline auf das Jahr 2018 verschoben. Dennoch wird empfohlen, TLS 1.0 so schnell wie möglich zu deaktivieren, da sich auch hinter dieser Technologie potentiell angreifbare Mechanismen verbergen. Dieser Empfehlung wollen wir nun auch folgen. TLS 1.1 bzw. 1.2 sind derzeit die bevorzugte Wahl und werden auch großflächig unterstützt. Nach unserer derzeitigen Einschätzung werden die folgenden Geräte bzw. Browser unsere Webseiten nach der Umstellung nicht mehr aufrufen können:

  • Android mit Version 4.3 und älter
  • Internet Explorer unter Windows Vista und älter
  • Internet Explorer 8/9/10 unter Windows 7/8 (in Standardkonfiguration)
  • Safari unter OS X älter als Mavericks
  • Linux-Distributionen, die mit OpenSSL Versionen unter 1.0.0 arbeiten
    • Debian Squeeze (6.0) und älter
    • Ubuntu Lucid Lynx (10.04 LTS) und älter
    • CentOS 5 und älter

Unter Windows XP (seriously?) oder Vista ist es natürlich möglich, auf alternative Browser auszuweichen – etwa aktuelle Versionen von Mozilla Firefox oder Google Chrome. Wer Anwendungen mit Java 7 betreibt, bemüht standardmäßig nur TLS 1.0. Das lässt sich aber durch Kommandozeilen-Parameter auch zu TLS 1.1 und 1.2 ändern. Generell ist fehlende Unterstützung für TLS 1.1 oder 1.2 aber auch ein gutes Zeichen dafür, dass das System dringend aktualisiert oder ausgetauscht werden sollte.

Wenn man sich die Zugriffs-Statistiken unserer Webseiten anschaut, betrifft die Umstellung nur sehr wenige Kunden – hier exemplarisch die Zugriffe durch den Internet Explorer 7.0 der letzten 30 Tage:

browser-ie70

Wie sieht die Zukunft aus?

Derzeit befindet sich der Standard für TLS 1.3 in der Finalisierung und die aktuellen Beta-Versionen von Mozilla Firefox und Google Chrome unterstützen dieses Protokoll bereits. Auf der Serverseite hat beispielsweise der Dienst Cloudflare bereits TLS 1.3 für seine Kunden aktiviert. Für Technik-Fans gibt es einen detaillierten Ausblick auf TLS 1.3 in diesem englischen Vortrag des 33C3 (Chaos Communication Congress 2016).

Wer seine Lieblings-Webseite oder seinen eigenen Webserver auf unterstützte Protokolle und Einstellungen testen will, kann den SSL Server Test von Qualys SSL Labs benutzen. Die Fähigkeiten des eigenen Browsers kann man hier auf den Prüfstand stellen – beide Seiten sind allerdings nur in Englisch verfügbar.

8 Kommentare

Sehr wichtige Angelegenheit, die oft leiden nicht ausreichend gewürdigt wird.

Soll in dem Zug auch HSTS aktiviert werden? Das gibt dann bei SSLLabs ein „A+“ statt ein „A“. 🙂

Hallo Daniel,

HSTS haben wir auch auf dem Schirm und es ist im Moment für https://app.sipgate.com und https://login.sipgate.com bereits aktiv. Das Thema ist uns wohl für die SSL Test Seite durchgegangen, unser Fehler 🙂

Weitere Möglichkeiten wie DANE, DNSSEC oder Certificate Pinning (alias HPKP) haben wir zu mindest noch nicht kurzfristig eingeplant.

Grüße, Rudi

Hallo Klaus, Hallo Westphal,

leider kann man IP-Telefone und Browser noch nicht ganz vergleichen: Während sich Browser heute weitgehend selbst aktualisieren und die Lebensdauer von Mobiltelefonen mit alter Software auch eher begrenzt ist, sieht es da bei IP-Telefonen etwas anders aus. Die meisten Menschen aktualisieren ihre Firmware nicht regelmäßig, der Hersteller hat das Gerät bereits abgekündigt und nur wenige Hersteller arbeiten mit automatischen Update Funktionen.

Dennoch haben einige Endgeräte Verschlüsselung grundsätzlich aktiviert – das heisst, sobald wir es freischalten, würden sie es auch nutzen. Zu alte Software kann dann verschiedene Szenarien bedeuten: Die TLS Implementierung ist schlicht zu alt und kann sich nicht mit der Gegenseite einigen. Die TLS Implementierung ist zwar aktuell genug, aber fehlerhaft. Das Telefon besitzt eine veraltete Liste und vertraut der Certificate Authority, die unser Zertifikat signiert hat nicht (und generell haben die meisten Endgeräte deutlich eingeschränktere CA Listen als die üblichen Browser). In allen Fällen bedeutet das Ergebnis: das Endgerät ist offline und kann nicht mehr telefonieren, bis der Kunde entweder die Software aktualisiert, das Endgerät ersetzt oder die Verschlüsselung deaktiviert.

Neben dieser technischen Hürde gibt es natürlich auch das Problem, die Art bzw. Umfang der Verschlüsselung korrekt an Kunden zu kommunizieren. Wenn jemand von seinem Endgerät weiss, dass es die Verbindung zu sipgate verschlüsselt aufbaut, sagt das ja noch nichts über einen tatsächlich getätigten Anruf aus, der im Zweifel seinen Weg über mehr als einen weiteren Carrier zum Empfänger findet.

Natürlich ist es besser, einen Teil zu verschlüsseln als gar nichts – das bringt uns aber wieder zum ersten Problem zurück. Verschlüsselung ist für uns damit natürlich nicht vom Tisch, wir testen weiter. Aktuell ist das zum Beispiel bei unserem Trunking Produkt in England der Fall.

Ich hoffe, das wirft etwas Licht auf dieses leider eher schwierige Thema.

Grüße, Rudi

SIP+TLS und SRTP würde ich auch gerne testen. Man könnte z.B. wie damals bei IPv6 das per Opt-In mittels separater Subdomain verfügbar machen, so dass nur Kunden, die den Hostnamen im Telefon ändern, über den Registrar mit Verschlüsselung rausgehen.

ja, Verschlüsselung ist sinnvoll und wichtig – auf diesem Weg kann sie ausgerollt werden, ohne irgendjemanden auszusperren – das ist ja wohl die Befürchtung…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*