name how java security https apache-httpclient-4.x poodle-attack

how - Clientes http de Java y POODLE



set name to jframe (4)

Apache HttpClient 4.3.6 deshabilita SSLv3 de forma predeterminada.

Aquí hay un extracto de las notas de la versión de Apache HC 4.3.6

Versión 4.3.6

HttpClient 4.3.6 (GA) es una versión de mantenimiento que corrige varios problemas con el paquete HttpClient OSGi, así como algunos otros problemas informados desde la versión 4.3.5.

Tenga en cuenta que a partir de esta versión, HttpClient deshabilita todas las versiones de SSL (incluido SSLv3) en favor del protocolo TLS de forma predeterminada. Aquellos usuarios que deseen continuar utilizando SSLv3 deben habilitar explícitamente el soporte para él.

Se recomienda a los usuarios de todas las versiones de HttpClient que actualicen.

Registro de cambios

  • El protocolo SSLv3 está deshabilitado por defecto Contribuido por Oleg Kalnichevski

Actualización: si está ejecutando en JVM con versión> = Java 1.8 Update 31 SSLv3 está deshabilitado de forma predeterminada. Verifique las notas de la versión

Con respecto a la vulnerabilidad de POODLE, si la comprendo correctamente, se requiere un cliente que reduzca automáticamente la calificación del protocolo TLS a SSLv3 cuando no pueda establecer un canal seguro con un servidor que utilice un protocolo de versión superior anunciado por el servidor.

¿Las bibliotecas de cliente HTTP comunes de Java, específicamente javax.net.ssl.HttpsURLConnection y Apache HttpClient, degradan automáticamente el protocolo TLS cuando no se puede establecer una sesión TLS con un servidor? De lo contrario, ¿estoy en lo cierto al afirmar que son inmunes al ataque de POODLE a menos que (a) el servidor solo admita SSLv3, o (b) una lógica en un nivel superior realice la rebaja?

Estoy buscando algo como http://blog.hagander.net/archives/222-A-few-short-notes-about-PostgreSQL-and-POODLE.html pero para los clientes Java.

Apache HttpClient no implementa ninguno de los aspectos del protocolo TLS. Se basa en las API de JSSE para realizar el protocolo de enlace TLS / SSL y para establecer sesiones seguras de SSL. Con la excepción de la lógica de verificación de nombre de host SSL, en lo que respecta a TLS / SSL, Apache HttpClient es tan seguro (o vulnerable) como el JRE en el que se está ejecutando.

Actualización: HttpClient 4.3 de forma predeterminada siempre usa TLS, por lo tanto, a menos que uno lo configure explícitamente para usar SSLv3, HttpClient no debe ser vulnerable a las vulnerabilidades basadas en POODLE .

Esto resultó ser incorrecto. ¡UNO DEBE eliminar explícitamente SSLv3 de la lista de protocolos compatibles!

SSLContext sslContext = SSLContexts.custom() .useTLS() // Only this turned out to be not enough .build(); SSLConnectionSocketFactory sf = new SSLConnectionSocketFactory( sslContext, new String[] {"TLSv1", "TLSv1.1", "TLSv1.2"}, null, SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER); CloseableHttpClient client = HttpClients.custom() .setSSLSocketFactory(sf) .build();

Actualización 2: a partir de la versión 4.3.6 HttpClient deshabilita todas las versiones de SSL (incluido SSLv3) de forma predeterminada.

Después de pasar un tiempo considerable tratando de averiguar por qué se usaba TLSv1.2 a pesar de configurar -Dhttps.protocols = "TLSv1", finalmente encontramos esta publicación. La bandera mágica es de hecho -Djdk.tls.client.protocols = "TLSv1" y nuestro cliente Apache Axis 1.4 funciona de nuevo. Por lo tanto, en caso de que se mueva de Java 7 a Java 8, es posible que deba agregar este indicador ya que JAVA 8 anterior usaba TLSv1 como predeterminado, mientras que JAVA 8 usa TLSv1.2

¡Gracias!