“Finger weg von HTTPS?” – Ist SSL Interception fahrlässig?

Kürzlich wurden wir von einem Reseller zu unserer Meinung zu folgendem Heise-Artikel gefragt: Sicherheitsforscher an AV-Hersteller: “Finger weg von HTTPS”.

Der Artikel klingt zugegebenermassen wirklich nicht gerade vertrauenserweckend. Die Fortigates sind im Artikel namentlich nicht benannt. Und eine Konfigurationsmöglichkeit haben wir auf der Fortigate hierfür auch nicht gefunden. So stellt sich natürlich die Frage, wie die Fortigate sich bei der SSL Interception genau verhält. Ist es “fahrlässig” die SSL Interception (“deep inspection”) der Fortigate zu aktivieren? Führt diese Konfiguration zu “dramatischen Sicherheitsproblemen”?

Uns blieb nichts anderes übrig, als den guten alten Packetsniffer hervor zu kramen, eine Fortigate mit dem SSL-Profile “Deep Inspection” zu versehen und dann die SSL Negotiation sowohl beim Client als auch auf dem WAN-Interface der Fortigate (also da, wo die Fortigate die eigene SSL Verbindung aufbaut) mitzusniffen.

Resultat: die Fortigate übernimmt die Verbindungsparameter aus dem “Hello” vom Client. Startet der Browser vom Client eine SSL Verhandlung mit TLS 1.0, baut auch die Fortigate eine TLS 1.0-Verbindung auf. Kommt der Browser mit 12 Cipher Suites daher, übernimmt die Fortigate die gleichen 12 Cipher Suites. Werden dagegen 24 Cipher Suites vom Browser offeriert, übernimmt auch das die Fortigate.

Einzig Algorithmen, die die Fortigate nicht kennt, übernimmt sie in ihrer eigenen Verbindung Richtung Server nicht (macht ja noch Sinn). Das heisst gleichzeitig aber auch, dass eine uralte FortiOS Version unter Umständen alle neueren Verschlüsselungs-Algorithmen, welche ein moderner Browser anbietet, nicht übernimmt und nur die alten Algorithmen Richtung Server anbietet.

Soviel mal zu unseren eigenen Tests.

Folgt man im Artikel dem Link auf die Quelle The Security Impact of HTTPS Interception, so findet man doch noch einen Hinweis auf die Fortigates. Das Paper bestätigt, dass die Fortigates (v5.4.0) Server-Zertifikate validiert, TLS 1.2 und aktuelle Algorithmen unterstützt. Allerdings werden auch RC4 Algorithmen übernommen und die Fortigates bekommen ein C-Grade verabreicht. Ja, sofern der Client RC4 offeriert, übernimmt die Fortigate das auch in Ihrer SSL-Verhandlung. Der C-Grade wird vergeben, da SSLv3 noch unterstützt wird – ja, sofern der Client das so will… Und die angegebene Logjam-Vulnerability ist im v5.4.1 bereits gefixt.

Unser persönliches Resümee: Entwarnung!

Die angesprochenen Probleme aus dem Artikel gelten nicht für die Fortigates – sofern man mit einer halbwegs aktuellen FortiOS Version arbeitet. Der Einsatz der SSL Interception durch die Fortigate erzeugt keine “zusätzlichen” Sicherheitsprobleme. “Zusätzlich”? Bietet der Client ein paar altersschwache Algorithmen in der SSL Verhandlung an, werden diese von der Fortigate übernommen, sofern sie diese noch unterstützt….

Um aber auch ein paar kritische Worte zuzulassen – es wäre ja schon schön, könnte man auf der Fortigate konfigurieren, ob alterschwache Protokolle oder Algorithmen wirklich übernommen werden, wenn der Client diese anbietet. Beim SSL-Offloading vom Virtual Server kann das schliesslich auch konfiguriert werden, warum also nicht bei der SSL-Interception? Klar – das Gegenargument ist natürlich, dass es immer noch Webserver gibt, die nur diese altersschwachen Algorithmen zulassen. Dann würde eine entsprechend konfigurierte Fortigate hier die SSL-Verbindung nicht aufbauen können. Aber dennoch – schön wäre es, könnte das der Firewall-Admin selber entscheiden.

 

0 Responses to ““Finger weg von HTTPS?” – Ist SSL Interception fahrlässig?”


  • No Comments

Leave a Reply