2 votes

Est-il possible d'activer TLS 1.2 dans le fichier .jnlp ?

Est-il possible d'activer TLS 1.2 dans le fichier .jnlp pour télécharger .jar à partir d'un serveur HTTPS où seul TLS 1.2 est activé ? J'ai essayé de plusieurs façons :

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

mais aucune ne fonctionne - lors du lancement de jnlp (téléchargement de .jar), je reçois une 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
(...)

Si j'active le paramètre "Use TLS 1.2" dans le panneau de contrôle Java, tout fonctionne - je peux télécharger le jar et mon application démarre avec succès. Mais j'aimerais activer TLS 1.2 dans le fichier jnlp indépendamment du paramètre dans le JCP, parce que beaucoup de mes clients utilisent encore Java 7 et j'aimerais le faire sans leur intervention.

MISE À JOUR :
Voici un fragment (fin) de l'onglet Console, lorsque je lance jnlp par commande :
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 (comme je l'ai dit dans le message principal) - si j'active "Use TLS 1.2", le fichier se télécharge correctement.

1voto

GendoIkari Points 922

Malheureusement, je pense que vous êtes coincé avec la solution du panneau de contrôle Java. La raison en est que le client et le serveur doivent établir une suite de chiffrement mutuellement compatible dans le cadre de la poignée de main TLS. Dans ce cas, votre environnement d'exécution Java local est le "client" et ses préférences en matière de suite de chiffrement sont régies par le panneau de configuration. La configuration JNLP ne peut pas changer cela à la volée, et ce pour une bonne raison : imaginez la situation inverse, dans laquelle le client est forcé d'accepter un chiffrement de moindre sécurité.

Par exemple, disons que votre serveur prend en charge TLS 1.2 et TLS 1.1 (dans cet ordre de préférence). Si votre client ne prend en charge que TLS 1.0 et SSL v2, il n'y a pas de suite de chiffrement mutuellement acceptable et la poignée de main échoue. La poignée de main ne réussit que si votre client supporte TLS 1.1, TLS 1.2 ou les deux. Notez que l'ordre n'a pas d'importance pour le client, puisque le serveur veut utiliser le niveau de sécurité le plus élevé possible que le client prend en charge.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X