(Отказ от ответственности: я ни на что не похож ни эксперт по безопасности, ни эксперт по Windows)
Установка:
- сервер с нашей стороны: Java 1.6 (уже добавлен bouncycastle в файл безопасности) на сервере Windows 2003
- сторонний клиент: сервер Windows 2008 с biztalk
- все свойства системы повторного согласования, введенные в результате атаки повторного согласования, «включены» на стороне сервера (я не знаю, насколько это безопасно)
В идеале мы хотим исправить это с нашей стороны, но при необходимости можно предложить исправление клиенту.
Клиентский сервер должен подключиться к нашему серверу по соединению HTTPS, но он всегда терпит неудачу, wireshark показывает следующий диалог:
> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message
В соответствии с RFC (http://www.ietf.org/rfc/rfc2246.txt) предупреждение (21) относится к неудачной расшифровке, и из того, что я вижу в wireshark, ни один из шифров, предложенных клиентом, фактически не поддерживается JRE 1.6 (согласно ) http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SupportedCipherSuites)
Стремясь воспроизвести ошибку, чтобы можно было рассмотреть ее поближе, я протестировал с другим программным обеспечением:
- wfetch на Windows XP с выбранным «https» выполнит начальное клиентское рукопожатие в SSLv2, сервер переключится на TLSv1 для ответа, это работает
- wfetch на Windows XP с настроенным на использование «TLSv1» для первоначального рукопожатия не будет работать так же, как сервер biztalk
- wfetch в windows 2008 с настроенным https использует TLSv1 для первоначального рукопожатия и завершается сбоем так же, как сервер biztalk
- IE (в windows xp) сначала попытается получить рукопожатие TLSv1 с тем же неудавшимся результатом, но сразу попытается снова, используя SSLv3, который работает
(на данный момент я полагаю, что все программное обеспечение Microsoft использует центральную конфигурацию, доступную по адресу HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ Schannel)
- firefox использует SSLv3 для всего разговора, поэтому никаких проблем нет
- OpenSSL выполняет первоначальное рукопожатие в SSLv2, и сервер переключается на TLSv1, когда он отвечает, никаких проблем там нет
- OpenSSL также может быть вынужден выполнить первоначальное рукопожатие в TLSv1, он предлагает список из 27 шифров (в отличие от 11 шифров, предлагаемых программным обеспечением на базе Windows) и может подключаться без проблем
На мой неопытный взгляд, это подтверждает идею о том, что несовместимое предложение шифра является основной причиной, когда Windows поддерживает только наборы шифров, которые не поддерживаются JVM (для TLSv1).
Я установил надувной замок в качестве дополнительного поставщика в файле java.security, но безрезультатно.
Я искал «высоко» и «низко» и нашел только ссылку, что, возможно, websphere поддерживает Windows-шифры для TLSv1, но не может загрузить автономного поставщика для его тестирования.
JRE 1.7 не поддерживается программным обеспечением, которое мы запускаем на нашей JVM, поэтому обновление не вариант (возможно, провайдер безопасности может быть безопасно понижен? Хотя я еще не нашел для него загрузку)
Я не нашел способа добавить шифр в окна, за исключением написания кода на C ++ (я безрезультатно поиграл с вышеупомянутыми настройками реестра).
Итак, в заключение я хотел бы знать, исправит ли это что-то из следующего и как их следует выполнить:
- добавить провайдера в jvm, который может работать с шифрами для TLSv1, которые предлагаются windows
- каким-то образом заставить клиента выполнить первоначальное рукопожатие в SSLv3 (предпочтительно не SSLv2) или, по крайней мере, повторить попытку, если сбой рукопожатия TLSv1
- каким-то образом добавить JVM-поддерживаемый шифр для TLSv1 в клиентские окна
Любые другие решения, конечно, также приветствуются.
EDIT
Версия Java Java version (64 bit): 1.6.0_19-b04.
Список предлагаемых шифров:
- TLS_RSA_WITH_RC4_128_MD5
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
- TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_DES_CBC_SHA
- TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
Установлены файлы политики криптографии с неограниченной силой. Я попытался установить javax.net.debug=all и запустил сервер с консоли, никаких дополнительных выходных данных не появилось. Я установил sun.security.ssl.allowUnsafeRenegotiation=true безрезультатно.
РЕДАКТИРОВАТЬ 2
Оказывается, программное обеспечение, которое мы используем, использует собственный стек для HTTP вместо стандартного. Было выпущено исправление, которое, похоже, решило проблему, хотя я не знаю точно, какая часть запроса TLS вызвала ошибку (учитывая, что большинство рукопожатий TLSv1 все-таки успешно).
Спасибо за отзыв, это был интересный, но тщетный поиск. Живи и учись.