Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Überprüfen der Chiffrierzeichenfolge

Überprüfen Sie die Cipher Negotiation beim TLS-Handshake mit einer Paketerfassung.

Konfigurieren

Deaktivieren einer bestimmten Verschlüsselung

Deaktivieren einer Gruppe von Chiffren mithilfe eines allgemeinen Algorithmus

Überprüfung

Überprüfen Sie die Liste der von der Cipher-Zeichenfolge zugelassenen Chiffren.

Testen einer TLS-Verbindung durch Aushandeln eines deaktivierten Verschlüsselungsverfahrens

Überprüfen der Paketerfassung eines TLSHandshake mithilfe eines deaktivierten Verschlüsselungsverfahrens

Zugehörige Informationen

Einleitung

In diesem Dokument werden die Schritte zum Anpassen der vorkonfigurierten Verschlüsselungszeichenfolgen in Expressway beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Cisco Expressway oder Cisco VCS,

- TLS-Protokoll.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

- Cisco Expressway-Version X15.0.2

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Die standardmäßige Expressway-Konfiguration umfasst vorkonfigurierte Verschlüsselungszeichenfolgen, die aus Kompatibilitätsgründen die Unterstützung für einige Verschlüsselungsarten ermöglichen, die in einigen Sicherheitsrichtlinien des Unternehmens als schwach angesehen werden können. Sie können die Verschlüsselungszeichenfolgen anpassen, um sie an die spezifischen Richtlinien der jeweiligen Umgebung anzupassen.

In Expressway ist es möglich, eine unabhängige Verschlüsselungszeichenfolge für jedes dieser Protokolle zu konfigurieren:

- HTTPS

- LDAP

- Reverse-Proxy

- SIP

- SMTP

- TMS-Bereitstellung

- UC-Servererkennung

- XMPP

Die Verschlüsselungszeichenfolgen entsprechen dem OpenSSL-Format, das in der OpenSSL Ciphers Manpage beschrieben wird. Die aktuelle Expressway-Version X15.0.2 enthält die Standardzeichenfolge EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH, die für alle Protokolle gleichermaßen vorkonfiguriert ist. Auf der Web-Admin-Seite können Sie unter Wartung > Sicherheit > Chiffren die jedem Protokoll zugewiesene Chiffrierzeichenfolge ändern, um bestimmte Chiffren oder Verschlüsselungsgruppen mithilfe eines gemeinsamen Algorithmus hinzuzufügen oder zu entfernen.

Überprüfen der Chiffrierzeichenfolge

Mit dem Befehl openssl ciphers -V "<cipher string>" können Sie eine Liste mit allen Verschlüsselungen ausgeben, die eine bestimmte Zeichenfolge zulässt. Dies ist für die visuelle Überprüfung der Verschlüsselungen nützlich. Dieses Beispiel zeigt die Ausgabe bei der Überprüfung der standardmäßigen Expressway-Verschlüsselungszeichenfolge:

~ # openssl ciphers -V "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH"

0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD

0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD

0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xC0,0xAD - ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD

0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0xAC - ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) Mac=AEAD

0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384

0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384

0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256

0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256

0xC0,0x09 - ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1

0xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1

0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD

0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD

0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xC0,0x9F - DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD

0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD

0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x9E - DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD

0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256

0x00,0x6A - DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256

0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256

0x00,0x40 - DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256

0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1

0x00,0x32 - DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1

0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x9D - AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD

0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x9C - AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD

0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256

0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256

0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

~ #

Überprüfen Sie die Cipher Negotiation beim TLS-Handshake mit einer Paketerfassung.

Wenn Sie eine TLS-Verhandlung in einer Paketerfassung erfassen, können Sie die Details der Verschlüsselungsverhandlung mithilfe von Wireshark überprüfen.

