Повышаем безопасность встроенных средств: включаем TLS 1.2, TLS 1.1

Затрагивает только софт который использует системные API для SSL: IE, WebDav redirector, update client, RDP, SQL NLA, RRAS…
Не затрагивает софт который со своими крипто средствами, типа: Firefox, Opera и тп.

По умолчанию в Windows 7 (остальные смотрите сами) использует TLS1.0 и SSLv3, также не использует сильные алгоритмы хеширования, обмена ключами, шифрования и их связки.
Однако данные алгоритмы реализованы и могут быть включены.

ВСЕ МОДИФИКАЦИИ НА СВОЙ СТРАХ И РИСК!!!
.reg файлы не публикую специально, чтобы было время для обдумывания перед примнением.

1. Если у вас установлены КриптоПро или ещё какие либо сторонние/дополнительные крипто средства — значения по умолчанию будут отличатся и при правке параметров это нужно учитывать, иначе что то можно сломать и потом долго искать причину и средство.

2. Есть реальная возможность сломать RDP на сервере выставив некоторые параметры, если других средств удалённого доступа (без TLS/SSL, типа telnet или ssh) не предусмотрено то придётся контактировать с ним физически.

Алгоритмы шифрования и обмена ключами

В реестре, по адресу:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010002
многостроковый параметр: Functions — определяет список доступных связок криптоалгоритмов и приоритет их использования в SSL/TLS

Если сравнить, то видно что я добавил «сильные связки» и оставил слабые.
Когда я удалил слабые, то Windows Update (который через интернет, а не локальный WSUS) перестал работать, поэтому пришлось вернуть.
Список алгоритмов можно посмотреть тут: gpedit.msc, Конфигурация компьютера, Административные шаблоны, Сеть, Параметры настройки SSL — Порядок комплектов шифров SSL
в описании этого параметра есть все доступные алгоритмы.
Пользоваться групповой политикой не стал — ограничение в 1023 знака, в такое даже алгоритмы по умолчанию не вписываются.

Результат, на примере IE11:
Было: SSL_PROTO:«TLSv1.2» SSL_CIPHER:«AES256-SHA256»
Стало: SSL_PROTO:«TLSv1.2» SSL_CIPHER:«ECDHE-RSA-AES256-SHA384»
(у меня на сервере жёстко заданы алгоритмы и для случая «было» согласование вообще не проходило пока я не добавлял более слабые связки алгоритмов)

Алгоритмы ЭЦП в SSL/TLS

Ключ: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCryptographyConfigurationLocalSSL0010003
многостроковый параметр: Functions — алгоритмы для ЭЦП в SSL/TLS (так же для работы с сертификатами)

Единственное, я немного переупорядочил их, на всякий случай.
Не так давно ECDSA/SHA512 и ECDSA/SHA384 в этом списке не было и страждущие добавляли их самостоятельно, но похоже какой то апдейт их туда добавил. Проверить не помешает.

Включение/отключение протоколов TSL/SSL

SSLv3 — пора закапывать, IMHO.
TLS1.0 — в принципе тоже, но на него завязана работа RDP и много кто только на нём сидит до сих пор. Поэтому безболезненно отключить его нельзя.
Тем временем МС рекомендует:

For new development, use Transport Layer Security 1.0.

при этом 1.1 и 1.2 они оставляют в подвешенном состоянии.

На TLS 1.0 в венде много завязано намертво, его отключение ломает RDP (испробовано на себе) и как минимум WebDav (видимо в бинарнике зашито, больше он ничего не хочет).

Подробности по включению/выключению: support.microsoft.com/kb/245030

Дополнительные настройки TSL/SSL

Раздел: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL
AllowInsecureRenegoClients, AllowInsecureRenegoServers — разрешить пересогласование на небезопасные варианты. Однозначно 0.

DisableRenegoOnClient, DisableRenegoOnServer — отключить пересогласование во время работы (насколько я понял про временный ключ шифрования). В дискуссиях/статьях упоминали что частое пересогласование — возможность DoS атаки, тк потребляет много ресурсов CPU.
Поставил 0: сервер у меня только RDP, а DoS-ить клиента не очень перспективно таким образом, к тому же функционал в принципе нужный.
Подробнее: www.atraining.ru/beast-move-from-ssl-to-tls/

UseScsvForTls — если выставить 1 то это отключит механизм пересогласования для совместимости со старыми реализациями TLS 1.0 (Vista без сп1). Ставим 0, чтобы включить расширение Renegotiation Info (RFC5746).
Подробности: blogs.msdn.com/b/jpsanders/archive/2010/09/08/understanding-problems-with-ms10-049-kb-980436-and-ietf-rfc5746.aspx
support.microsoft.com/kb/980436
netsekure.org/2010/08/windows-ssltls-update-for-secure-renegotiation/
www.atraining.ru/beast-move-from-ssl-to-tls/

SendExtraRecord — SSL/TLS 1.0 — защита от beast атак:
0 — вроде включено
1 — точно включено, но SQL и пр ломается
2 — патч совсем выключен, BEAST дырка точно включена.
support.microsoft.com/kb/2643584/ru
blogs.msdn.com/b/kaushal/archive/2012/01/21/fixing-the-beast.aspx
(тут рекомендуют использовать RC4 а патч выключать, но в RC4 нашли неприятные моменты и теперь его не рекомендуется использовать)

И на последок, есть такая утилита: www.nartac.com/Products/IISCrypto/Default.aspx

PS

For fun: support.microsoft.com/kb/2643584

• Many applications that use schannel are written so that the receiver side assumes application data will be packed into a single packet. This occurs even though the application calls schannel for decryption. The applications ignore a flag that is set by schannel. The flag indicates to the application that there is more data to be decrypted and picked up by the receiver. This method does not follow the MSDN-prescribed method of using schannel. Because the security update enforces record-splitting, this breaks such applications.
• Broken applications include Microsoft products and in-box components. The following are examples of scenarios that may be broken when the SendExtraRecord registry value is set to 1:
  • All SQL products, and applications that are built onto SQL.
  • Terminal Servers that have Network Level Authentication (NLA) turned on. By default, NLA is enabled in Windows Vista and later versions of Windows.
  • Some Routing Remote Access Service (RRAS) scenarios.

Автор: Ivan_83

Источник