Можно ли включить TLS 1.2 в файл .jnlp?

3264
Buffalo

Можно ли включить TLS 1.2 в файле .jnlp для загрузки .jar с HTTPS-сервера, где установлен только TLS 1.2? Я пробовал во многих отношениях:

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

но ни одна из них не работает - во время запуска jnlp (загрузка .jar) я получаю исключение:

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


Если я установлю параметр «Использовать TLS 1.2» в панели управления Java, все будет работать - я могу скачать jar, и мое приложение запустится успешно. Но я хотел бы включить TLS 1.2 в файле jnlp независимо от настроек в JCP, потому что многие из моих клиентов все еще используют Java 7, и я хотел бы сделать это без их действий.


ОБНОВЛЕНИЕ :
Вот фрагмент (конец) вкладки Консоль, когда я запускаю jnlp с помощью команды:
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 существует (как я уже говорил в основном посте) - если я включу «Использовать TLS 1.2», файл загрузится ОК.

1
Не могли бы вы запустить с `-Djavax.net.debug = all` или` -Djavax.net.debug = ssl: handshake: verbose`, чтобы получить более подробный вывод о сбое рукопожатия? Cyrbil 8 лет назад 0
Конечно, я обновил свой пост Buffalo 8 лет назад 0
Слепая стрельба, вносит ли изменение значение параметра "deploy.security.TLSv1`" в значение _false_, `deploy.security.TLSv1.2` в значение _true_ и` https.protocols` в _TLSv1.2_? Cyrbil 8 лет назад 0
К сожалению, это не работает - то же самое исключение. Buffalo 8 лет назад 0
У меня нет настроек среды, чтобы попробовать и протестировать, поэтому я не могу вам сильно помочь в этом. Обычно я думаю, что tls вернется к серверной версии, но кажется, что по умолчанию на java7 он работает с TLSv1, и он поддерживает все версии ... Я поднимаю ваш вопрос, надеясь, что вы получите более пристальное внимание :) Удачи. Cyrbil 8 лет назад 0
ОК, спасибо за попытку помочь :) Buffalo 8 лет назад 0

1 ответ на вопрос

0
eggheadmike

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.

Похожие вопросы