Для исправленного Q:
Ваша первая ссылка на (Oracle, и, следовательно, OpenJDK) Java 7, а не 8; есть различия в поддержке шифровального набора TLS между 7 и 8, хотя они не влияют на названный вами шифровальный набор. Ваша ссылка для «до 1.8» предназначена для IBM Java, которая использует различные криптопроцессоры и не является хорошей документацией для крипто Oracle / OpenJDK. Обратите внимание, что вопрос по этой ссылке, в частности, "... комплекты шифров, которые поддерживаются IBM Java" - НЕ Oracle / OpenJDK Java. Для Oracle / OpenJDK 8 см. https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites, а для 11 см. https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names. Оба включают TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 и, как и ожидалось, работают в Oracle 11.0.2, а многочисленные версии 8. Все TLSv1.2, поддерживаемые в 8, все еще поддерживаются в 11, хотя 11 дополнительно поддерживает TLSv1.3 (который вы, очевидно, не используете).
Помимо того факта, что, как прокомментировано, настройки Java по умолчанию обычно лучше обеспечивают безопасность, чем переопределения людьми, которые не знают, что они делают, за исключением того, что вы сообщаете в своем другом Q (но не предоставил здесь)
javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature
никоим образом не означает, что указанный вами шифровальный пакет не поддерживается. Во-первых, пожалуйста, уточните, является ли ваше приложение клиентом или сервером TLS - даже если в протоколе application нет отношений клиент / сервер, в протоколе TLS всегда ; Вот как определяется TLS (и SSL до него) .
Во-вторых, следуйте стандартным инструкциям для отладки SSL / TLS = JSSE , запустив системное свойство javax.net.debug=ssl и покажите полученный результат (вероятно, только последние 100 строк или около того, потому что он довольно объемный).
Оригинальный Q был намного более неопределенным и, казалось, был о RC4, но на самом деле не был.
Текст вашего вопроса не дает никакого представления о том, какой «алгоритм набора шифров» вы имеете в виду, но вы пометили RC4-шифр. Если ваша проблема использует (любой из) наборы шифров, которые включают RC4 в TLS 1.2 или более ранней версии, то вам не следует. RC4 был запрещен для TLS с помощью RFC7465 в феврале 2015 года из-за быстрого развития криптоаналитических атак на него. Это относится ко всем версиям протокола TLS, существовавшим в 2015 году (1.0, 1.1 и 1.2), и был реализован всеми поддерживаемыми версиями Java: 8 от 8u60 и выше и все выпуски 9 и выше.
Если вы действительно хотите использовать RC4 и рисковать, кражи ваших данных - возможно, это на самом деле неверно, бессмысленно или иным образом бесполезно - либо измените настройку в файле java.security, либо вызовите Security.setProperty в начале вашей программы (до загрузки JSSE); см. Справочное руководство JSSE , например. для Java11 . Обратите внимание, что в j8 расположение файла другое, <JREhome>/lib/security/java.security. См. Также Проблема, связанная с RC4 после обновления Java 8 .
Если и когда вы (хотите или должны) использовать TLS 1.3, который поддерживает Java 11 и выше, это больше не вариант. TLS 1.3 поддерживает только шифры AEAD (или режимы), которых RC4, как первоначально определено, не имеет, и никакое предложение по конструкции AEAD на основе RC4 сегодня не будет принято.
С другой стороны, если вы просто хотите использовать хорошие, безопасные шифровальные наборы, ничего не меняйте и просто используйте значения по умолчанию. Значения по умолчанию являются значениями по умолчанию именно потому, что они безопасны, по крайней мере, насколько известно в настоящее время. Если аналитические достижения изменят это, тогда значения по умолчанию будут изменены соответствующим образом, и ваши программы, использующие их, также будут защищены без необходимости создавать, тестировать, распространять и проверять новые выпуски.