Ist es möglich, TLS 1.2 in der .jnlp-Datei zu aktivieren?

3280
Buffalo

Ist es möglich, TLS 1.2 in der .jnlp-Datei zu aktivieren, um .jar von einem HTTPS-Server herunterzuladen, auf dem nur TLS 1.2 eingestellt ist? Ich habe es auf vielerlei Weise versucht:

<resources>  <j2se (...) /> <jar (...) /> <property name="deployment.security.TLSv1.2" value="true" /> <property name="jnlp.deployment.security.TLSv1.2" value="true" /> <property name="java.deployment.security.TLSv1.2" value="true" /> <property name="https.protocols" value="TLSv1.2" /> <property name="jnlp.https.protocols" value="TLSv1.2" /> <property name="javaws.https.protocols" value="TLSv1.2" /> </property> </resources>

aber keine davon funktioniert - beim Starten von jnlp (Herunterladen von .jar) erhalte ich eine Ausnahme:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java (...)


Wenn ich in der Java-Systemsteuerung die Einstellung "TLS 1.2 verwenden" eingestellt habe, funktioniert alles - ich kann jar herunterladen und meine App wird erfolgreich gestartet. Ich möchte jedoch TLS 1.2 in der jnlp-Datei unabhängig von den Einstellungen in JCP aktivieren, da viele meiner Clients immer noch Java 7 verwenden und ich dies ohne ihre Aktion tun möchte.


UPDATE :
Hier ist ein Fragment (Ende) der Registerkarte Console, wenn ich jnlp mit dem folgenden Befehl
starte : javaws -J-Djavax.net.debug = all FILE.jnlp:

Java Web Start 10.51.2.13 Using JRE version 1.7.0_51-b13 Java HotSpot(TM) 64-Bit Server VM User home directory =   (...)  [Raw read]: length = 5 0000: 15 03 03 00 02 ..... [Raw read]: length = 2 0000: 02 28 .( Thread-8, READ: TLSv1.2 Alert, length = 2 Thread-8, RECV TLSv1 ALERT: fatal, handshake_failure Thread-8, called closeSocket() [Raw read]: length = 5 Thread-8, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 0000: 15 03 03 00 02 ..... [Raw read]: length = 2 0000: 02 28 .( Thread-7, READ: TLSv1.2 Alert, length = 2 Thread-7, RECV TLSv1 ALERT: fatal, handshake_failure Thread-7, called closeSocket() Thread-7, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure #### Java Web Start Error: #### Unable to load resource: https://ADDRESS/FILE.jar

ADDRESS / FILE.jar existiert (wie gesagt im Hauptposting) - wenn ich "Use TLS 1.2" einschalte, lädt die Datei OK.

1
Könnten Sie mit `-Djavax.net.debug = all` oder` -Djavax.net.debug = ssl: handshake: verbose` ausführen, um eine ausführlichere Ausgabe über den Handshake-Fehler zu erhalten? Cyrbil vor 8 Jahren 0
Natürlich habe ich meinen Beitrag aktualisiert Buffalo vor 8 Jahren 0
Blind Shooting, setzen Sie `deploy.security.TLSv1` auf _false_,` deploy.security.TLSv1.2` auf _true_ und `https.protocols` auf _TLSv1.2_, um eine Änderung vorzunehmen? Cyrbil vor 8 Jahren 0
Leider funktioniert es nicht - dieselbe Ausnahme. Buffalo vor 8 Jahren 0
Ich habe keine Umgebungseinstellungen, die ich ausprobieren und testen kann, daher kann ich Ihnen hier nicht wirklich weiterhelfen. Normalerweise denke ich, dass tls auf die Serverversion zurückgreifen würde, aber es scheint mit TLSv1 standardmäßig auf java7 suborn zu sein. Außerdem werden alle Versionen unterstützt. Ich unterstütze Ihre Frage in der Hoffnung, dass Sie bessere Aufmerksamkeit erhalten. :) Viel Glück. Cyrbil vor 8 Jahren 0
OK, danke für deine Hilfe :) Buffalo vor 8 Jahren 0

1 Antwort auf die Frage

0
eggheadmike

Leider denke ich, dass Sie mit der Java Control Panel-Lösung festhalten. Der Grund dafür ist, dass Client und Server als Teil des TLS-Handshakes eine miteinander kompatible Verschlüsselungssuite einrichten müssen. In diesem Fall ist Ihre lokale Java-Laufzeitumgebung der "Client", und die Cipher Suite-Voreinstellungen werden von der Systemsteuerung gesteuert. Die JNLP-Konfiguration kann dies nicht sofort ändern, und das mit gutem Grund - stellen Sie sich die umgekehrte Situation vor, in der der Client eine Verschlüsselung mit niedrigerer Sicherheit akzeptieren muss.

Angenommen, Ihr Server unterstützt TLS 1.2 und TLS 1.1 (in dieser Reihenfolge). Wenn Ihr Client nur TLS 1.0 und SSL v2 unterstützt, gibt es keine für beide Seiten akzeptablen Verschlüsselungssammlung und der Handshake schlägt fehl. Der Handshake ist nur erfolgreich, wenn Ihr Client TLS 1.1, TLS 1.2 oder beide unterstützt. Beachten Sie, dass die Reihenfolge auf dem Client keine Rolle spielt, da der Server die höchstmögliche Sicherheitsstufe verwenden möchte, die der Client unterstützt.

Verwandte Probleme