(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.
servidorEl 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.
¿Puede mostrar una lista de cifrados que el cliente está proponiendo? – Jonathan
¿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? –
(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