openssl s_client, GnuTLS, sslscan stimmen nicht mit unterstützten Chiffren überein

350
arielCo

OpenSSL besagt, dass die Verschlüsselungssoftware für einen bestimmten Webserver ECDHE-RSA-AES128-SHA256 ist:

$ openssl s_client -connect 10.87.0.51:12656 </dev/null | grep Cipher depth=0 C = VE, ST = xxxx, L = xxxxx, O = xxxxx, CN = xxxx.xxx.xx, emailAddress = xxxx@xxxxx.com verify error:num=18:self signed certificate verify return:1 depth=0 C = VE, ST = xxxxx, L = xxxxx, O = xxxxx, CN = xxxxxx.xx.xx, emailAddress = xxxx@xxxxx.com verify return:1 DONE New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA256 Cipher : ECDHE-RSA-AES128-SHA256

GnuTLS stimmt AFAIK zu (nicht sicher, wie der AES CBC-Teil zu interpretieren ist, da er eine andere Nomenklatur verwendet)

$ gnutls-cli --no-ca-verification -p 12656 10.87.0.51 < /dev/null | sed -n '/Description/,$p' - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1) - Session ID: 5B:B6:66:65:8F:82:29:8B:5C:45:50:29:2F:6C:2D:7A:2C:C8:C0:EE:EB:CC:B7:79:19:1C:26:EA:97:CA:D6:A9 - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Options: safe renegotiation, - Handshake was completed  - Simple Client Mode:

Aber SSLscan / openssl sagt, es scheiterte bei der Prüfung:

$ sslscan 10.87.0.51:12656 | grep -e Accepted -e ECDHE-RSA-AES128-SHA256 Failed TLSv1 128 bits ECDHE-RSA-AES128-SHA256 Accepted TLSv1 128 bits ECDHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 128 bits ECDHE-RSA-RC4-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 Accepted TLSv1 112 bits ECDHE-RSA-DES-CBC3-SHA Accepted TLSv1 112 bits DES-CBC3-SHA

Falsche ich hier einen Widerspruch? Ich bin völlig neu dabei.

Edit : SSLscan sendet nicht wirklich ein Hallo für den ECDHE-RSA-AES128-SHA256, sondern stellt TCP-Verbindungen her und trennt die Verbindung zweimal, wobei "SSL-Routinen / ssl3_client_hello / keine verfügbaren Verschlüsselungscodes" zurückgegeben werden. Ich müsste weiter in SSLscan graben.

1

1 Antwort auf die Frage

0
garethTheRed

Während des ersten TLS-Handshakes sendet ein Client eine Client Hello- Nachricht, die unter anderem eine Versionsnummer, die angeforderte Komprimierungsmethode, Erweiterungen (wie SNI) und, in diesem Fall, eine Liste der vom Client unterstützten Verschlüsselungssuiten enthält.

Der Server antwortet mit einer Server Hello- Nachricht, die verschiedene Elemente enthält, darunter das Serverzertifikat, eine optionale Anforderung für ein Clientzertifikat und vor allem die ausgewählte Chipher Suite, die aus der Liste ausgewählt wurde, die der Client zuvor gesendet hatte.

In Ihrem Beispiel ist der Server festgelegt und der Client geändert. Daher hängt die Auswahl der verschiedenen Chiffriersätze von den unterschiedlichen Fähigkeiten Ihrer Clients ab.

Auch mit der gleichen Bibliothek und ohne zusätzliche Konfiguration meinerseits? Morgen werde ich die Handshakes festhalten und nach Unterschieden in Suiten suchen, die in Client Hello gesendet werden. arielCo vor 5 Jahren 0
Das ist der beste Weg, um nachzuforschen. OpenSSL und GnuTLS sind verschiedene Bibliotheken. Ist SSLScan statisch mit einer anderen OpenSSL-Bibliothek verknüpft? Ich habe gerade OpenSSL und SSLScan ausprobiert und die gleichen Chiffren für beide erhalten. garethTheRed vor 5 Jahren 0
Nachdem ich etwas tiefer gegriffen habe, scheint meine Version von SSLScan OpenSSL 1.0.2l zu verwenden, während `openssl version` 1.1.0f anzeigt. garethTheRed vor 5 Jahren 0
Meine beiden verwenden dieselbe .so (bestätigt durch `ldd`), aber irgendwie sendet` sslscan` nicht den Server Hello für ECDHE-RSA-AES128-SHA256. `openssl version` und` dpkg -l libssl1.0.0` sagen 1.0.2g. arielCo vor 5 Jahren 0

Verwandte Probleme