Gfrktyl

is it possible to turn on TLS 1.2 in .jnlp file to download .jar from HTTPS server where only TLS 1.2 is set? I've tried in many ways:

<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>

but none of them works - during launching jnlp (downloading .jar) I get exception:

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

(...)

If I set "Use TLS 1.2" setting in Java Control Panel, everythings works - I can download jar and my app starts successfully.
But I'd like to turn on TLS 1.2 in jnlp file regardless of setting in JCP, because many of my clients still use Java 7 and I'd like to do it without their action.

UPDATE:

Here is a fragment (end) of Console tab, when I launch jnlp via command:

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 exists (as I said in main post) - if I turn "Use TLS 1.2" on, the file downloads OK.

Unfortunately I think you are stuck with the Java Control Panel solution. The reason for this is that client and server must establish a mutually compatible cipher suite as part of the TLS handshake. In this case, your local Java Runtime Environment is the "client," and its cipher suite preferences are governed by the Control Panel. JNLP configuration cannot change this on the fly, and with good reason -- imagine the reverse situation, in which the client is forced to accept a lower-security cipher.

For example, let's say your server supports TLS 1.2 and TLS 1.1 (in that order of preference). If your client only supports TLS 1.0 and SSL v2 then there is no mutually agreeable cipher suite, and the handshake fails. The handshake only succeeds if your client supports TLS 1.1, TLS 1.2, or both. Note that order doesn't matter on the client, since the server wants to use the highest possible level of security that the client supports.