Ошибка рукопожатия при обмене данными между Java 1.7 и Java 1.8

У меня проблемы с вызовом служб с Java 1.7 на Java 1.8. Я постараюсь объяснить, что я делаю.

Версия java сервера 1 - 1.7.0_79 (к сожалению, я не могу это изменить). Я использую Spring Rest Template для общения. Я понимаю, что 1.7 использует TLS1, а Java 8 использует TLS1.2. Я пробовал эту связь с обеими сторонами в версии 1.8, и я смог общаться, поэтому я уверен, что с сертификатом все в порядке.

Я использовал команду для проверки шифра, используемого сервером 2.

$ openssl s_client -connect <server>:8443 -tls1_2

и получил ответ

..... Long certificate chain

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: AC92BFBC090F4245271C10B9C5B968D1845278AE03714ED5806B4929DC3D0CC9

Так что, на мой взгляд, сервер использует этот протокол и шифр. Так что, если я использую тот же протокол и шифр, я смогу общаться. Чтобы еще раз убедиться, что этот конкретный шифр существует, я попросил своего коллегу выполнить следующую команду на сервере 2.

openssl ciphers -v

и получил следующий ответ

... lot of ciphers
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

Поэтому я уверен, что сервер поддерживает ECDHE-RSA-AES128-GCM-SHA256, и я внес изменения в SSLConnectionSocketFactory моего шаблона Rest.

public SSLConnectionSocketFactory sslConnectionSocketFactory() throws Exception {

        return new SSLConnectionSocketFactory(sslContext(),
                new String[] {
                        "TLSv1.2"
                },
                new String[] {
                        "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
                },
                NoopHostnameVerifier.INSTANCE);
    }

Но я все еще получаю ошибку

"Unsupported ciphersuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"

Не могли бы вы направить меня в правильном направлении? Я много искал, но не мог найти решение. Заранее спасибо.


person Sandeep Kumar    schedule 25.11.2020    source источник
comment
Где вы запускаете свою команду openssl? Это из той же среды, в которой вы запускаете свой RestTemplate клиент?   -  person Savior    schedule 25.11.2020
comment
TLS 1.2 можно включить в настройках среды: stackoverflow.com/questions/39157422/ Вы пробовали?   -  person Alex Chernyshev    schedule 25.11.2020
comment
@ Алекс Чернышев Я пытался это сделать, но это не сработало. Я думаю, что моя версия Java 1.7.0_79, и я думаю, что эти переменные работают для более поздних версий. К сожалению, я не могу изменить версию Java.   -  person Sandeep Kumar    schedule 25.11.2020
comment
@Savior Server 1 работает под управлением 1.7, а на нем работает шаблон spring. Я запустил ``` openssl s_client -connect ‹Server 2›:8443 -tls1_2``` и получил ..... Long certificate chain SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: AC92BFBC090F4245271C10B9C5B968D1845278AE03714ED5806B4929DC3D0CC9 Сервер 2 работает 1.8 openssl ciphers -v запущен на сервере 2, который дал ответ ... lot of ciphers ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD   -  person Sandeep Kumar    schedule 25.11.2020
comment
@SandeepKumar, вы можете попробовать сделать обратное: разрешить старый TLS на стороне Java8, он там из-за обратной совместимости, но просто отключен по умолчанию.   -  person Alex Chernyshev    schedule 25.11.2020
comment
@Alex Chernyshev Мы не владеем этими серверами и не контролируем их. Кроме того, я думаю, что TLS1 небезопасен, как TLS1.2.   -  person Sandeep Kumar    schedule 25.11.2020
comment
Я использовал сценарий, приведенный в заголовке superuser.com/questions/109213/, чтобы перечислить, какие шифры успешно используются при рукопожатии, и только одно соединение было успешным - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Я использовал то же самое в RestTemplate все та же ошибка - Unsupported ciphersuite -. Это так расстраивает.   -  person Sandeep Kumar    schedule 25.11.2020
comment
Запуск openssl ciphers на server2 сообщает вам, что поддерживает OpenSSL, а НЕ то, что поддерживает Java8, если только сервер на самом деле не использует OpenSSL, например Tomcat/JbossWS/Wildfly в собственном режиме/режиме APR, и даже в этом случае часто используется встроенная копия OpenSSL, а не командная строка. один. В любом случае, бесплатные версии Oracle Java 7, включая 7u79, НЕ ПОДДЕРЖИВАЮТ НАБОРЫ ШИФРОВ GCM. (Они добавлены в ПЛАТНУЮ версию 7u191 и МОГУТ быть в версиях OpenJDK.) Если сервер поддерживает только набор шифров GCM, вы не можете подключиться к нему, кроме как через прокси или ретранслятор.   -  person dave_thompson_085    schedule 25.11.2020
comment
Извините, я имел в виду, они работают на одном хосте или соединение идет через Интернет?   -  person Savior    schedule 25.11.2020
comment
@ dave_thompson_085 оба сервера работают в офисной локальной сети с использованием openjdk, и оба сервера работают под управлением JBoss. Чего я не понимаю, так это того, что скрипт на superuser.com/questions/109213/ может успешно подключиться с использованием TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, тогда почему он выдает ошибку, когда я его использую из программы.   -  person Sandeep Kumar    schedule 26.11.2020
comment
Если вы имеете в виду сценарий в первом и принятом ответе по этой ссылке, он использует OpenSSL (в частности, командную строку openssl, которая вызывает библиотеки OpenSSL libssl и libcrypto) версии, которая, по-видимому, поддерживает наборы шифров GCM. Ваша клиентская программа - это Java, а обычная Java не использует OpenSSL, хотя «родной» Wildlfly может использовать incoming. Java-реализация SSL/TLS называется JSSE, и, как я уже сказал, JSSE в Oracle Java 7, за исключением недавних платных версий, которых у вас нет, не поддерживает наборы шифров GCM. Вот почему в исключении написано «Не поддерживается»; значит не поддерживается.   -  person dave_thompson_085    schedule 26.11.2020


Ответы (1)


Как упомянул @dave_thompson_085, проблема была с набором шифров. Я должен был узнать раньше :) На втором сервере было только 2 набора шифров для TLS 1.2 (не знаю, почему и как), и оба были GCM и не поддерживались моим сервером. Спасибо за помощь всем.

person Sandeep Kumar    schedule 27.11.2020