web-dev-qa-db-fra.com

Clients HTTP Java et POODLE

En ce qui concerne la vulnérabilité POODLE, si je le comprends bien, il faut un client qui rétrograde automatiquement le protocole TLS en SSLv3 lorsqu’il ne parvient pas à établir un canal sécurisé avec un serveur utilisant un protocole de version supérieure annoncé par le serveur.

Les bibliothèques clientes Java HTTP communes, en particulier javax.net.ssl.HttpsURLConnection et Apache HttpClient, rétrogradent-elles automatiquement le protocole TLS lorsqu’il n’est pas possible d’établir une session TLS avec un serveur? Sinon, ai-je raison de dire qu'ils sont à l'abri de l'attaque POODLE sauf si (a) le serveur ne prend en charge que SSLv3 ou (b) une logique d'un niveau supérieur effectue la rétrogradation?

Je cherche quelque chose comme http://blog.hagander.net/archives/222-A-few-short-notes-about-PostgreSQL-and-POODLE.html mais pour les clients Java.

javasecurityhttpsapache-httpclient-4.xpoodle-attack
16
ykaganovich

Apache HttpClient n'implémente aucun des aspects du protocole TLS. Il s'appuie sur les API JSSE pour établir le protocole TLS/SSL et établir des sessions SSL sécurisées. À l'exception de la logique de vérification du nom d'hôte SSL, en ce qui concerne TLS/SSL, Apache HttpClient est aussi sécurisé (ou aussi vulnérable) que le JRE dans lequel il s'exécute. 

Mettre à jour:  Par défaut, HttpClient 4.3 utilise toujours TLS. Par conséquent, à moins de le configurer explicitement pour utiliser SSLv3, HttpClient devrait ne soit pas vulnérable aux exploits basés sur POODLE.. 

Cela s'est avéré être faux. UnDOITsupprimer explicitement SSLv3 de la liste des protocoles pris en charge! 

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();

Mise à jour 2: À compter de la version 4.3.6, HttpClient désactive toutes les versions de SSL (y compris SSLv3) par défaut.

22
oleg

Vous DEVEZ désactiver SSL v3.0 sur les clients Java si vous utilisez https.

Cela peut être fait en ajoutant cette propriété sur Java 6/7:

-Dhttps.protocols = "TLSv1"

Et pour Java 8:

-Dhttps.protocols = "TLSv1, TLSv1.1, TLSv1.2" 

-Djdk.tls.client.protocols = "TLSv1, TLSv1.1, TLSv1.2" 

Source: http://www.Oracle.com/technetwork/Java/javase/documentation/cve-2014-3566-2342133.html

12
yyvess

Apache HttpClient 4.3.6 désactive SSLv3 par défaut.

Voici un extrait de Notes de publication d'Apache HC 4.3.6

Version 4.3.6

HttpClient 4.3.6 (GA) est une version de maintenance qui en corrige plusieurs problèmes avec le paquet HttpClient OSGi ainsi que d’autres problèmes rapporté depuis la sortie 4.3.5.

Veuillez noter qu'à partir de cette version, HttpClient désactive toutes les versions de SSL (y compris SSLv3) en faveur du protocole TLS par défaut . Les utilisateurs qui souhaitent continuer à utiliser SSLv3 doivent explicitement utiliser activer le support pour cela. 

Les utilisateurs de toutes les versions de HttpClient sont invités à mettre à niveau.

Changelog:

  • Le protocole SSLv3 est désactivé par défaut Proposé par Oleg Kalnichevski 

Update: Si vous utilisez une machine virtuelle Java dont la version est>> Java 1.8 Update 31, SSLv3 est désactivé par défaut.Consultez les notes de publication

3
Dungeon Hunter

Après avoir passé beaucoup de temps à essayer de comprendre pourquoi TLSv1.2 était utilisé malgré le paramétrage de -Dhttps.protocols = "TLSv1", nous avons finalement trouvé ce post. Le drapeau magique est bien -Djdk.tls.client.protocols = "TLSv1" et notre client Apache Axis 1.4 fonctionne à nouveau . Si vous passez de Java 7 à Java 8, vous devrez peut-être ajouter cet indicateur Comme avant Java 8, TLSv1 était utilisé par défaut, alors que Java 8 utilisait TLSv1.2.

Merci!

0
edge66