SSL Forward Proxy – Übersicht
Secure Sockets Layer (SSL) ist ein Protokoll auf Anwendungsebene, das Verschlüsselungstechnologie für das Internet bereitstellt. SSL, auch TLS genannt Transport Layer Security , gewährleistet die sichere Übertragung von Daten zwischen einem Client und einem Server durch eine Kombination aus Datenschutz, Authentifizierung, Vertraulichkeit und Datenintegrität. SSL stützt sich für diese Sicherheitsstufe auf Zertifikate und private und öffentliche Schlüsselaustauschpaare.
Die Serverauthentifizierung schützt vor betrügerischen Übertragungen, indem sie es einem Webbrowser ermöglicht, die Identität eines Webservers zu überprüfen. Vertraulichkeitsmechanismen stellen sicher, dass die Kommunikation privat ist. SSL erzwingt die Vertraulichkeit durch Verschlüsselung von Daten, um zu verhindern, dass unbefugte Benutzer die elektronische Kommunikation belauschen. Schließlich stellt die Nachrichtenintegrität sicher, dass der Inhalt einer Kommunikation nicht manipuliert wurde.
SSL Forward Proxy ist ein transparenter Proxy. Das heißt, es führt eine SSL-Verschlüsselung und -Entschlüsselung zwischen dem Client und dem Server durch, aber weder der Server noch der Client können seine Anwesenheit erkennen. SSL Forward Proxy stellt sicher, dass er über die Schlüssel zum Ver- und Entschlüsseln der Nutzdaten verfügt:
-
Für den Server fungiert der SSL-Weiterleitungsproxy als Client: Da der SSL-Weiterleitungsproxy den freigegebenen Vorprimärschlüssel generiert, bestimmt er die zu ver- und entschlüsselnden Schlüssel.
-
Für den Client fungiert der SSL-Weiterleitungsproxy als Server: Der SSL-Weiterleitungsproxy authentifiziert zunächst den ursprünglichen Server und ersetzt den öffentlichen Schlüssel im ursprünglichen Serverzertifikat durch einen ihm bekannten Schlüssel. Anschließend wird ein neues Zertifikat generiert, indem der ursprüngliche Aussteller des Zertifikats durch seine eigene Identität ersetzt wird, und dieses neue Zertifikat wird mit seinem eigenen öffentlichen Schlüssel signiert (der als Teil der Proxyprofilkonfiguration bereitgestellt wird). Wenn der Client ein solches Zertifikat akzeptiert, sendet er einen freigegebenen Vorprimärschlüssel, der mit dem öffentlichen Schlüssel auf dem Zertifikat verschlüsselt ist. Da der SSL-Weiterleitungsproxy den ursprünglichen Schlüssel durch seinen eigenen Schlüssel ersetzt hat, kann er den freigegebenen Vorprimärschlüssel empfangen. Entschlüsselung und Verschlüsselung erfolgen in jede Richtung (Client und Server), und die Schlüssel sind sowohl für die Verschlüsselung als auch für die Entschlüsselung unterschiedlich.
Abbildung 1 zeigt, wie die SSL-Prüfung (bei einem vorhandenen IPS-Modul der SRX-Serie) typischerweise zum Schutz von Servern verwendet wird. Die SSL-Prüfung erfordert den Zugriff auf private Schlüssel, die von den Servern verwendet werden, damit das Gerät der SRX-Serie den verschlüsselten Datenverkehr entschlüsseln kann.
der SRX-Serie
Abbildung 2 zeigt, wie der SSL-Forward-Proxy mit einer verschlüsselten Nutzlast funktioniert. Wenn die Anwendungs-Firewall (AppFW), das Intrusion Prevention System (IPS) oder die Anwendungsverfolgung (AppTrack) konfiguriert ist, fungiert der SSL-Weiterleitungsproxy als SSL-Server, der die SSL-Sitzung vom Client aus beendet und eine neue SSL-Sitzung mit dem Server einrichtet. Das Gerät entschlüsselt den gesamten SSL-Proxy-Datenverkehr und verschlüsselt ihn anschließend erneut. Der SSL-Weiterleitungsproxy verwendet die folgenden Dienste:
-
SSL-T-SSL-Abschlusszeichen auf der Clientseite.
-
SSL-I-SSL-Initiator auf der Serverseite.
-
Konfigurierte AppFW-, IPS- oder AppTrack-Services verwenden die entschlüsselten SSL-Sitzungen.
Wenn keiner der Services (AppFW, IPS oder AppTrack) konfiguriert ist, werden SSL-Proxydienste auch dann umgangen, wenn ein SSL-Proxyprofil an eine Firewallrichtlinie angehängt ist. IPS führt keine SSL-Prüfung für eine Sitzung durch, wenn der SSL-Weiterleitungsproxy für diese Sitzung aktiviert ist. Das heißt, wenn sowohl die SSL-Überprüfung als auch der SSL-Weiterleitungsproxy für eine Sitzung aktiviert sind, hat der SSL-Weiterleitungsproxy immer Vorrang.
Unterstützte Verschlüsselungen im Proxy-Modus
Eine SSL-Verschlüsselung umfasst Verschlüsselungschiffren, Authentifizierungsmethode und Komprimierung. Tabelle 1 zeigt eine Liste der unterstützten Verschlüsselungen. NULL-Chiffren sind ausgeschlossen.
Folgende SSL-Protokolle werden unterstützt:
-
SSLv3
-
TLS1
| SSL-Verschlüsselung |
Algorithmus für den Austausch von Schlüsseln |
Datenverschlüsselung |
Nachrichtenintegrität |
|---|---|---|---|
| RSA_WITH_RC4_128_MD5 |
RSA-Schlüsselaustausch |
128-bit RC4 |
MD5-Hash (Message Digest 5) |
| RSA_WITH_RC4_128_SHA |
RSA-Schlüsselaustausch |
128-bit RC4 |
Sicherer Hash-Algorithmus (SHA)-Hash |
| RSA_WITH_DES_CBC_SHA |
RSA-Schlüsselaustausch |
DES CBC |
SHA-Hash |
| RSA_WITH_3DES_EDE_CBC_SHA |
RSA-Schlüsselaustausch |
3DES EDE/CBC |
SHA-Hash |
| RSA_WITH_AES_128_CBC_SHA |
RSA-Schlüsselaustausch |
128-Bit AES/CBC |
SHA-Hash |
| RSA_WITH_AES_256_CBC_SHA |
RSA-Schlüsselaustausch |
256-Bit AES/CBC |
SHA-Hash |
| RSA_EXPORT_WITH_RC4_40_MD5 |
RSA-Export |
40-Bit RC4 |
MD5-Hash |
| RSA_EXPORT_WITH_DES40_CBC_SHA |
RSA-Export |
40-bit DES/CBC |
SHA-Hash |
| RSA_EXPORT1024_WITH_DES_CBC_SHA |
RSA 1024-Bit-Export |
DES/CBC |
SHA-Hash |
| RSA_EXPORT1024_WITH_RC4_56_MD5 |
RSA 1024-Bit-Export |
56-Bit RC4 |
MD5-Hash |
| RSA_EXPORT1024_WITH_RC4_56_SHA |
RSA 1024-Bit-Export |
56-Bit RC4 |
SHA-Hash |
| RSA-MIT-AES-256-GCM-SHA384 |
RSA-Schlüsselaustausch |
256-Bit-AES/GCM |
SHA384-Hash |
| RSA-MIT-AES-256-CBC-SHA256 |
RSA-Schlüsselaustausch |
256-Bit AES/CBC |
SHA256-Hash |
| RSA-MIT-AES-128-GCM-SHA256 |
RSA-Schlüsselaustausch |
128-Bit-AES/GCM |
SHA256-Hash |
| RSA-MIT-AES-128-CBC-SHA256 |
RSA-Schlüsselaustausch |
128-Bit AES/CBC |
SHA256-Hash |
Serverauthentifizierung
Implizite Vertrauenswürdigkeit zwischen dem Client und dem Gerät (da der Client das vom Gerät generierte Zertifikat akzeptiert) ist ein wichtiger Aspekt des SSL-Proxys. Es ist äußerst wichtig, dass die Serverauthentifizierung nicht beeinträchtigt wird. In der Realität gibt es jedoch viele selbstsignierte Zertifikate und Zertifikate mit Anomalien. Zu den Anomalien gehören abgelaufene Zertifikate, Instanzen des allgemeinen Namens, die nicht mit einem Domänennamen übereinstimmen usw.
Die Serverauthentifizierung wird durch die Auswahl der Option Serverauthentifizierung ignorieren im SSL-Weiterleitungsproxyprofil gesteuert.
Wenn die Option Serverauthentifizierung ignorieren nicht ausgewählt ist, treten die folgenden Szenarien auf:
-
Wenn die Authentifizierung erfolgreich ist, wird ein neues Zertifikat generiert, indem die Schlüssel ersetzt und der Ausstellername in den Ausstellernamen geändert wird, der im Zertifikat der Stammzertifizierungsstelle im Proxyprofil konfiguriert ist.
-
Wenn die Authentifizierung fehlschlägt, wird die Verbindung getrennt.
Wenn die Option Serverauthentifizierung ignorieren als Aktion im SSL-Proxyprofil definiert ist, treten die folgenden Szenarien auf:
-
Wenn das Zertifikat selbstsigniert ist, wird ein neues Zertifikat generiert, indem nur die Schlüssel ersetzt werden. Der Name des Ausstellers wird nicht geändert. Dadurch wird sichergestellt, dass der Clientbrowser eine Warnung anzeigt, dass das Zertifikat ungültig ist.
-
Wenn das Zertifikat abgelaufen ist oder der allgemeine Name nicht mit dem Domänennamen übereinstimmt, wird ein neues Zertifikat generiert, indem die Schlüssel ersetzt und der Name des Ausstellers in SSL-PROXY: DUMMY_CERT:GENERIERT AUFGRUND EINES FEHLERS BEI DER SRVR-AUTHENTIFIZIERUNG. Dadurch wird sichergestellt, dass der Clientbrowser eine Warnung anzeigt, dass das Zertifikat ungültig ist.
Liste der vertrauenswürdigen Zertifizierungsstellen
SSL Forward Proxy sorgt für eine sichere Übertragung von Daten zwischen einem Client und einem Server. Vor dem Herstellen einer sicheren Verbindung prüft der SSL-Forward-Proxy die Zertifikate der Zertifizierungsstelle (Certificate Authority , CA), um die Signaturen auf den Serverzertifikaten zu überprüfen. Aus diesem Grund ist eine angemessene Liste vertrauenswürdiger CA-Zertifikate erforderlich, um Server effektiv zu authentifizieren.
Serverauthentifizierung ignorieren
Sie können die Option Serverauthentifizierung ignorieren verwenden, um die Serverauthentifizierung vollständig zu ignorieren. In diesem Fall ignoriert der SSL-Weiterleitungsproxy Fehler, die während des Überprüfungsprozesses des Serverzertifikats auftreten (z. B. Fehler bei der Signaturüberprüfung der Zertifizierungsstelle, selbstsignierte Zertifikate und Zertifikatsablauf).
Wir empfehlen diese Option nicht für die Authentifizierung, da ihre Konfiguration dazu führt, dass Websites überhaupt nicht authentifiziert werden. Sie können diese Option jedoch verwenden, um die Ursache für unterbrochene SSL-Sitzungen effektiv zu identifizieren.
Stammzertifizierungsstelle
In einer PKI-Hierarchie (Public Key Infrastructure) steht die Stammzertifizierungsstelle ganz oben im Vertrauenspfad. Die Stammzertifizierungsstelle identifiziert das Serverzertifikat als vertrauenswürdiges Zertifikat.
Wiederaufnahme der Sitzung
Eine SSL-Sitzung bezieht sich auf den Satz von Parametern und Verschlüsselungsschlüsseln, der durch die Durchführung eines vollständigen Handshakes erstellt wird. Eine Verbindung ist die Konversation oder aktive Datenübertragung, die innerhalb der Sitzung stattfindet. Der Rechenaufwand für einen vollständigen SSL-Handshake und die Generierung von Primärschlüsseln ist beträchtlich. Bei kurzlebigen Sitzungen kann die Zeit für den SSL-Handshake länger sein als die Zeit für die Datenübertragung. Um den Durchsatz zu verbessern und dennoch ein angemessenes Sicherheitsniveau aufrechtzuerhalten, stellt die Wiederaufnahme der SSL-Sitzung einen Mechanismus zur Zwischenspeicherung von Sitzungen bereit, sodass Sitzungsinformationen, z. B. der geheime Schlüssel vor der primären Sitzung und die vereinbarten Verschlüsselungen, sowohl für den Client als auch für den Server zwischengespeichert werden können. Die zwischengespeicherten Informationen werden durch eine Sitzungs-ID identifiziert. Bei nachfolgenden Verbindungen vereinbaren beide Parteien, die Sitzungs-ID zum Abrufen der Informationen zu verwenden, anstatt einen neuen geheimen Schlüssel vor der primären Hauptebene zu erstellen. Die Wiederaufnahme der Sitzung verkürzt den Handshake-Prozess und beschleunigt SSL-Transaktionen.
SSL-Proxy-Protokolle
Wenn die Protokollierung in einem SSL-Proxyprofil aktiviert ist, kann der SSL-Proxy die in Tabelle 2 gezeigten Meldungen generieren.
| Protokolltyp |
Beschreibung |
|---|---|
| SSL_PROXY_SSL_SESSION_DROP |
Protokolle, die generiert werden, wenn eine Sitzung vom SSL-Proxy unterbrochen wird. |
| SSL_PROXY_SSL_SESSION_ALLOW |
Protokolle, die generiert werden, wenn eine Sitzung vom SSL-Proxy verarbeitet wird, auch wenn kleinere Fehler aufgetreten sind. |
| SSL_PROXY_SESSION_IGNORE |
Protokolle, die generiert werden, wenn Nicht-SSL-Sitzungen zunächst fälschlicherweise als SSL-Sitzungen angesehen werden. |
| SSL_PROXY_SESSION_ALLOWLIST |
Protokolle, die generiert werden, wenn eine Sitzung auf die Zulassungsliste gesetzt wird. |
| SSL_PROXY_ERROR |
Protokolle, die zum Melden von Fehlern verwendet werden. |
| SSL_PROXY_WARNING |
Protokolle, die zum Melden von Warnungen verwendet werden. |
| SSL_PROXY_INFO |
Protokolle, die für die Berichterstattung über allgemeine Informationen verwendet werden. |
Alle Protokolle enthalten ähnliche Informationen. Das Meldungsfeld enthält den Grund für die Loggenerierung. Eines der drei Präfixe, die in Tabelle 3 aufgeführt sind, identifiziert die Quelle der Nachricht. Andere Felder sind aussagekräftig beschriftet.
| Präfix |
Beschreibung |
|---|---|
| System |
Protokolle, die aufgrund von Fehlern im Zusammenhang mit dem Gerät oder einer im Rahmen des SSL-Proxyprofils ausgeführten Aktion generiert werden. Die meisten Protokolle fallen in diese Kategorie. |
| OpenSSL-Fehler |
Protokolle, die während des Handshake-Prozesses generiert werden, wenn ein Fehler von der openssl-Bibliothek erkannt wird. |
| Zertifikatsfehler |
Protokolle, die während des Handshake-Prozesses generiert werden, wenn ein Fehler im Zertifikat erkannt wird (x509-bezogene Fehler). |
Absolute Geheimhaltung bei Weiterleitung
Perfect Forward Secrecy ist ein spezielles Schlüsselvereinbarungsprotokoll, das sicherstellt, dass Ihre Sitzungsschlüssel nicht kompromittiert werden, selbst wenn der private Schlüssel des Servers kompromittiert wird. Durch die Generierung eines eindeutigen Sitzungsschlüssels für jede Sitzung, die ein Benutzer initiiert, wirkt sich dies auch dann nicht auf Daten aus, die in einer bestimmten Sitzung ausgetauscht werden, die durch diesen bestimmten Schlüssel geschützt ist, selbst wenn ein einzelner Sitzungsschlüssel kompromittiert wird.
Die Elliptic Curve DHE (ECDHE)-Verschlüsselungsanzüge werden unterstützt, um die perfekte Weiterleitungsgeheimhaltung für SSL-Weiterleitungsproxy zu ermöglichen. Der SSL-Weiterleitungsproxy verwendet weiterhin RSA für die Authentifizierung. Es verwendet jedoch EC Diffie-Hellman ephemeral key exchange, um sich auf ein gemeinsames Geheimnis zu einigen.
ECDHE-Verschlüsselungssammlungen sind schneller als die DHE-Gegenstücke, und daher unterstützt der SSL-Weiterleitungsproxy nur ECDHE-Verschlüsselungsanzüge. Die ECDHE-Verschlüsselungsanzüge basieren auf der Kryptografie mit elliptischen Kurven, mit der Sie mit kleineren Schlüsseln das gleiche Sicherheitsniveau wie RSA erreichen können. Zum Beispiel ist eine elliptische 224-Bit-Kurve genauso sicher wie ein 2048-Bit-RSA-Schlüssel.
Tabelle 4 zeigt die unterstützten ECDHE-Chiffrieranzüge.
| SSL-Verschlüsselung |
Algorithmus für den Austausch von Schlüsseln |
Datenverschlüsselung |
Nachrichtenintegrität |
|---|---|---|---|
| ECDHE-RSA-MIT-AES-256-GCM-SHA384 |
ECDHE RSA |
256-Bit-AES/GCM |
SHA 384 Hash |
| ECDHE-RSA-MIT-AES-256-CBC-SHA384 |
ECDHE RSA |
256-Bit AES/CBC |
SHA 384 Hash |
| ECDHE-RSA-MIT-AES-256-CBC-SHA |
ECDHE RSA |
256-Bit AES/CBC |
SHA-Hash |
| ECDHE-RSA-MIT-AES-3DES-EDE-CBC-SHA |
ECDHE RSA |
3DES AES/EDE/CBC |
SHA-Hash |
| ECDHE-RSA-MIT-AES-128-GCM-SHA256 |
ECDHE RSA |
128-Bit-AES/GCM |
SHA 256 Hash |
| ECDHE-RSA-MIT-AES-128-CBC-SHA256 |
ECDHE RSA |
128-Bit AES/CBC |
SHA 256 Hash |
| ECDHE-RSA-MIT-AES-128-CBC-SHA |
ECDHE RSA |
128-Bit AES/CBC |
SHA-Hash |