Nachdem die Kommentare zum Thema SSL Decryption eher allgemeiner Natur waren, jetzt einmal die konkrete Umsetzung. Zunächst gilt es dem System ein geeignetes Zertifikat aus zu stellen. Da es sich üblicherweise um kommerzielle Umgebungen mit einer Zertifizierungsstelle handelt, benötigt man zunächst einen “Certificate Signing Request” – CSR. Den kann man in den “Certificates” unter Device stellen. Die Details findet ihr hier.

Der Request – Dialog sieht dann in etwa wie folgt aus:

Gleich was hier eingetragen wird, auf jeden Fall NICHT Certificate Authority anwählen. Der CSR liegt dann in dem Zertifikat Store vor und kann durch Export abgespeichert werden. Den CSR nimmt man

 

jetzt bei der Zertifizierungsstelle der Wahl und stellt ein Zertifikat aus. In den meisten Unternehmen wird dies der Zertifizierungs- Dienst von Active Directory sein, der über seine Web- Schnittstelle https://123.123.123.123/certsrv angesprochen werden kann.

Das so ausgestellte Zertifikat ist damit ein “Proxy Zertifikat” und sollte jetzt in eine saubere Zertifikat Hierarchie eingebettet werden. Das hat insbesondere den Vorteil, dass die Palo Alto Firewall in Zukunft Zertifikate selbst signieren, ausstellen oder verlängern kann. Administrativ eine große Erleichterung.

Dazu kann man auf dem Zertifikat- Server dessen Root- Zertifikat vollständig – verschlüsselt abspeichern und in der Palo Alto importieren. Unterhalb diesen Zertifikats kann dann wiederum das SSL Decrypt Zertifikat importiert werden. Die Zertifikat- Hierarchie sollte dann in etwa wie folgt aussehn:

Wichtig ist hier auch die Angabe der Verwendung der Zertifikate als “Forward Trust” bzw. “Forward Untrust” da hiermit definiert wird, diese Zertifikate auch zur SSL Entschlüsselung verwendet werden.

Der Vorteil dieser Variante ist, dass es eine “Trusted Authority”, also eine vertrauenswürdige Instanz im Unternehmen gibt, die auf allen Clients bekannt ist und sofern die jeweiligen Anwendungen das Root Domänen Zertifikat aus dem System eigenen Zertifikat- Speicher akzeptieren auch die Proxy Zertifikate ohne Fehlermeldung akzeptieren. Ist dies nicht der Fall, kommen die Internet- typischen Fehlermeldungen, dass eine “unsichere Verbindung” aufgebaut wird.

Diesen Fehler kann man gegebenenfalls im Browser oder sonstiger Anwendung akzeptieren und bestätigen.

Mehr dazu in den Caveats. Grundsätzlich kann man jedoch an dieser Stelle immer das Zertifikat kontrollieren und sollte dann ein in der Organisation erstelltes Zertifikat finden. Auch hilft der Gedanke hier ein extern Zertifiziertes öffentliches Zertifikat zu erwerben und verwenden nicht wirklich weiter, da zumindest die Innenseite der Proxy Verbindung nicht auf die öffentlichen Adressen verweisen wird.

Zur Vorbereitung der Policies müssen unter den Objects zwei Decryption Profiles angelegt werden. Ein “standard”, das eigentlich keine aktivierten Elemente enthält. Für gelegentliche Verschärfung der Regeln empfiehlt sich noch ein “strict”, in dem extern abgelaufene Zertifikate oder nicht vertrauenswürdige Herausgeber ausgeklammert werden.

Da in den Decryption Policies auch auf die URL Kategorien zurück gegriffen wird, bietet es sich ebenfalls an, unter den “Custom Objects” gleich “URL Categories” an zu legen, in welchen bekannte und für die Entschlüsselung nicht notwendige Domains eingetragen werden. Hier macht eine gewisse Selektivität durchaus Sinn, da die Hostlisten exportiert und importiert werden können und so auch eine einfache Wiederverwendung in verschiedenen Szenarien gegeben ist.

Zu empfohlenen Ausnahmen komme ich auch hier in den Caveats. Typische Kandidaten sind jedoch Tracker- Anwendungen von Paketdiensten, Einschlägige Kommunikationsdienste (Webex, Citrix, …)

Die Custom URL Objects sehen dann so oder so ähnlich aus:

 

 

Mit diesem Rüstzeug kommt man endlich dazu, die eigentlichen Decryption Policies ein zu stellen. Die Liste ist eigentlich recht kurz. Entschlüssele alles was SSL verwendet. Punkt.

Vorweg die Einstellung der nicht zu entschlüsselnden Ausnahmen. Ich würde auf jeden Fall financial-services und healtcare mit ausklammern. Andere Kategorien halte ich persönlich für etwas zu großflächig. Da man über Source-IP einzelne Clients als Testsysteme heran ziehen kann, bietet sich an die entsprechenden Kategorien selbst auf zu bauen und hier sehr sparsam eine Anwendungslandschaft aus zu loten.

In vielen Fällen gibt es hier dann auch Client seitig Schwierigkeiten mit der Akzeptanz des Enterprise Self Signed Zertifikates. Dabei gibt es vier mögliche Fälle.

1. Der Client akzeptiert das Enterprise Root signierte private Zertifikat und alles ist ok. z.B. der Internet Explorer.
2. Der Client akzeptiert das Enterprise Root signierte private Zertifikat zunächst nicht und bietet mir die Möglichkeit das Root Zertifikat als Trusted Authority in den Zertifikat- Speicher der Anwendung zu laden um danach die Zertifikate zu akzeptieren. z.B. Firefox.
3. Der Client akzeptiert das Enterprise Root signierte private Zertifikat nicht und meldet eine “unsichere Verbindung” die man nach Kontrolle des Zertifikates – ist es auch mein eigenes – akzeptieren kann. Das kann auch auf der Commando- Zeile erfolgen. z.B. Google Drive
4. Werden all diese Methoden nicht akzeptiert muss gegebenenfalls die Ausnahme Kategorie in der No Decrypt Policy fest halten.

Details hierzu dann ebenfalls in den Caveats.

Damit hat man dann zwei Decryption Policies. Alles was nach außen geht wird Decrypted und vorweg, die Policy, welche auf URL Basis regelt welche Ausnahmen nicht Decrypted werden.  Thats it.

Schaltet man die Decrytion dann scharf, sollte man vorweg den User Helpdesk informieren und sich etwas Zeit frei halten. Es finden sich immer in den ersten zwei – drei Tagen Ausnahmen die eine Gründliche Evaluierung nicht zu Tage gefördert hat. Hier ist dann meistens kurzfristiges nachjustieren notwendig.

Kyp.F.