Der TLS-Handshake-Prozess umfasst ein vom Client-Gerät gesendetes ClientHello-Paket, das die Liste der unterstützten Verschlüsselungen gemäß der für das Verbindungsprotokoll konfigurierten Verschlüsselungszeichenfolge bereitstellt. Der Server überprüft die Liste, vergleicht sie mit seiner eigenen Liste zulässiger Chiffren (bestimmt durch seine eigene Chiffrierzeichenfolge) und wählt eine von beiden Systemen unterstützte Chiffre für die verschlüsselte Sitzung aus. Anschließend antwortet er mit einem ServerHello-Paket, das den ausgewählten Verschlüsselungscode angibt. Es gibt wichtige Unterschiede zwischen den TLS 1.2 und 1.3 Handshake Dialogen, aber der Cipher Negotiation Mechanismus verwendet dieses Prinzip in beiden Versionen.

Dies ist ein Beispiel für eine TLS 1.3-Verschlüsselungsverhandlung zwischen einem Webbrowser und Expressway an Port 443, wie in Wireshark gezeigt:

Beispiel für einen TLS-Handshake in Wireshark

Zunächst sendet der Browser ein ClientHello-Paket mit der Liste der unterstützten Chiffren:

Beispiel für ein ClientHello-Paket in Wireshark

Expressway überprüft die für das HTTPS-Protokoll konfigurierte Verschlüsselungszeichenfolge und findet eine Verschlüsselung, die sowohl von Expressway selbst als auch vom Client unterstützt wird. In diesem Beispiel wird die ECDHE-RSA-AES256-GCM-SHA384-Chiffre ausgewählt. Expressway antwortet mit dem ServerHello-Paket, das den ausgewählten Schlüssel angibt:

Beispiel für ein ServerHello-Paket in Wireshark

Konfigurieren

Das OpenSSL-Verschlüsselungszeichenfolgenformat enthält mehrere Sonderzeichen, um Vorgänge für die Zeichenfolge auszuführen, z. B. das Entfernen einer bestimmten Verschlüsselung oder einer Gruppe von Verschlüsselungen, die eine gemeinsame Komponente verwenden. Da das Ziel dieser Anpassungen normalerweise darin besteht, Chiffren zu entfernen, werden in diesen Beispielen folgende Zeichen verwendet:

- Das - Zeichen, mit dem Chiffren aus der Liste entfernt werden. Einige oder alle der entfernten Chiffren können durch Optionen, die später in der Zeichenfolge erscheinen, wieder zugelassen werden.

- Das !-Zeichen, das auch zum Entfernen von Chiffren aus der Liste verwendet wird. Wenn Sie es verwenden, können die entfernten Chiffren nicht durch andere Optionen, die später in der Zeichenfolge erscheinen, wieder zugelassen werden.

- Das Zeichen :, das als Trennzeichen zwischen Elementen in der Liste fungiert.

Beide können verwendet werden, um eine Chiffre aus der Zeichenfolge zu entfernen! ist jedoch bevorzugt. Eine vollständige Liste der Sonderzeichen finden Sie auf der OpenSSL Ciphers Manpage.

Hinweis: Die OpenSSL-Site stellt fest, dass bei Verwendung des Zeichens ! "die gelöschten Chiffren in der Liste nie wieder auftauchen können, auch wenn sie explizit angegeben sind". Dies bedeutet nicht, dass die Chiffren dauerhaft aus dem System gelöscht werden, es bezieht sich auf den Umfang der Interpretation der Chiffre-Zeichenfolge.

Deaktivieren einer bestimmten Verschlüsselung

Um eine bestimmte Verschlüsselung zu deaktivieren, fügen Sie an die Standardzeichenfolge das Trennzeichen, das ! oder -Zeichen und den zu deaktivierenden Verschlüsselungsnamen an. Der Name der Verschlüsselung muss dem OpenSSL-Namensformat entsprechen, das auf der OpenSSL Ciphers Manpage verfügbar ist. Wenn Sie z. B. den AES128-SHA-Verschlüsselungscode für SIP-Verbindungen deaktivieren müssen, konfigurieren Sie eine Verschlüsselungszeichenfolge wie diese:

EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:!AES128-SHA

Navigieren Sie anschließend zur Expressway-Web-Admin-Seite, navigieren Sie zu Maintenance > Security > Ciphers, weisen Sie die benutzerdefinierte Zeichenfolge den erforderlichen Protokollen zu, und klicken Sie auf Save (Speichern). Damit die neue Konfiguration angewendet werden kann, muss das System neu gestartet werden. In diesem Beispiel wird die benutzerdefinierte Zeichenfolge dem SIP-Protokoll unter SIP TLS-Verschlüsselungen zugewiesen:

