Назад | Перейти на главную страницу

Windows Server 2008 R2 - наборы шифров на основе SHA2

В настоящее время я занимаюсь обновлением сертификатов SSL для различных веб-сайтов, которыми я управляю, с сертификатов, совместимых с SHA1, на SHA2.

На сегодняшний день мы всегда использовали «RSA» в качестве механизма обмена ключами в наших сертификатах SSL, и поэтому я решил продолжить делать это при генерации запроса на подпись сертификата для заменяющих сертификатов.

В моей среде разработки я заменил несколько сертификатов и установил приоритеты для наборов шифров на основе SHA256 (SHA-2) на веб-серверах.

Я заметил, что Google Chrome 42 и Firefox 37.0.2 по-прежнему выбирают набор шифров на основе SHA1. TLS_RSA_WITH_AES_256_CBC_SHA. (Я еще не тестировал Internet Explorer должным образом)

Чтобы определить, какие наборы шифров поддерживают Chrome 42 и Firefox 37.0.2, я выполнил трассировку сети и обнаружил TLSCipherSuites в пределах ClientHello.

Хром 42:

TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: Unknown Cipher
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9E }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA { 0xC0,0x07 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_RC4_128_SHA { 0xC0,0x11 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_GCM_SHA256 { 0x00, 0x9C }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
TLSCipherSuites: TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
TLSCipherSuites: Unknown Cipher

Firefox 37.0.2:

TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2B }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA { 0xC0,0x0A }
TLSCipherSuites: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA { 0xC0,0x09 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
TLSCipherSuites: TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
TLSCipherSuites: TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }

Веб сервер

Мои веб-серверы работают под управлением Windows Server 2008 R2 и поддерживают следующие наборы шифров (обратите внимание - это порядок предпочтений по умолчанию, с тех пор я установил приоритет для всех наборов на основе SHA256:

TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_RC4_128_MD5,SSL_CK_RC4_128_WITH_MD5,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA

Единственный набор шифров SHA256, представленный в Windows Server 2008 R2, который поддерживается Chrome 42 и Firefox 37.0.2, - это TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (который в Server 2008 R2 имеет _P256 добавлен к имени). Но для поддержки этого пакета мне пришлось бы перевыпустить наши сертификаты, изменив механизм обмена ключами с использованием RSA к ECDSA (Алгоритм цифровой подписи с эллиптической кривой). На самом деле я пробовал это, и он отлично работает, но многие старые браузеры не поддерживают криптографию с эллиптическими кривыми. Так что это не жизнеспособное решение.

Так есть ли способ заставить Firefox и Chrome выбирать набор шифров SHA256 на веб-сервере Windows Server 2008 R2, который не нарушает совместимость со старыми браузерами?
Можно ли добавить в ОС дополнительные комплекты шифров?

ОБНОВЛЕНИЕ 28/04/15:
Спасибо тем, кто ответил за дополнительную ясность относительно алгоритма обмена ключами и алгоритма подписи.

Я бы хотел, чтобы браузеры могли ~~с использованием набора шифров SHA256~~ выполнение аутентификации сообщения с помощью SHA2.

Но проблема остается в том, что из доступных наборов шифров SHA256 в Windows Server 2008 R2 единственный, поддерживающий как Chrome, так и Firefox, - это TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. И чтобы использовать этот набор шифров, мне нужен сертификат, подписанный ECDSA.

Насколько я понимаю, криптография с эллиптическими кривыми не поддерживает некоторые старые браузеры / операционные системы. Как упоминалось в моем вопросе (хотя я ошибся в терминологии), я действительно создал сертификат, подписанный ECDSA, и хотя я не проводил обширного тестирования, до сих пор я видел, что IE7 и IE8, работающие в Windows XP SP3, не могут загружать мои сайты (через HTTPS) и просто создайте сообщение «Internet Explorer не может отобразить веб-страницу».

Конечно, Windows XP теперь является устаревшей ОС, но я обеспокоен тем, что браузеры / операционные системы, которые «старые», но все еще «поддерживаются», могут таким же образом выйти из строя. Поэтому я заинтересован в поиске решения с использованием сертификата, подписанного RSA, но это кажется невозможным. Я прав насчет этого?

tls certificate

Ссылки SHA256, которые вы видите в списках шифровальных наборов, не предназначены для сертификатов. Скорее они связаны с псевдослучайной функцией TLS и целостностью сообщения.

Поддержка сертификатов не зависит от набора шифров TLS.

Все версии Firefox и Chrome (и последние версии IE) поддерживают сертификаты SHA256, если операционная система также поддерживает их, что для клиентской Windows является XP SP3 и выше. Server 2008 R2 имеет полную поддержку сертификатов SHA256.

Вы не хотите отдавать приоритет алгоритму MAC SHA256 над другими частями набора шифров. Это наименее важная часть. Набор шифров, который у вас должен быть сегодня во главе списка приоритетов на сервере IIS 7.5:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

Важнейшие части, которые нужно искать:

Шифр обмена ключами (ECDHE - лучший, эллиптическая кривая для скорости, эфемерный алгоритм Диффи-Хеллмана для прямой секретности)
RSA как алгоритм подписи сертификатов - как вы обнаружили, новые сертификаты ECDSA имеют проблемы совместимости со старыми клиентами.
Симметричный шифр. Лучше всего использовать 128-битный AES GCM, но у вас не может быть этого, а также оставить ECDHE / RSA в Windows в настоящее время. Следующим лучшим является AES CBC (128 или 256 бит).

Вам следует использовать IIS Crypto (https://www.nartac.com/Products/IISCrypto/) и выберите вариант наилучшей практики. Это даст вам лучший порядок набора шифров, который вы можете достичь в IIS в настоящее время.

Смотрите также мой ответ на этот вопрос:

Изменить механизм обмена ключами в IIS 8

Windows Server 2008 R2 включил шифрование после применения передовых методов шифрования IIS:

Чтобы получить список на стороне сервера, я обычно использую скомпилированную версию кода, доступную здесь в разделе «Список поддерживаемых наборов шифров»;

https://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx

Я загрузил скомпилированную мной версию в Dropbox, если вы хотите ее использовать (на ваш страх и риск, я не несу ответственности. Но это безопасно!)

https://www.dropbox.com/s/mvajmebtyilgics/listciphers.exe?dl=0

Ответ "Ричи Фрейма" точен. Строка набора шифров указывает не на SHA256 внутри подписи. Но в дополнение к ответу Ричи, вот еще один лакомый кусочек:

Но для поддержки этого пакета мне пришлось бы перевыпустить наши сертификаты, изменив механизм обмена ключами с использования «RSA» на «ECDSA» (алгоритм цифровой подписи с эллиптической кривой).

Вы не можете этого сделать. Механизм обмена сеансовыми ключами не закодировано внутри самого сертификата.

Вы смешиваете алгоритм обмена ключами и алгоритм подписи. Путаница в том, что RSA может выполнять как обмен ключами, так и подписи.

Это примерно так:

Для старой типичной установки у вас был бы сертификат, подписанный RSA, и вы также выполняли бы обмен ключами сеанса через RSA.
Для установки более нового типа у вас будет сертификат, подписанный RSA, и вы будете выполнять обмен сеансовыми ключами Диффи-Хеллмана. А затем аутентифицируйте этот анонимный обмен ключами с помощью ключей RSA сертификата.
Для современной установки современного типа у вас будет сертификат, подписанный ECDSA, и вы будете выполнять обмен сеансовыми ключами Elliptic-Curve-Diffie-Hellman (ECDH). А затем аутентифицируйте этот анонимный обмен ключами с помощью ключей ECDSA сертификата.

Обновление 2015-04-29: используйте сертификат sha256rsa

Поэтому я заинтересован в поиске решения с использованием сертификата, подписанного RSA, но это кажется невозможным. Я прав насчет этого?

Нет. К счастью, ты ошибаешься. Вы можете использовать оба в одном сертификате. SHA256 как односторонняя хеш-функция и RSA как алгоритм подписи. (Эта конкретная комбинация имеет кодовое название sha256WithRSAEncryption. Но есть и многие другие.) (Взгляните на https://www.ietf.org/. Прямо сейчас они используют именно эту комбинацию.)

Для совместимости я рекомендую вам почитать в блоге Ивана Ристича.

Иван Ристич, Прекращение поддержки SHA1: что вам нужно знать (Архивировано Вот.)

Одна из ссылок в этом блоге - это таблица совместимости GlobalSign SHA-256. Это может быть для вас особенно интересно.

Обновление 2015-04-29: вам нужно что-то с "RSA_WITH"
Если у вас есть сертификат RSA, значит, вы используете шифрование RSA. Бит шифрования в строке дескриптора набора шифров - это бит непосредственно перед "С УЧАСТИЕМ".

Итак, в вашем случае вам нужно что-то с «RSA_WITH» посередине. Я взял их из списка Firefox, который вы сделали выше:

TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 { 0xC0,0x2F }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
TLSCipherSuites: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x33 }
TLSCipherSuites: TLS_DHE_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x39 }
TLSCipherSuites: TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }

И не беспокойтесь о "SHA" или "SHA256" в конце каждой строки. Это делает не обратитесь к тому, что указано в сертификате. Он относится к тому же алгоритму, но не к его применению внутри сертификата.