wake-up-neo.com

Java http-Clients und POODLE

In Bezug auf die POODLE-Sicherheitsanfälligkeit ist, wenn ich sie richtig verstehe, ein Client erforderlich, der das TLS-Protokoll automatisch auf SSLv3 herabgestuft, wenn es nicht möglich ist, einen sicheren Kanal mit einem Server zu erstellen, der das vom Server angekündigte Protokoll der höheren Version verwendet.

Werden die üblichen Java-HTTP-Clientbibliotheken, insbesondere javax.net.ssl.HttpsURLConnection und Apache HttpClient, das TLS-Protokoll automatisch heruntergestuft, wenn keine TLS-Sitzung mit einem Server eingerichtet werden kann? Wenn nicht, stimme ich, dass sie gegen den POODLE-Angriff immun sind, es sei denn (a) der Server unterstützt nur SSLv3 oder (b) eine Logik auf höherer Ebene das Downgrade durchführt?

Ich suche etwas wie http://blog.hagander.net/archives/222-A-few-short-notes-about-PostgreSQL-and-POODLE.html aber für Java-Clients.

16
ykaganovich

Apache HttpClient implementiert keine TLS-Protokollaspekte. Es ist auf JSSE-APIs angewiesen, um TLS/SSL-Handshake durchzuführen und sichere SSL-Sitzungen einzurichten. Mit Ausnahme der SSL-Hostnamen-Überprüfungslogik ist der Apache HttpClient, soweit TLS/SSL betroffen ist, so sicher (oder so anfällig) wie die JRE, in der er ausgeführt wird. 


Update:  HttpClient 4.3 verwendet standardmäßig immer TLS, es sei denn, es wird explizit für die Verwendung von SSLv3 konfiguriert. HttpClient sollte nicht anfällig für Exploits sein, die auf POODLE basieren

Das stellte sich als falsch heraus. EinMUSSmuss SSLv3 explizit aus der Liste der unterstützten Protokolle entfernen! 

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

Update 2: Ab Version 4.3.6 deaktiviert HttpClient standardmäßig alle Versionen von SSL (einschließlich SSLv3).

22
oleg

Sie müssen SSL v3.0 auf Java-Clients deaktivieren, wenn Sie https verwenden.

Dies kann durch Hinzufügen dieser Eigenschaft in Java 6/7 erfolgen:

-Dhttps.protocols = "TLSv1"

Und für Java 8:

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

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

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

12
yyvess

Apache HttpClient 4.3.6 deaktiviert standardmäßig SSLv3.

Hier ist ein Auszug aus den Versionshinweisen zu Apache HC 4.3.6 .

Release 4.3.6

HttpClient 4.3.6 (GA) ist eine Wartungsversion, mit der mehrere Probleme mit dem HttpClient OSGi-Paket sowie einige andere Probleme seit Release 4.3.5 gemeldet.

Bitte beachten Sie, dass HttpClient ab dieser Version alle Versionen deaktiviert von SSL (einschließlich SSLv3) standardmäßig zugunsten des TLS-Protokolls . Benutzer, die weiterhin SSLv3 verwenden möchten, müssen explizit Aktivieren Sie die Unterstützung dafür. 

Benutzern aller HttpClient-Versionen wird ein Upgrade empfohlen.

Änderungsprotokoll:

  • Das SSLv3-Protokoll ist standardmäßig deaktiviert. Bereitgestellt von Oleg Kalnichevski 

Update: Wenn Sie eine JVM mit einer Version> = Java 1.8 Update 31 ausführen, ist SSLv3 standardmäßig deaktiviert. Überprüfen Sie die Versionshinweise

3
Dungeon Hunter

Nachdem wir lange Zeit versucht hatten herauszufinden, warum TLSv1.2 trotz der Einstellung von -Dhttps.protocols = "TLSv1" verwendet wurde, haben wir diesen Beitrag gefunden. Das magische Flag ist in der Tat -Djdk.tls.client.protocols = "TLSv1" und unser Apache Axis 1.4-Client funktioniert wieder .. .. Wenn Sie von Java 7 auf Java 8 wechseln, müssen Sie dieses Flag hinzufügen Als Java 8 wurde TLSv1 als Standard verwendet, wohingegen Java 8 TLSv1.2 verwendet

Vielen Dank!

0
edge66