SSL-Zertifikate

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 Festlegen der ignore-server-auth-failure Option im SSL-Proxyprofil gesteuert. Die Ergebnisse dieser Option sind in Tabelle 1 verfügbar.

Tabelle 1: Option "Serverauthentifizierungsfehler ignorieren"

SSL-Proxy-Profilaktion	Befund
Die ignore-server-auth-failure Option ist nicht gesetzt (Standardoption)	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.
Die ignore-server-auth-failure Option ist gesetzt	Wenn das Zertifikat selbstsigniert ist, wird ein neues Zertifikat generiert, indem 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. 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. Weitere Informationen finden Sie unter Aktivieren von Debugging und Ablaufverfolgung für SSL-Proxy.

Client-Authentifizierung

Derzeit wird die Clientauthentifizierung im SSL-Proxy nicht unterstützt. Wenn ein Server die Clientauthentifizierung anfordert, wird eine Warnung ausgegeben, dass ein Zertifikat nicht verfügbar ist. Anhand der Warnung kann der Server bestimmen, ob er fortgesetzt oder beendet werden soll.

Optimierung der SSL-Performance

Der SSL/TLS-Handshake ist ein CPU-intensiver Prozess. Da SSL/TLS das am weitesten verbreitete Sicherheitsprotokoll im Web ist, hat seine Leistung erhebliche Auswirkungen auf die Webleistung.

Ab Junos OS Version 15.1X49-D120 können Sie die folgenden Optionen zur Optimierung der Leistung verwenden:

• Optimierten RSA-Schlüsselaustausch nutzen

• Authentifizierte Verschlüsselung mit zugehörigen Daten (AEAD) verwenden: AES128-CBC-SHA, AES256-CBC-SHA

• Verwalten des Zertifikat-Caches: Im Zertifikat-Cache wird das gesperrte Serverzertifikat zusammen mit den Details des Serverzertifikats gespeichert. Während des SSL/TLS-Handshakes kann der SSL-Proxy dem Client das zwischengespeicherte gesperrte Zertifikat präsentieren, anstatt das neue gesperrte Zertifikat zu generieren.

Die Verbesserung der SSL-Leistung führt zu einer verbesserten Website-Leistung ohne Kompromisse bei der Sicherheit und maximierter Benutzererfahrung.

Optional können Sie die folgenden Einstellungen für Ihren Zertifikatcache konfigurieren. Es wird jedoch empfohlen, die Standardwerte beizubehalten.

Beispiel:

• (Optional) Legen Sie den Timeoutwert für den Zertifikatcache fest (Beispiel: 300 Sekunden).

  In diesem Beispiel speichert der Zertifikatcache die Zertifikatdetails 300 Sekunden lang. Der Standardwert für die Zeitüberschreitung beträgt 600 Sekunden.

• (Optional) Deaktivieren Sie den Zertifikatcache.

  Wenn Sie den Zertifikatcache deaktivieren, lässt das Gerät den vollständigen SSL-Handshake für eine neue Verbindung zu. Standardmäßig ist der Zertifikatcache aktiviert.

• (Optional) Machen Sie den vorhandenen Zertifikatcache ungültig.

  In diesem Beispiel macht das Gerät den vorhandenen Zertifikatcache ungültig, wenn die Zertifikatsperrliste (Certificate Revocation List, CRL) aktualisiert wird. Standardmäßig ist das Ungültigmachen des Zertifikatcaches bei der CRL-Aktualisierung deaktiviert.

Wiederaufnahme der Sitzung

Die Wiederaufnahme der SSL-Sitzung bietet einen Mechanismus zum Fortsetzen einer vorherigen Sitzung mit bereits ausgehandelten Sitzungs-IDs. Die Wiederaufnahme der Sitzung erspart Client und Server den Rechenaufwand eines vollständigen SSL-Handshakes und der Generierung neuer Primärschlüssel.

Die Wiederaufnahme der Sitzung verkürzt den Handshake-Prozess und beschleunigt SSL-Transaktionen, was zu einer verbesserten Leistung bei gleichzeitiger Aufrechterhaltung eines angemessenen Sicherheitsniveaus führt.

TLS 1.2 unterstützt die Wiederaufnahme von Sitzungen mit Sitzungskennungen und Sitzungsticket-Mechanismen. Eine Wiederaufnahme einer SSL-Sitzung umfasst die folgenden Schritte:

• Ein Sitzungszwischenspeicherungsmechanismus speichert Sitzungsinformationen im Cache, z. B. den geheimen Schlüssel vor dem Master und vereinbarte Verschlüsselungen für Client und Server.

• Die Sitzungs-ID identifiziert die zwischengespeicherten Informationen.

• Bei nachfolgenden Verbindungen vereinbaren beide Parteien, die Sitzungs-ID zum Abrufen der Informationen zu verwenden, anstatt einen geheimen Pre-Master-Schlüssel zu erstellen.

Ab Junos OS Version 22.1R1 unterstützt TLS 1.3 die Wiederaufnahme von Sitzungen mithilfe eines Pre-shared Key (PSK) im SSL-Proxy. Die Wiederaufnahme einer Sitzung mithilfe von PSK ermöglicht die Wiederaufnahme einer Sitzung mit einem zuvor festgelegten gemeinsamen geheimen Schlüssel, um den SSL-Handshake-Overhead zu reduzieren.

PSK ist ein eindeutiger Verschlüsselungsschlüssel, der aus dem anfänglichen TLS-Handshake abgeleitet wird. Nach einem erfolgreichen TLS-Handshake sendet der Server eine PSK-Identität an den Client. Der Client verwendet diese PSK-Identität in den zukünftigen Handshakes, um die Verwendung des zugeordneten PSK zum Fortsetzen der Sitzung auszuhandeln.

