Die Best Practice beim Einrichten klang zu schön um wahr zu sein. So einfach ist es dann auch tatsächlich nicht. Alleine die Tatsache, dass in den Screenshots drei Decryption Policies definiert sind, obwohl best Practice eigentlich zwei genügen, sollte stutzig machen.
Die Ausnahmen sind vielfältig und IMHO durchaus gängig. Da man nicht alle Internet Infrastruktur URLs frei geben will gehen schon die Microsoft Update Dienste auf die Bretter. Aber die einschlägigen Erfahrungen der Reihe nach: …
- Die erste Auffälligkeit ist tatsächlich dass der Internetexplorer sauber das Systemweite Domänen Root Zertifikat akzeptiert und der Firefox nur mit einem individuellen Import zu beruhigen ist. Googles Chrome hat vor der Version 39.0.2171.95 m den System Zertifikat Speicher bemüht, bemängelt aktuell aber die “unsicheren Verbindungen” – Hat die Option ein Zertifikat zu importieren, aber wir haben noch nicht das Zertifikat- Format gefunden in dem danach tatsächlich die Zertifizierung auch zieht.
- Als nächstes ging die Paket- Tracking- Anwendung von UPS auf die Bretter. Diese ist mit gar keinen Tricks zu beruhigen. Der Support von UPS ist aber in der Lage eine Reihe von Hostnamen zu nennen, die alle in das URL- Object UPS eingepflegt wurden und mit dem in der NoDecrypt- Policy funktioniert auch UPS. Aktuell gehen wir davon aus, dass dies bei Fedex, DHL und wie sie alle heißen, nicht anders sein wird.
- Microsoft Updates wurden auch blockiert. Beim googeln nach einschlägigen Erfahrungen kamen dann mehrere andere Themen hoch, die auch im Betrieb der internen Infrastruktur Schwierigkeiten nach sich ziehen. Konkret gibt es Schwierigkeiten auch mit Apples Diensten (Update, Message Push, iTunes), der Citrix Konferenz Lösung, Whatsapp, googleDrive, Dropbox und einigem mehr. Es gibt zwar eine URL- Kategorie zu Infrastructure- Services, diese öffnet aber ein Scheunentor und steht eigentlich im Widerspruch zu der Anforderung der SSL- Decryption. Einpflegen zweier neuer URL- Sammler- Objekte für Communication- Services und Update- Services. Dringend zu empfehlen sind tatsächlich die Freigaben für Microsoft und ggfs. Apple, um hier einen Shitstorm auf der Hotline zu vermeiden. Auch Whatsapp wird in meinen Umfeldern zunehmend produktiv genutzt. Bemerkenswert ist hier auch, dass die Palo Alto eigenen Update Services hier mit ein zu tragen sind und ebenfalls nicht tolerant auf die Decryption reagieren.
- Überdenken der im Unternehmen erlaubten Anwendungen, die explizit mit ihren angeforderten Hostnamen oder Domänen eingetragen werden – Verwendung von Wildcards ist Gott sei Dank möglich. Dabei gilt es die Abwägung zu treffen, wie präzise sich die Anforderungen der Anwendung eingrenzen lassen und wie sehr man dem jeweiligen Anbieter und dessen Fähigkeit seine Infrastruktur sauber zu halten, vertraut. Wenn *.microsoft.com frei gegeben wird, ist das vielleicht vertretbar. Wenn Google Drive neben *.google.com noch die kompletten dynamischen Namespaces mehrerer großer globaler Internetprovider benötigt, ist das eher ungünstig – wo mieten sich die Bösen Buben denn auch ihren Serverspace?
- Elster geht bei der Steueranmeldung auf die Bretter. Palo Alto hat noch nicht erkannt, dass sie internationale Kunden haben und dass ausländische Steuerbehörden vielleicht auch Financial Services sind. Enthalten sind die URLs www.elster.de und www.elsteronline.de jedenfalls nicht und selbst wenn man sie nachträgt funktioniert das nicht. Der Hinweis versteckt sich tief versteckt auf der Webseite der Finanzbehörden oder in der Hilfe von Elsterformular. Sucht man dort nach “Betrieb im Netzwerk” gibt es dort die “Gatewayanforderungen”. Hier finden sich mindestens vier statische IPs, die frei gegeben sein müssen. Trägt man diese in die vorhandene NoDecrypt Policy ein, würden ja nur Domänenanfragen auf diese vier IPs nicht decrypted. Das macht eine eigene No Decrypt Policy “NoDecryptElster” erforderlich in der aller Verkehr mit dem Ziel dieser IPs ausgeklammert wird. Die IPs sind:
62.157.211.58, 62.157.211.59, 193.109.238.26, 193.109.238.27. - FEDEX Werkzeuge funktionieren ebenfalls nur mit dem Eintrag einer expliziten Regel und den statischen IPs die im Kommentar- Bereich hier zu finden sind. Der Unterschied zu 5. ist, dass die dazugehörigen Hostnamen sehr wohl aufgelöst werden aber die URL Kategorie sich mit diesen Hostnamen nicht anlegen lässt. Die IPs sind:
199.81.196.22, 199.81.196.27, 199.81.197.140, 199.81.197.170, 199.81.216.140, 199.81.217.140.
Das ist eine aktuelle lose Sammlung der im “deutschen Kontext” aufgetretenen Hürden. Die gewonnene Sicherheit ist den Aufwand durchaus wert, da die Zahl der Sicherheits- bedingten Störungen in meinen Umfeldern drastisch nach unten korrigiert werden konnte.
Allerdings führt einem die Pflege der Ausnahmen noch einmal klar die Notwendigkeit einer Güterabwägung vor Augen, welche Anwendungen und welches Maß an Anwender Bequemlichkeit hier mit grundlegenden Sicherheits- Anforderungen vereinbar ist und was eben nicht. Notwendige und unabdingbare Anwendungen stehen außer Frage und lassen sich üblicherweise auch sinnvoll integrieren. Die Best Practices seitens des Herstellers, die auch von Integratoren so umgesetzt werden, brauchen hier definitiv noch ein wenig “Justage”.
Bleibt die grundsätzliche Frage warum es hier überhaupt zu solchen Empfindlichkeiten kommt. Das ist die Konsequenz aus digital signiertem Code. Da entsprechende Anwendungen der einschlägigen Anbieter (Microsoft Update, Whatsapp Services, Finanzamt) durchaus davon abhängen, dass nur frei gegebene Anwendungen sicher und damit verschlüsselt auf ihre Systeme zugreifen, sind deren Server- Zertifikate fest in den Anwendungen hinterlegt. Das ist gut so. Schließlich will ich meine Finanz- Daten nicht jemand anderem als dem Finanzamt zugänglich machen … z.B.. Die Clients enthalten also die Kontrolle, dass der Server auch der ist, der er zu sein vorgibt. Wenn also die eingehenden Server Zertifikate durch das Domänen Zertifikat ausgetauscht werden, wird das beruhigender Weise als Fehler erkannt. Das ist ein klarer Fall von miteinander konkurrierenden Sicherheitsinteressen und damit die Mehr- Arbeit zu einer vernünftigen Klärung wert.
All das entbindet dabei nicht, sich ganz bewusst darüber Klarheit zu verschaffen, welchem Kommunikationspartner ich wie sehr vertraue oder eben nicht. Bei diesem Vertrauen geht es dabei nicht nur um die inhaltliche Vertrauenswürdigkeit, sondern auch um das Vertrauen in die Umsetzungs- Stärke und Fähigkeit der Sicherheitsrichtlinien der gegenüberliegenden Seite. Schließlich sichert gerade und vor allem SSL Decryption vor gezielt und mit hohem Aufwand Maß- geschneidertem Schadcode ab, der sich gerne auch über vertrauenswürdige Verbindungen weiter tunneln möchte.
In diesem Sinnd, Kyp.F.