Il messaggio Client Hello suggerisce la suite di crittografia che non si trova nell'elenco specificato dal metodo setEnabledCipherSuites ()

Question

Il messaggio Client Hello suggerisce la suite di crittografia che non si trova nell'elenco specificato dal metodo setEnabledCipherSuites ()

#1 da (1 voti)

3

Nel mio codice, utilizzo API JSSE6 per specificare un elenco di suite di crittografia abilitate. Volevo solo consentire crittografia a 168 bit o superiore, di seguito è una parte del mio codice:

/** List of 168 bits encryption or higher cipher suites */
private static final String[] ENABLED_CIPHER_SUITES_168 = {
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_256_CBC_SHA",
    "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA",
    "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
    "TLS_EMPTY_RENEGOTIATION_INFO_SCSV",
    "TLS_KRB5_WITH_3DES_EDE_CBC_SHA",
    "TLS_KRB5_WITH_3DES_EDE_CBC_MD5",
    "SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA",
    "NETSCAPE_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    "SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA",
    };
// return a list of cipher suites which match both array
String[] list = matchStringArrays(ENABLED_CIPHER_SUITES_168, ((SSLSocket)socket).getSupportedCipherSuites());
// Set a list of enabled cipher suites
((SSLSocket)socket).setEnabledCipherSuites(list);

Ma quando provo la mia app con uno strumento di scansione SSL, dicono che il mio server consente le suite di crittografia a 96 bit?

Quindi utilizzo Wireshark per acquisire pacchetti del processo di handshake SSL, ho trovato che nel messaggio Client Hello, c'è una suite di crittografia che non è inclusa nell'elenco delle suite di crittografia abilitate. La suite di crittografia è

ssl2_des_192_ede3_cbc_with_md5

Come può questa suite di cifratura apparire nel messaggio ciao del cliente?

java encryption wireshark tls

posta ducnh 29.10.2014 - 05:50

fonte

1 risposta

Leggi altre domande sui tag java encryption wireshark tls

Decifrare l'hive SAM dopo l'aggiornamento dell'anniversario di Windows 10? c'è il rischio di aumentare la lunghezza della riga di intestazione di esmtp contro rfc5822 - domanda asa / pix

score 1 · Accepted Answer

Il provider SunJSSE non supporta SSLv2. tuttavia supporta l'invio del primo messaggio ClientHello dell'handshake SSL / TLS nel formato SSLv2, tuttavia.

Un client che invia il messaggio ClientHello nel formato SSLv2 è utile se il client è pronto per utilizzare effettivamente SSLv2. Tuttavia, poiché SunJSSE non supporta SSLv2, invia il ClientHello nel formato SSLv2 per un motivo più debole: questo è per supportare server vecchi, buggy e legacy che conoscono SSLv3 ma aspettarsi il ClientHello nel formato SSLv2 e semplicemente riagganciare di fronte a un "normale", formato SSLv3 ClientHello (tali server esistono perché quando SSLv3 è stato progettato e distribuito, i client SSL hanno preso presto l'abitudine di inviare ClientHello nel formato SSLv2, quindi la ricezione di un% diClientHello SSLv3 non è stata realmente testata).

Questo fa luce su ciò che SunJSSE farà: invierà un SSLv2 ClientHello a non fare effettivamente SSLv2, solo per essere in grado di connettersi ad alcuni vecchi server che si aspettano quel formato di messaggio e quindi procedere ad usare SSLv3. Anche l'SSLv2 ClientHello conterrà, nell'elenco delle suite di cifratura, i codici per le suite di crittografia SSLv2 - che il client non effettivamente supporta, dal momento che non conosce SSLv2. Queste suite di crittografia sono quindi innocue: il cliente non ha alcuna intenzione di usarle e in effetti non sa come usarle; li include solo per rendere il messaggio ClientHello più "SSLv2-like". Il client si aspetta che il server risponda con un% diServerHello SSLv3, la suite di crittografia SSLv2 viene ignorata.

Disattivare il supporto per tale formato "SSLv2 ClientHello " è ancora una buona idea, per i seguenti motivi:

Sebbene il JDK di Sun / Oracle utilizzi SunJSSE per SSL, un'altra implementazione Java potrebbe includere il supporto completo SSLv2 (l'implementazione di IBM è rinomata per farlo) e non si desidera utilizzare inavvertitamente l'SSLv2 completo, poiché è debole in diversi modi.
C'è una strong spinta per disabilitare completamente SSLv2. I server potrebbero smettere di supportare il formato di messaggio% s% co_de SSLv2. Potrebbero essere alcuni vecchi server bacati che richiedono un co2de% SSLv2%; ma ci sono anche alcuni nuovi server non buggy che non supportano SSLv2 ClientHello ; e quest'ultimo sarà sempre più prevalente col passare del tempo.
Anche quando lo supportano, quel formato non può contenere estensioni SSL, ad es. Indicazione del nome del server , quindi l'utilizzo del formato diClientHello di SSLv2% potrebbe risultare limitativo.

Al giorno d'oggi si parla molto anche di disabilitare SSLv3 e forzare TLS 1.0 o versioni successive, quindi aggrapparsi a SSLv2 ti farà sembrare antiquato.