In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die Schritte zum Anpassen der vorkonfigurierten Verschlüsselungszeichenfolgen in Expressway beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
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.
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:
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.
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
~ #
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:
Zunächst sendet der Browser ein ClientHello-Paket mit der Liste der unterstützten Chiffren:
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:
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:
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.
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:
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.
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.
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
~ #
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:
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.
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:
:
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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
23-Jul-2024 |
Erstveröffentlichung |