Ошибка рукопожатия TLSv1

(Отказ от ответственности: я ни в какой степени не представляю себе эксперта по безопасности или эксперта по Windows)

Настройка:

• сервер на нашем конце: java 1.6 (уже добавлен bouncycastle в файл безопасности) на сервере Windows 2003
• сторонний клиент: сервер Windows 2008 с biztalk
• все свойства системы перерегистрации, введенные из-за атаки на перезаключение, "включены" на стороне сервера (небезопасно я знаю)

В идеале мы хотим исправить это с нашей стороны, но при необходимости можно предложить исправление для клиента.

Клиентский сервер должен подключиться к нашему серверу по HTTPS-соединению, но он всегда терпит неудачу, wirehark показывает следующий диалог:

> TLSv1: Client Hello
< TLSv1: Alert (21): Unexpected Message

В соответствии с RFC (http://www.ietf.org/rfc/rfc2246.txt) предупреждение (21) относится к неудачному расшифровке и из того, что я могу видеть в wirehark, ни один из шифров, предложенный клиент фактически поддерживается 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) и может подключаться без проблем

Для моего неподготовленного взгляда это усиливает мысль о том, что несовместимое шифрованное предложение является основной причиной, когда окна поддерживают только комплекты шифров, которые не поддерживаются JVM (для TLSv1). Я установил bouncy castle в качестве дополнительного провайдера в файле java.security безрезультатно. Я искал высоко и низко и нашел только ссылку, которая, возможно, websphere поддерживает шифры Windows для TLSv1, но не может загрузить автономный провайдер для ее проверки. JRE 1.7 не поддерживается программным обеспечением, которое мы запускаем на нашей JVM, поэтому обновление не является вариантом (возможно, поставщик безопасности может быть безопасно понижен? Я еще не нашел для него загрузку) Я не нашел способ добавить шифрование к окнам, не написав С++-код (я играл с вышеупомянутыми параметрами реестра без эффекта).

Итак, в заключение я задаюсь вопросом, исправит ли одно из следующих вещей и как они должны быть выполнены:

• добавить провайдера в jvm, который может работать с шифрами для TLSv1, которые предлагаются окнами
• каким-то образом заставить клиента выполнить начальное рукопожатие в SSLv3 (желательно не SSLv2) или, по крайней мере, повторить попытку, если сообщение подтверждения TLSv1 не выполнено.
• каким-то образом добавить JVM-поддерживаемый шифр для TLSv1 в клиентские окна

Разумеется, также приветствуются любые другие решения.

ИЗМЕНИТЬ

Версия 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 преуспели).

Спасибо за отзыв, это был интересный, если бесполезный поиск. Живи и учись.