El mensaje de saludo del cliente sugiere una suite de cifrado que no se encuentra en la lista especificada por el método setEnabledCipherSuites ()

Question

El mensaje de saludo del cliente sugiere una suite de cifrado que no se encuentra en la lista especificada por el método setEnabledCipherSuites ()

#1 de Tom Leek (1 votos)

3

En mi código, uso JSSE6 API para especificar una lista de suites de cifrado habilitadas. Mi objetivo era permitir solo 168 bits o más conjuntos de cifrado de cifrado, a continuación es parte de mi código:

/** 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);

¿Pero cuando pruebo mi aplicación con alguna herramienta de escáner SSL, dicen que mi servidor permite conjuntos de cifrado de cifrado de 96 bits?

Luego utilizo Wireshark para capturar paquetes del proceso de intercambio de SSL, encontré que en el mensaje de saludo del cliente, hay un conjunto de cifrado que no está en mi lista de conjuntos de cifrado habilitados. La suite de cifrado es

ssl2_des_192_ede3_cbc_with_md5

¿Cómo puede aparecer este conjunto de cifrado en el mensaje de saludo del cliente?

encryption tls java wireshark

pregunta ducnh 29.10.2014 - 05:50

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption tls java wireshark

PCI DSS: enmascarar PAN y registrar acceso individual a PAN ¿Descifrando la sección SAM después de la actualización del aniversario de Windows 10?

score 1 · Accepted Answer

El proveedor SunJSSE no admite SSLv2. Sin embargo, sí admite el envío del primer mensaje ClientHello del protocolo de enlace SSL / TLS en formato SSLv2.

Un cliente que envía el mensaje ClientHello en formato SSLv2 es útil si el cliente está listo para usar SSLv2. Sin embargo, dado que SunJSSE no admite SSLv2, envía ClientHello en formato SSLv2 por una razón más débil: esto es para admitir servidores antiguos, con errores, que conocen SSLv3 pero esperan ClientHello en formato SSLv2, y simplemente cuelgan cuando se enfrentan a un formato "normal", SSLv3 ClientHello (tales servidores existen porque cuando se diseñó e implementó SSLv3, los clientes SSL pronto adoptaron el hábito de enviar ClientHello en formato SSLv2, por lo que la recepción de un SSLv3 ClientHello no se probó realmente).

Esto arroja algo de luz sobre lo que hará SunJSSE: enviará un SSLv2 ClientHello para que no haga SSLv2, solo para poder conectarse a algunos servidores antiguos que esperan ese formato de mensaje y luego proceder a usar SSLv3. El SSLv2 ClientHello también contendrá, en la lista de conjuntos de cifrado, los códigos para los conjuntos de cifrado de SSLv2, que el cliente no admite no , ya que no conoce SSLv2. Estas suites de cifrado son, por lo tanto, inofensivas: el cliente no tiene intención de usarlas y, de hecho, no sabe cómo usarlas; los incluye solo para hacer que el mensaje ClientHello sea más "similar a SSLv2". El cliente espera que el servidor responda con un SSLv3 ServerHello , ignorando el conjunto de cifrado SSLv2.

La desactivación del soporte para ese "formato SSLv2 ClientHello " sigue siendo una buena idea, por las siguientes razones:

Aunque el JDK de Sun / Oracle usa SunJSSE para SSL, otra implementación de Java puede incluir soporte completo de SSLv2 (la implementación de IBM tiene la reputación de hacerlo), y no quiere usar inadvertidamente el SSLv2 completo, ya que es débil de varias maneras.
Hay un empuje fuerte para deshabilitar SSLv2 completamente. Los servidores pueden dejar de admitir el formato de mensaje SSLv2 ClientHello . Pueden ser algunos servidores antiguos que requieren un SSLv2 ClientHello ; pero también hay algunos servidores nuevos sin errores que no admiten SSLv2 ClientHello ; y este último será cada vez más frecuente a medida que pase el tiempo.
Incluso cuando lo admiten, ese formato no puede contener extensiones SSL, por ejemplo. Indicación del nombre del servidor , por lo que el uso del formato SSLv2 ClientHello puede resultar limitativo.

Hoy en día, se habla mucho sobre la desactivación de SSLv3 y el forzamiento de TLS 1.0 o superior, por lo que aferrarse a SSLv2 te hará lucir un poco arcaico.