É possível ativar o TLS 1.2 no arquivo .jnlp?

Question

é possível ativar o TLS 1.2 no arquivo .jnlp para fazer o download de .jar do servidor HTTPS em que apenas o TLS 1.2 está configurado? Eu tentei de várias maneiras:

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

mas nenhum deles funciona - durante o lançamento do jnlp (download .jar) recebo uma exceção:

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

Se eu definir a configuração "Usar TLS 1.2" no Painel de Controle Java, tudo funcionará - posso baixar o jar e meu aplicativo é iniciado com êxito. Mas gostaria de ativar o TLS 1.2 no arquivo jnlp, independentemente da configuração no JCP, porque muitos dos meus clientes ainda usam o Java 7 e gostaria de fazê-lo sem a ação deles.

UPDATE :
Aqui está um fragmento (final) da aba Console, quando eu lanço o jnlp via comando:
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 existe (como eu disse no post principal) - se eu ativar o "Use TLS 1.2", o download do arquivo será OK.

    

Answer 1

Infelizmente, acho que você está preso à solução Java Control Panel. A razão para isso é que o cliente e o servidor devem estabelecer um conjunto de criptografia mutuamente compatível como parte do handshake TLS. Nesse caso, seu Java Runtime Environment local é o "cliente" e suas preferências de conjunto de codificação são controladas pelo Painel de Controle. A configuração do JNLP não pode mudar isso imediatamente, e com uma boa razão - imagine a situação inversa, na qual o cliente é forçado a aceitar uma cifra de segurança menor.

Por exemplo, digamos que seu servidor suporte o TLS 1.2 e o TLS 1.1 (nessa ordem de preferência). Se o seu cliente suportar apenas o TLS 1.0 e o SSL v2, não haverá um conjunto de criptografia mutuamente aceitável e o handshake falhará. O handshake só será bem-sucedido se o cliente suportar o TLS 1.1, o TLS 1.2 ou ambos. Observe que a ordem não importa no cliente, já que o servidor deseja usar o nível mais alto possível de segurança que o cliente suporta.