Eine Wiederaufnahme der SSL-Sitzung mit TLS1.3 umfasst die folgenden Schritte:

1. Nach einem anfänglichen TLS-Handshake sendet der Server eine neue Sitzungsticket-Nachricht an den Client, die die PSK-Identität (verschlüsselte Kopie des PSK) enthält.

2. Wenn der Client das nächste Mal versucht, die Sitzung fortzusetzen, sendet er dasselbe Sitzungsticket an den Server in der Hello-Nachricht.
3. Der Server entschlüsselt die Nachricht, identifiziert den PSK und ruft die Sitzungsinformationen aus seinem Cache ab, um die Sitzung fortzusetzen.

Bei einer SSL-I-INITIIERUNG (SSL-Initiierung) wird PSK mit ECDHE-Schlüsselaustauschmodus verwendet, und bei SSL-T (SSL-Terminierung) werden PSK und PSK mit ECDHE-Austauschmodi verwendet.

Die SSL-Proxysitzung unterstützt die Interoperabilität zwischen TLS1.3 und TLS1.2 und früheren Versionen an zwei Enden einer Verbindung für die Wiederaufnahme der Sitzung.

Standardmäßig ist die Sitzungswiederaufnahme für SSL-Proxy aktiviert. Sie können die Sitzungswiederaufnahme löschen oder gemäß Ihren Anforderungen erneut aktivieren.

• So löschen Sie die Wiederaufnahme der Sitzung:
• So aktivieren Sie die Sitzungswiederaufnahme wieder:

Verwenden Sie den folgenden Befehl, um den Wert für die Sitzungszeitüberschreitung zu konfigurieren.

Sie können den Timeout-Wert zwischen 300 Sekunden und 86400 Sekunden konfigurieren. Der Standardwert ist 86400 Sekunden (24 Stunden).

Neuverhandlung von Sitzungen

Die Firewalls der SRX-Serie unterstützen die Neuaushandlung von Sitzungen. Nachdem eine Sitzung erstellt und der SSL-Tunneltransport eingerichtet wurde, erfordert eine Änderung der SSL-Parameter eine Neuaushandlung. SSL-Proxy unterstützt sowohl sichere (RFC 5746) als auch nicht sichere (TLS v1.0, TLS v1.1 und TLS v1.2) Neuaushandlung. Wenn die Sitzungswiederaufnahme aktiviert ist, ist die Neuverhandlung der Sitzung in den folgenden Situationen nützlich:

• Chiffrierschlüssel müssen nach einer längeren SSL-Sitzung aktualisiert werden.

• Für eine sicherere Verbindung müssen stärkere Chiffren verwendet werden.

Wenn Sie das SSL-Proxyprofil ändern, indem Sie ein Zertifikat, eine Verschlüsselungsstärke oder eine Liste vertrauenswürdiger Zertifizierungsstellen ändern, leert das System die Cacheeinträge, wenn Sie die geänderte Richtlinie übernehmen. In diesem Fall ist ein vollständiger Handshake erforderlich, um die neuen SSL-Parameter festzulegen. (Es gibt keine Auswirkungen auf Nicht-SSL-Sitzungen.)

Wenn das SSL-Proxyprofil nicht geändert wird, werden die Cache-Einträge, die diesem Profil entsprechen, nicht geleert, und die Sitzung wird fortgesetzt.

Aushandeln von StartTLS für SMTP-Sitzungen

Das StartTLS ermöglicht eine SMTP-Sitzung von einer anfänglichen reinen TCP-Verbindung zu einer sichereren TLS-Verbindung. StartTLS ermöglicht die SMTP-Sitzung zwischen dem Server und dem Client über die TLS-Schicht nach erfolgreicher Aushandlung zwischen den Peers. StartTLS aktualisiert eine bestehende unsichere einfache SMTP-Verbindung zu einer sicheren SSL/TLS-Verbindung.

Sie können einen Schwellenwert festlegen, mit dem Sie entscheiden können, wie lange gewartet werden soll, bevor die Sitzung ignoriert wird, wenn StartTLS nicht vom Client empfangen wird.

Sie können die folgenden Optionen konfigurieren:

• byte-threshold: Mindestens zulässige Bytes der unverschlüsselten Sitzung, bevor die Sitzung ignoriert wird, wenn StartTLS nicht vom Client empfangen wird. Bereich 100 bis 300.
• packet-threshold: Anzahl der unverschlüsselten Pakete, die in Client-zu-Server-Richtung zulässig sind, bevor die Sitzung ignoriert wird, wenn StartTLS nicht vom Client empfangen wird. Bereich 1 bis 15.

Beispiel:

In diesem Beispiel lässt der SSL-Proxy 100 Byte einfachen (unverschlüsselten) SMTP-Datenverkehr zu. Nach Erreichen von 100 Byte wird die Sitzung ignoriert, wenn StartTLS nicht vom Client empfangen wird.

In diesem Beispiel lässt der SSL-Proxy 2 Pakete mit einfachem (unverschlüsseltem) SMTP-Datenverkehr zu. Nach Erreichen von 2 Paketen wird die Sitzung ignoriert, wenn StartTLS nicht vom Client empfangen wird.

Dynamische Auflösung von Domainnamen

Die mit Domainnamen verknüpften IP-Adressen sind dynamisch und können sich jederzeit ändern. Wenn sich eine Domänen-IP-Adresse ändert, wird sie an die SSL-Proxy-Konfiguration weitergegeben (ähnlich wie bei der Konfiguration der Firewall-Richtlinie).