Java 7 oracle не поддерживает TLSv1.2
Java 7 oracle не поддерживает TLSv1.2. Я пытался запустить свой код, и я попробовал следующие вещи:
System.setProperty("deployment.security.TLSv1.1", "false")
System.setProperty("deployment.security.TLSv1", "false")
System.setProperty("deployment.security.TLSv1.2", "true")
System.setProperty("https.protocols", "TLSv1.2")
System.setProperty("https.cipherSuites", "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,AES_256_GCM,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384")
и это не помогает.
Как я могу заставить мое приложение Java7 использовать Tlsv1.2. Я могу запустить свою программу, используя java8, которая по умолчанию использует TLS1.2, и все работает отлично.
Как я могу сделать это в Java7 от оракула.
Я также пытался войти в /usr/lib/jvm/java-7-oracle/jre/lib/security и отключен jdk.tls.disabledAlgorithms=SSLv2Hello, SSLv3, TLSv1 но это все равно не работает.
Что я не прав?
Кстати, я получаю sslhandshakeexception-handshake-failure
РЕДАКТИРОВАТЬ:
Ошибка:
0000: 02 28 .(
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
166 [main] DEBUG org.apache.http.impl.conn.DefaultClientConnection - Connection org.apache.http.impl.conn.DefaultClientConnection@6b18e1c6 closed
166 [main] DEBUG org.apache.http.impl.conn.DefaultClientConnection - Connection org.apache.http.impl.conn.DefaultClientConnection@6b18e1c6 shut down
main, called close()
main, called closeInternal(true)
[main] DEBUG org.apache.http.impl.conn.BasicClientConnectionManager - Releasing connection org.apache.http.impl.conn.ManagedClientConnectionImpl@1f2dc289
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:1979)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:533)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:401)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:72)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:214)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:160)
4 ответа
Я отвечу на мой собственный вопрос, если у кого-то есть подобная проблема:
Я потратил 2 дня, чтобы попробовать все, и наконец я понял это.
В Java-7-oracle невозможно использовать TLS1.2. Даже настройка его с помощью System Properties или даже настройка на уровне SSLContext мне не помогла. Их поддержка очень плохая. Хотя в Java-8-oracle, это возможно.
Просто меняю Java на java-7-openjdk-amd64 сделал трюк для меня.
Я столкнулся с той же проблемой и, так как я делал свои запросы, используя клиентскую библиотеку Apache HTTP, я решил ее, инициализируя свой HttpClient таким образом
CloseableHttpClient client = HttpClients.custom()
.setSSLSocketFactory(getSSLContext())
.build();
где getSSLContext() метод это
private SSLConnectionSocketFactory getSSLContext() throws NoSuchAlgorithmException {
return new SSLConnectionSocketFactory(
SSLContext.getDefault(),
new String[]{"TLSv1.2"},
null,
new NoopHostnameVerifier());
}
У меня были похожие проблемы: я не смог включить TLSv1.2 в Java JDK 1.7.0_80 в WebLogic 10.3, мы обновили его до JDK 1.7.0_181, и он начал работать для нас.
Вы можете обновить версию Java 7 до 1.7.0_131-b31.
Для JRE 1.7.0_131-b31 на сайте Oracle:
TLSv1.2 и TLSv1.1 теперь включены по умолчанию на конечных точках клиента TLS. Это поведение похоже на то, что уже происходит в выпусках JDK 8.
У меня были похожие проблемы, и мне потребовалось несколько дней, чтобы решить все мои проблемы. Я не могу обновить свою версию JRE, так как она работает на HSM. Может быть, есть другие, кроме меня, с такими требованиями.
ДАННЫЙ:
- JRE 1.7.0_25
- TOMCAT 8.0.9
ТРЕБОВАНИЕ: веб-приложение, работающее на Tomcat, должно иметь возможность подключаться к сокету через TLSv1.2.
Проблема 1:
JRE 1.7.0_25 не может самостоятельно подключиться к сокету через TLSv1.2.
Решение:
Для этого используйте библиотеку BouncyCastle: https://www.bouncycastle.org/
Проблема 2 (для решения этой проблемы потребовалось несколько дней):
BouncyCastle был активирован и добавлен к провайдеру безопасности в первую очередь, но по-прежнему не используется при создании SSLContext и других экземпляров (Certificat, KeyStore, TrustManager).
Решение:
Принудительно используйте BouncyCastle в качестве службы безопасности в JSSE с помощью следующего кода:
BouncyCastleProvider provider = new BouncyCastleProvider();
Security.insertProviderAt(new BouncyCastleJsseProvider(provider), 1);
Security.insertProviderAt(provider, 2);
Вместо того:
Security.insertProviderAt(new BouncyCastleProvider(), 2);
Security.insertProviderAt(new BouncyCastleJsseProvider(), 1);
Но это привело меня к следующей проблеме:
Проблема 3:
java.lang.SecurityException: JCE не может аутентифицировать поставщика BC
Решение:
Последний jar-файл BouncyCastle (bcprov-jdk15on-162.jar), а также предыдущий (bcprov-jdk15on-161.jar) неправильно подписаны для 1.7.0_25, но bcprov-jdk15on-160.jar подписаны. После использования версии 160 я наконец смог подключиться к сокету через TLSv1.2 с помощью следующего кода:
private static SSLContext createSSLContextBouncy(String base64Cert) {
BouncyCastleProvider provider = new BouncyCastleProvider();
Security.insertProviderAt(new BouncyCastleJsseProvider(provider), 1);
Security.insertProviderAt(provider, 2);
LOGGER.debug("Using bouncy castle as security provider");
try {
byte[] certBytes = Base64.decodeBase64(base64Cert);
X509Certificate cert =
(X509Certificate) CertificateFactory.getInstance("X.509", "BC").generateCertificate(new ByteArrayInputStream(certBytes));
KeyStore keystore = KeyStore.getInstance("BKS", "BC");
keystore.load(null);
keystore.setCertificateEntry("alias", cert);
TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance("PKIX", "BCJSSE");
trustManagerFactory.init(keystore);
TrustManager[] trustManagers = trustManagerFactory.getTrustManagers();
SSLContext sslContext = SSLContext.getInstance("TLS", "BCJSSE");
sslContext.init(null, trustManagers, new SecureRandom());
return sslContext;
} catch (Exception e) {
throw new RuntimeException(e);
}
}
К сожалению, внутри Tomcat он все еще не работал.
Проблема 4:
Подключение к TLSv1.2 по-прежнему не работает, когда я запускаю код как веб-приложение (на Tomcat). Рукопожатие началось, но завершилось ошибкой "В соединении отказано".
Решение:
Версия Tomcat, работающая на HSM (возможно, также и на других), по какой-либо причине требует 30 секунд для рукопожатия, но конечная точка имеет тайм-аут на 10 секунд. Я тестировал другую версию Tomcat (8.0.37, поскольку у нас есть информация о том, что HSM, возможно, ее поддерживает), и она работала без сбоев.
Надеюсь, это кому-нибудь поможет.