Основанные на 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.
Chrome 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 (который в Сервере 2 008 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 подписало сертификат - но это, кажется, невозможно. Действительно ли я прав относительно этого?
Ссылки 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
I ' я загрузил скомпилированную мной версию в 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-шифрование. Бит шифрования в строке дескриптора набора шифров - это бит непосредственно перед « WITH ».
Итак, в вашем случае вам нужно что-то с «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" в конце каждой строки. Это не относится к тому, что находится в сертификате. Он относится к тому же алгоритму, но не к его применению в сертификате.