Seite "Cipher Settings" im Expressway-Web-Administratorportal

Hinweis: Nehmen Sie bei einem Expressway-Cluster die Änderungen nur auf dem primären Server vor. Die neue Konfiguration wird auf den Rest der Cluster-Mitglieder repliziert.

Vorsicht: Verwenden Sie die empfohlene Cluster-Neustartsequenz aus dem Cisco Expressway Cluster Creation and Maintenance Deployment Guide. Starten Sie zunächst den primären Server neu, warten Sie, bis er über die Webschnittstelle erreichbar ist, und führen Sie dann das Gleiche mit jedem Peer aus, und zwar in der Reihenfolge, in der die Liste unter System > Clustering konfiguriert ist.

Deaktivieren einer Gruppe von Chiffren mithilfe eines allgemeinen Algorithmus

Um eine Gruppe von Chiffren mithilfe eines gemeinsamen Algorithmus zu deaktivieren, fügen Sie an die Standardzeichenfolge die folgenden Zeichen an: Trennzeichen, das ! oder - Zeichen und den zu deaktivierenden Algorithmusnamen. Die unterstützten Algorithmusnamen sind auf der OpenSSL Ciphers Manpage verfügbar. Wenn Sie z. B. alle Verschlüsselungen deaktivieren müssen, die den DHE-Algorithmus verwenden, konfigurieren Sie eine Verschlüsselungszeichenfolge wie diese:

EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:!DHE

Navigieren Sie zur Expressway-Web-Admin-Seite, navigieren Sie zu Maintenance > Security > Ciphers, weisen Sie die benutzerdefinierte Zeichenfolge den erforderlichen Protokollen zu, und klicken Sie auf Save. Damit die neue Konfiguration angewendet werden kann, muss das System neu gestartet werden.

Hinweis: Nehmen Sie bei einem Expressway-Cluster die Änderungen nur auf dem primären Server vor. Die neue Konfiguration wird auf den Rest der Cluster-Mitglieder repliziert.

Vorsicht: Verwenden Sie die empfohlene Cluster-Neustartsequenz aus dem Cisco Expressway Cluster Creation and Maintenance Deployment Guide. Starten Sie zunächst den primären Server neu, warten Sie, bis er über die Webschnittstelle erreichbar ist, und führen Sie dann das Gleiche mit jedem Peer aus, und zwar in der Reihenfolge, in der die Liste unter System > Clustering konfiguriert ist.

Überprüfung

Überprüfen Sie die Liste der von der Cipher-Zeichenfolge zugelassenen Chiffren.

Sie können die benutzerdefinierte Verschlüsselungszeichenfolge mit dem Befehl openssl ciphers -V "<cipher string>" überprüfen. Überprüfen Sie die Ausgabe, um sicherzustellen, dass die unerwünschten Chiffren nach den Änderungen nicht mehr aufgeführt werden. In diesem Beispiel wird die Chiffrierzeichenfolge EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:!DHE überprüft. Die Befehlsausgabe bestätigt, dass die Zeichenfolge keine der Chiffren zulässt, die den DHE-Algorithmus verwenden:

~ # openssl ciphers -V "EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!eNULL:!aNULL:!aDH:!DHE"

0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD

0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD

0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD

0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD

0xC0,0xAD - ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD

0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0xAC - ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128) Mac=AEAD

0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384

0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384

0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256

0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256

0xC0,0x09 - ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1

0xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1

0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD

0xC0,0x9D - AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD

0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD

0xC0,0x9C - AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD

0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256

0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256

0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1

~ #

Testen einer TLS-Verbindung durch Aushandeln eines deaktivierten Verschlüsselungsverfahrens

Sie können den Befehl openssl s_client verwenden, um zu überprüfen, ob ein Verbindungsversuch mit einer deaktivierten Verschlüsselung abgelehnt wird. Verwenden Sie die Option -connect, um Ihre Expressway-Adresse und Ihren Port anzugeben, und die Option -cipher, um die einzelne Verschlüsselung anzugeben, die vom Client während des TLS-Handshakes ausgehandelt werden soll:

