2012-01-19 11 views
12

(Negación: No soy de ninguna de las maneras un experto en seguridad, ni un experto en ventanas para esa materia)TLSv1 errores de enlace en

Configuración:

  • servidor en nuestro fin: Java 1.6 (ya añadido BouncyCastle al archivo de seguridad) en windows 2003 Server
  • cliente
  • terceros: windows 2008 Server con BizTalk
  • todas las propiedades del sistema renegociación introducidas debido al ataque renegociación se "activado" en el lado del servidor (no es seguro que sé)

Idealmente queremos solucionar esto a nuestro lado, pero es posible proponer una solución al cliente si es necesario.

servidor

El cliente tiene que conectarse a nuestro servidor a través de una conexión HTTPS pero siempre falla, Wireshark muestra la siguiente conversación:

> TLSv1: Client Hello 
< TLSv1: Alert (21): Unexpected Message 

De acuerdo con la RFC (http://www.ietf.org/ rfc/rfc2246.txt) la alerta (21) se refiere a un descifrado fallido y, por lo que puedo ver en wireshark, ninguno de los cifrados propuestos por el cliente son realmente compatibles con JRE 1.6 (según http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites) en un esfuerzo por reproducirse el error para poder examinarlo más de cerca, lo probé con algún otro software:

  • wfetch en Windows XP con "https" seleccionado realizará el saludo de cliente inicial en SSLv2, el servidor cambiará a TLSv1 para responder, esto funciona
  • wfetch en Windows XP con configurado para usar "TLSv1" para el saludo inicial fallar en la misma forma que el servidor BizTalk
  • WFetch en windows 2008 con "https" configurados utilizará "TLSv1" para el apretón de manos inicial y fallar en la misma forma que el servidor BizTalk
  • IE (en windows XP) se Inicialmente intente un apretón de manos TLSv1 con el mismo resultado fallido pero inmediatamente lo intente de nuevo usando SSLv3 que funciona (en este punto me imagino que todo el software de Microsoft usa una configuración central disponible en HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentCo ntrolSet \ Control \ SecurityProviders \ Schannel)
  • Firefox utiliza SSLv3 para toda la conversación, por lo que no hay problema
  • OpenSSL realiza un apretón de manos inicial en SSLv2, y el servidor cambia a TLSv1 cuando se responde, no hay problema
  • OpenSSL puede ser obligado a hacer el saludo inicial en TLSv1 así, se ofrece una lista de 27 cifras (en contraposición a las 11 cifras propuestas por el software basado en windows) y se puede conectar sin problemas

para mi no entrenados Esto refuerza la idea de que una proposición de cifrado incompatible es la causa raíz donde Windows solo admite suites de cifrado. at no son compatibles con JVM (para TLSv1). He instalado Bouncy Castle como un proveedor adicional en el archivo java.security en vano. He buscado alto y bajo y solo encontré una referencia que tal vez websphere admite las cifras de Windows para TLSv1 pero no hay forma de descargar un proveedor independiente para probarlo. JRE 1.7 no es compatible con el software que ejecutamos en nuestra JVM, por lo que actualizar no es una opción (¿quizás el proveedor de seguridad puede ser degradado de forma segura?Aún así, no he encontrado una descarga) No he encontrado la manera de agregar un cifrado a las ventanas antes de escribir el código de C++ (He jugado con la configuración de registro mencionada sin efecto).

Así que en conclusión me pregunto si una de las siguientes cosas iban a arreglarlo y cómo deben llevarse a cabo:

  • agregar un proveedor a la JVM que puede trabajar con los sistemas de cifrado para TLSv1 que se proponen por las ventanas
  • alguna manera forzar al cliente a hacer el saludo inicial en SSLv3 (preferiblemente no SSLv2) o al menos volver a intentar si el apretón de manos TLSv1 falla
  • alguna manera añadir un sistema de cifrado JVM-compatible para TLSv1 a las ventanas del cliente

Por supuesto, también se aprecian otras soluciones.

EDITAR

versión de Java es Java version (64 bit): 1.6.0_19-b04.

La lista de sistemas de cifrado propuestos es:

  • TLS_RSA_WITH_RC4_128_MD5
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA
  • TLS_RSA_WITH_DES_CBC_SHA
  • TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
  • TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
  • TLS_RSA_EXPORT_WITH_RC4_40_MD5
  • TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_DSS_WITH_DES_CBC_SHA
  • TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA

se instalan los archivos de criptografía de potencia ilimitada. Intenté configurar javax.net.debug=all e inicié el servidor desde la consola, no apareció ninguna salida adicional. He configurado sun.security.ssl.allowUnsafeRenegotiation=true en vano.

EDIT 2

Resulta que el software que estamos utilizando utiliza una pila de encargo para HTTPS en lugar del predeterminado. Se emitió una solución que parece resolver el problema, aunque no sé exactamente qué parte de la solicitud TLS desencadenó el error (ya que la mayoría de los handshakes de TLSv1 tuvieron éxito).

Gracias por los comentarios, ha sido una búsqueda interesante aunque inútil. Vive y aprende.

+0

¿Puede mostrar una lista de cifrados que el cliente está proponiendo? – Jonathan

+0

¿Cuál es la versión completa de Java que está utilizando? Además, ¿tiene los archivos de políticas de Criptografía de fuerza ilimitada instalados en Java Runtime? –

+1

(No debería necesitar agregar el proveedor BouncyCastle en general.) Si esta aplicación usa 'HttpsUrlConnection', intente establecer la propiedad de este sistema:' https.protocols = SSLv3, TLS'. Solo para probar algunas otras cosas: 'sun.security.ssl.allowUnsafeRenegotiation = true' (no recomendado, por si acaso ...). También sería útil ver si hay más detalles al activar la depuración: 'javax.net.debug = all' o al menos' javax.net.debug = handshake'. – Bruno

Respuesta

1

Resulta que el software que estamos usando usa una pila personalizada para HTTPs en lugar de la predeterminada. Se emitió una solución que parece resolver el problema, aunque no sé exactamente qué parte de la solicitud TLS desencadenó el error (ya que la mayoría de los handshakes de TLSv1 tuvieron éxito).

Gracias por los comentarios, ha sido una búsqueda interesante aunque inútil. Vive y aprende.

0

Podrías leer mi artículo en detecting cipher strength (solo para asegurarte de que instalaste las cifras jce correctamente). En su pregunta dice que instaló cifrados ilimitados, pero luego hace referencia a claves de 128 y 40 bits. Entonces, estoy confundido por lo que tienes. Además, ¿podría verificar la intensidad del cifrado en el certificado SSL al que está intentando conectarse y decirnos qué es y cuál es el algoritmo?Además, asegúrese de que su archivo de política para JDK tenga los derechos adecuados para permitir una fuerza ilimitada.

Por último, ¿puede conectarse a un sitio SSL "conocido" para verificar correctamente los contactos de sus clientes? (Gmail web por ejemplo)

+1

Excepto por unas raras excepciones, las personas que desean usar SSL/TLS lo hacen porque desean establecer una conexión segura entre el cliente y el servidor. Sugerir usar un administrador de confianza que permita cualquier cosa y un verificador de nombre de host que acepte todo lo que sea justo lo hace inútil. Por favor deja de sugerir estas "soluciones". Claro que se deshacen de las advertencias, pero también hacen posible los ataques MITM. – Bruno

+0

Lo siento, la pregunta parece haber cambiado bastante desde que la contesté. Mi respuesta probablemente ya no sea relevante. – djangofan

Cuestiones relacionadas