Https: как поддерживать все протоколы SSL/TLS и наборы шифров?

Я работаю над поисковым роботом, которому необходимо отправлять HTTPS-запросы на различные серверы. Из-за этого я хотел бы, чтобы мой сканер поддерживал все возможные протоколы/шифры.

В настоящее время я использую Java 8, но готов обновиться (не думаю, что это имеет значение).

Я создал SSLContext следующим образом:

SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

Я предполагаю, что каждый сервер, поддерживающий TLSv1.3, также поддерживает 1.2.

Это будет обратно совместимо? т.е. поддерживает TLS 1.1/1.0 и SSL?

(Кстати, в настоящее время используется SSL?)

Что еще мне нужно сделать, чтобы пообещать успешное рукопожатие SSL/TLS?

Спасибо!

Не похоже, что вы наткнулись на стену, которая мешает вам двигаться вперед. Так почему бы вам просто не перейти к стандартной конфигурации и не посмотреть, что произойдет. В большинстве случаев рукопожатие tls разрешается правильно. А в тех случаях, когда это не так, обычно это какая-то неправильная конфигурация на сервере или самозаверяющий сертификат. В этих случаях вам следует избегать доступа к серверу.

Juan 21.05.2019 23:28

@ Хуан, я тебя понимаю. кстати, не лучше ли выбрать SSLContext.getInstance("TLS") вместо SSLContext.getInstance("TLSv1.2")?

yaseco 21.05.2019 23:32
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
2
2
1 262
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Because of that, I'd like my crawler to support all possible protocols/ciphers.
I'm currently using Java 8 but willing to upgrade (don't think it matters).

I guess that every server that supports TLSv1.3 supports 1.2 as well.
Is this going to be backward compatible? i.e. support TLS 1.1/1.0 and SSL?
(Is SSL even being used nowadays btw?)

Да, по крайней мере, в ближайшем будущем почти все, кто поддерживает 1.3, будут поддерживать и 1.2, за исключением нескольких сайтов, созданных специально для проверки совместимости с 1.3. (Бьюсь об заклад, многие даже продолжат поддерживать 1.1, например, PCI по-прежнему разрешает это, хотя и неохотно, но вам это не нужно; любая Java, поддерживающая 1.1, также поддерживает 1.2.) Контекст TLSv1.2 поддерживает более низкие версии (если разрешено, см. ниже), а контекст TLS по умолчанию также поддерживает 1.2 и ниже в j8 (по умолчанию в j7нет поддерживал 1.1 и 1.2 на стороне клиента).

Никто не должен использовать SSLv3 не позднее 2016 г. и выпуски Java, поскольку j8u31 в 2014-12 годах был настроен на запрет этого, хотя код все еще присутствует, если вы измените конфигурацию, чтобы разрешить это. Смотрите запись для jdk.tls.disabledAlgorithms в JRE/lib/security/java.security для j8 или JAVA/conf/security/java.security для j9 вверх. Обратите внимание, что этот тип «отключения» не может быть отменен с помощью кода, вызывающего SSLSocket.setEnabledProtocols и связанных с ним методов, только путем изменения конфигурации или свойства безопасности при запуске; в отличие от протоколов, «отключенных» по выбору контекста, можно включить, когда это необходимо, и наоборот.

Никто не должен был использовать SSLv2 с начала века (либо 2000, либо 2001, в зависимости от того, насколько вы педантичны; в этом случае разница не имеет значения). В Java это не реализовано (и никогда не было).

Использование TLSv1.0 в настоящее время спорно. Теоретически он уязвим для BEAST, но в конце концов это оказалось не слишком опасным, и теперь его можно еще больше уменьшить за счет разделения данных приложения 1/n. Поскольку Java включает его по умолчанию, я бы не стал его удалять, но вы можете быть несколько осторожны с любыми обнаруженными вами серверами, которые на самом деле выбирают его.

Вы не можете поддерживать все наборы шифров, потому что Java не реализует их все; к счастью, вам это не нужно. Никто в интернете не использует PSK (кроме варианта для возобновления в 1.3) SRP или Kerberos; Java реализует только последнее. Вероятно, нет или очень мало требовать Camellia SEED ARIA IDEA или AES-CCM, ни один из которых не реализован в Java (по крайней мере, в стандартных криптопровайдерах), хотя вы можете встретить некоторые из них, которые поддерживают по крайней мере некоторые из них, если они предлагаются. Никто должен не поддерживает RC4, пакеты «экспорт», «eNULL» и одиночный DES; снова выпуски Java запретили RC4 в java.security с тех пор, как 8u60 в 2015-08 годах, а остальные долгое время отключались по умолчанию вместе с «анонимными» наборами (также известными как «aNULL»). Это последнее - единственное, что я хотел бы изменить; Я могу представить себе редкие, но разумные случаи запуска общедоступного сервера без проверки подлинности сертификата, но в остальном безопасного.

Но есть параметры безопасности, отличные от протокола и шифра, которые могут предотвратить соединение. В частности, Java теперь настроен на отклонение рукопожатий с использованием ключа или параметров, слишком коротких для обеспечения безопасности, или сертификатов, подписанных с использованием MD5, который для этой цели взломан, даже если они используются в наборе шифров, приемлемом для обеих конечных точек. Эти настройки аналогичны disabledAlgorithms с настройками для сертификатов также в jdk.certpath.disabledAlgorithms, и вам может потребоваться их ослабить. Существует некоторый риск того, что ваши соединения, использующие ослабленные параметры, могут быть скомпрометированы, но поскольку у вас, предположительно, нет конфиденциальной информации для отправки на неизвестные серверы, и вы все равно не будете доверять полученной от них информации, такая компрометация может быть невозможна. проблема.

Следующим и, вероятно, самым важным является проверка сертификата. Вы столкнетесь со многими сайтами, использующими сертификаты, которые на самом деле недействительны, и многие другие, которые не могут быть проверены в стандартном хранилище доверенных сертификатов Java JRE/lib/security/cacerts или аналогичном, таком как Windows или Mozilla. Поскольку вам, по-видимому, все равно, получаете ли вы данные с реального или законного сервера, вы можете игнорировать ошибки сертификата, используя нестандартный TrustManager, который просто возвращает успех без фактической проверки цепочки сертификатов сервера вообще. Если вы ищете другие вопросы на SO, вы можете найти, вероятно, сотню, где кто-то предлагает «решить» проблему TLS или https в Java, «просто вырезать и вставить этот TrustManager, чтобы решить все проблемы без каких-либо мыслей, понимания или усилий». Во многих случаях это предлагается людьми, которые на самом деле не понимают TLS, для проблем, которые в первую очередь не являются проблемами с сертификатом, поэтому «решение» не помогает и просто делает систему полностью небезопасной, если и когда актуальные проблемы исправлены. Я думаю, что это первый вопрос, который я видел, где это решение действительно уместно.

Наконец, в TLS есть номинально необязательная функция, индикация имени сервера (SNI), которая теперь требуется многим серверам, особенно CDN, WAF, IDS/IPS и подобным вещам, которые обрабатывают трафик для нескольких доменов. В зависимости от того, какие API и параметры вы используете для подключения, старые версии Java не всегда отправляли SNI. Тем не менее, недавний j8 и выше должны делать это, если вы не отключите его намеренно — и вы можете найти несколько сломанных серверов, где вам делать нужно отключить его как этот недавний вопрос.

Я не мог и мечтать о лучшем ответе - Большое спасибо!

yaseco 22.05.2019 14:14

Другие вопросы по теме