openssl s_client -connect <Adresse>:<Port> -cipher <Chiffre> -no_tls1_3

In diesem Beispiel wird von einem Windows-PC mit installiertem openssl aus versucht, eine TLS-Verbindung zu Expressway herzustellen. Der PC verhandelt als Client nur die unerwünschte DHE-RSA-AES256-CCM-Verschlüsselung, die den DHE-Algorithmus verwendet:

C:\Users\Administrator>openssl s_client -connect exp.example.com:443 -cipher DHE-RSA-AES256-CCM -no_tls1_3

Connecting to 10.15.1.7

CONNECTED(00000154)

D0130000:error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:..\ssl\record\rec_layer_s3.c:865:SSL alert number 40

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 7 bytes and written 118 bytes

Verification: OK

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

No ALPN negotiated

SSL-Session:

Protocol : TLSv1.2

Cipher : 0000

Session-ID:

Session-ID-ctx:

Master-Key:

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1721019437

Timeout : 7200 (sec)

Verify return code: 0 (ok)

Extended master secret: no

---

C:\Users\Administrator>

In der Befehlsausgabe wird angezeigt, dass der Verbindungsversuch mit der Fehlermeldung "ssl/tls alert handshake failure:..\ssl\record\rec_layer_s3.c:865:SSL alert number 40" fehlgeschlagen ist, da der Expressway für die Verwendung von EECDH:EDH:HIGH:-AES256+SHA:!MEDIUM:!LOW:!3DES:!MD5:!PSK:!e NULL:!aNULL:!aDH:!DHE-Verschlüsselungszeichenfolge für HTTPS-Verbindungen, die Verschlüsselungen deaktiviert, die den DHE-Algorithmus verwenden.

Hinweis: Damit Tests mit dem Befehl openssl s_client wie beschrieben funktionieren, muss die Option -no_tls1_3 an den Befehl übergeben werden. Falls nicht enthalten, fügt der Client automatisch TLS 1.3-Chiffren in das ClientHello-Paket ein:

ClientHello-Paket mit automatisch hinzugefügten Chiffren

Wenn der Ziel-Expressway diese Chiffren unterstützt, kann eine davon ausgewählt werden, anstatt der spezifischen Chiffre, die Sie testen müssen. Die Verbindung ist erfolgreich, was Sie glauben lassen kann, dass eine Verbindung möglich war, indem der deaktivierte Schlüssel an den Befehl mit der Option -cipher übergeben wurde.

Überprüfen einer Paketerfassung eines TLS-Handshakes mit einem deaktivierten Cipher

Sie können eine Paketerfassung vom Testgerät oder vom Expressway erfassen, während Sie einen Verbindungstest mit einem der deaktivierten Verschlüsselungscodes durchführen. Sie können es dann mit Wireshark untersuchen, um die Handshake-Ereignisse weiter zu analysieren.

Suchen Sie nach dem ClientHello, das vom Testgerät gesendet wurde. Bestätigen Sie, dass nur die unerwünschte Testchiffre ausgehandelt wird, in diesem Beispiel eine Chiffre mit dem DHE-Algorithmus:

Beispiel für ein ClientHello-Paket in Wireshark

:

Vergewissern Sie sich, dass Expressway mit einem schwerwiegenden TLS-Warnpaket antwortet, und verweigern Sie die Verbindung. Da Expressway in diesem Beispiel keine DHE-Chiffren für die konfigurierte Verschlüsselungszeichenfolge für das HTTPS-Protokoll unterstützt, antwortet es mit einem schwerwiegenden TLS-Warnpaket mit dem Fehlercode 40.

Ein schwerwiegendes TLS-Warnpaket in Wireshark

Zugehörige Informationen

- OpenSSL-Verschlüsselungs-Manpage

- Cisco Expressway Administrator Guide (X15.0) - Kapitel: Sicherheitsmanagement - Konfigurieren der minimalen TLS-Version und der Cipher Suites