Как отключить sslv3 windows server 2003

Протокол SSL и его преемник TLS — это криптографические протоколы, предназначенные для обеспечения безопасности сетевых соединений в интернет. Кроме распространенного HTTPS, предназначенного для веб-соединений, они используются и многими другими приложениями. SSLv1 никогда публично не выпускался, SSLv2 быстро оказался небезопасным. Был создан SSLv3, он все еще используется для защиты транспортного уровня интернет соединений вместе с TLSv1 / 1.1 / 1.2.

Не так давно инженеры Google обнаружили уязвимость протоколе SSLv3, благодаря которой данная версия SSL подвержена POODLE атаке, и его использование крайне не желательно. Существует патч, но он не решает данную проблему полностью, поскольку исправлены должны быть обе стороны соединения, клиент и сервер.

Протоколу SSLv3 почти 18 лет, тем не менее он все еще очень распространен в сети, не смотря на это, необходимо как можно скорее отказаться от использование данной версии протокола SSL, как на стороне сервера так и клиента. Хотя существует небольшая часть интернет-пользователей, которые используют очень устаревшие системы и вообще не поддерживают TLS, в связи с этим они ограничены в возможности подключения к вашему сайту или сервису.

• Отключение SSLv3 на распространенных веб серверах
• Отключение протокола SSLv3 в основных веб браузерах
• Отключение протокола SSLv3 на почтовых серверах
• Отключение протокола SSLv3 в некоторых других сетевых сервисах

Основные вопросы и ответы касаемо протокола SSLv3

Почему следует отключить SSLv3 на сервере?

Если вы владелец или администратор сервера, вам действительно нужно отключить SSLv3 как можно скорей, что-бы обезопасить ваших пользователей. После отключения протокола SSLv3, клиенты не смогут использовать эту уязвимую версию SSL протокола для подключения и будут вынуждены использовать более новую, более безопасную альтернативу.

Почему нужно отключить SSLv3 на клиенте?

Как пользователь, вы должны отключить SSLv3 в своем браузере, чтобы обезопасить себя при посещении сайтов, которые все еще поддерживают SSLv3. Сделав это, вы можете быть уверены что ваше веб-приложение не будет пытаться установить соединение с SSLv3 и будет использовать более безопасную альтернативу.

Является ли POODLE уязвимостью реализации, такой-же как уязвимость OpenSSL Heartbleed?

Нет, POODLE это уязвимость протокола. Это означает, что это касается внутренней работе SSLv3, и вы не можете ее исправить.

Нужно ли отозвать сертификаты после POODLE?

Нет, вам не нужно выпускать новые сертификаты. Атака POODLE — это не утечка памяти, это атака восстановления данных в открытом тексте, которая нацелена на HTTP заголовки и использует слабость протокола SSLv3 при работе с блочными шифрами.

Отключение SSLv3 в распространенных веб серверах

Отключить SSLv3 на веб сервере Apache

Добавить в файл конфигурации apache, или изменить если уже есть но не соответствует, следующую директиву:

SSLProtocol All -SSLv2 -SSLv3

после чего перезагпустить apache:

service apache2 restart
# или 
apachectl restart

Отключить SSLv3 на веб сервере IIS

Создайте файл реестра disable_ssl3.reg со следующим содержимым:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server]
«Enabled»=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server]
«Enabled»=dword:00000000

и запустите его.

Отключить SSLv3 на веб сервере nginx

Добавьте в файл конфигурации nginx.conf директиву:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

если такая уже есть и отличается, исправьте, после чего перезагрузите nginx

nginx -s reload

Отключить SSLv3 на веб сервере Lighttpd

Релизы Lighttpd сервера до версии 1.4.28 позволяют отключать только SSLv2. Если вы используете версию 1.4.29 и выше, пропишите в конфиг:

ssl.use-sslv2 = «disable»
ssl.use-sslv3 = «disable»

после чего перезапустите сервер

service lighttpd restart

Отключение протокола SSLv3 в основных веб браузерах

Chrome и Chromium

Если вы используете Chrome 40 и выше, вы в безопасности, поскольку с версии 40 Chrome/Chromium полностью отключил поддержку SSLv3.

В Chrome и Chromium используются параметры, позволяющие пользователю самостоятельно указывать предпочтительный протокол, однако многие ошибочно считают что SSLv3 является более свежей версией нежели TLS 1.0, и по ошибке отключают последний.

Таким образом, пока не был объявлен браузер Google Chrome или Chromium с отключенным по умолчанию SSLv3, необходимо запустить данные браузеры с параметром командной строки —ssl-version-min = tls1 . Для этого можно изменить ярлык приложения, что-бы браузер запускался с нужным параметром.

windows

1. Щелкните правой кнопкой мыши по ярлыку Google Chrome/Chromium на рабочем столе, вкладка Properties.
2. В строке объект, после последнего символа двоеточия, добавьте пробел а затем —ssl-version-min=tls1.
3. Нажмите ОК и подтвердите если будут запрошены права администратора.

Имейте в виду, что данная настройка защитит только сеансы браузера запущенные ярлыком на рабочем столе, на сеансы запущенные нажатием на ссылку в документе или письме данная настройка не влияет. Что-бы это исправить нужно отредактировать параметр реестра HKEY_CLASSES_ROOT/ChromeHTML/shell/open/command, приведя его к такому виду:
«C:Program FilesGoogleChromeApplicationchrome.exe» —ssl-version-min=tls1 — «%1»
убедитесь что путь до chrome.exe соответствует вашей системе.

Linux

Изменение символических ссылок рабочего стола и меню приложений зависят от графического окружения. Например в Ubuntu нужно отредактировать файл /usr/share/applications/google-chrome.desktop, дописав параметр —ssl-version-min=tls1 в строчки начинающиеся с «exec=», например до изменения:

Exec=/usr/bin/google-chrome-stable %U

привести к такому виду:

Exec=/usr/bin/google-chrome-stable —ssl-version-min=tls1 %U

теперь нужно сохранить файл и перезапустить браузер.
Только для Chromium на стабильных релизах Debian и Ubuntu, нужно в файл /etc/chromium-browser/default добавить строку:

CHROMIUM_FLAGS=»—ssl-version-min=tls1″

На нестабильных версиях Debian нужно создать файл /etc/chromium.d/disable-sslv3, содержащий строку:

CHROMIUM_FLAGS=»${CHROMIUM_FLAGS} -ssl-version-min=tls1″

MacOS X

Открыть редактор AppleScript и прописать строку:

do shell script «open ‘/Applications/Google Chrome.app’ —args —ssl-version-min=tls1»

затем сохранить как приложение и добавить в Dock.

Mozilla Firefox

Если версия Firefox ниже 34, в адресной строке браузера набрать about:config и установить значение параметра security.tls.version.min равным 1.

Safari

Apple выпустила обновление безопасности 2014-005, которое отключает шифры CBC по согласованию с SSLv3. Патч доступен для Mac OS Mavericks, Mountain Lion и Yosemite, и после обновления никаких действий с вашей стороны не потребуется.

Internet Explorer

Перейти в меню Пуск >> Свойства обозревателя.
Вкладка Дополнительно.
Снимите флажок Использовать SSL 3.0.
Подтвердите, нажав OK.

Если у вас установлена ​​более старая версия Windows, например Windows XP, убедитесь что установлен пакет обновления 3 (SP3), чтобы иметь доступ к сайтам с отключенным протоколом SSLv3.

Opera

Если вы используете Opera 12.17 или старше:

Нажмите ctrl + f12.
Перейдите на вкладку «Дополнительно».
Нажмите «Безопасность» в меню слева.
Нажмите «Протоколы безопасности».
Снимите флажок «Включить SSL 3».
Нажмите ОК.

Отключение протокола SSLv3 на почтовых серверах

Отключить SSLv3 в Sendmail

Пропишите следующие строки в файл конфигурации sendmail.mc, в секцию LOCAL_CONFIG:

LOCAL_CONFIG
O CipherList=HIGH
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

после чего перезагрузите sendmail

service sendmail restart

Отключить SSLv3 в Postfix

Пропишите в файл конфигурации postfix или исправьте следующие строки:

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3
smtp_tls_protocols=!SSLv2,!SSLv3

перезагрузите postfix

service postfix restart

Отключить SSLv3 в Dovecot

Пропишите в файл конфигурации /etc/dovecot/local.conf следующую строку, или исправьте если есть:

ssl_protocols = !SSLv2 !SSLv3

перезапустите dovecot

service dovecot restart

Отключить SSLv3 в Courier-imap

Пропишите в файл конфигурации /etc/courier/imapd-ssl, или исправьте если есть:

IMAPDSSLSTART=NO
IMAPDSTARTTLS=YES
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL=TLS1
TLS_STARTTLS_PROTOCOL=TLS1

перезапустите courier-imap

service courier-imap restart

Отключение протокола SSLv3 в некоторых других сетевых сервисах

Отключить SSLv3 для Java

В контрольной панели java перейти: Start -> Java -> Configure Java, вкладка Advanced, прокрутить вниз, снять флажок Use SSL 3.0.

Отключить SSLv3 для NodeJS

Если вы используете NodeJS в качестве веб сервера ( не лучшая идея ), установите secureOptions:

constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2

читать подробности

Отключить SSLv3 для OpenVPN

OpenVPN использует TLSv1.0 или, начиная с версии 2.3.3, опционально TLSv1.2, поэтому не подвержен POODLE атаке

источник

Отключить SSLv3 для Puppet

Puppet агенты не подвержены POODLE атаке.
Если-же вы все равно хотите отключить SSLv3, используйте stephenrjohnson/puppetmodule модуль для настройки мастер процесса который не использует SSLv3.

Отключить SSLv3 для HAProxy

Отредактируйте директиву bind в файле конфигурации /etc/haproxy.conf, добавив no-sslv3. Получаем что-то вроде:

bind :443 ssl crt ciphers no-sslv3

Более подробно в документации по haplroxy.

Онлайн сервисы для тестирования SSL протокола

В октябре инженеры Google опубликовали информацию о критической уязвимости в SSL версии 3.0, получившей забавное название POODLE (Padding Oracle On Downgraded Legacy Encryption или пудель 🙂 ). Уязвимость позволяет злоумышленнику получить доступ к информации, зашифрованной протоколом SSLv3 с помощью атаки «man in the middle». Уязвимости подвержены как серверы, так и клиенты, которые могут соединяться по протоколу SSLv3.

В общем-то ситуация не удивительная, т.к. протоколу SSL 3.0, впервые представленного еще в 1996 году, уже исполнилось 18 лет и морально он уже устарел. В большинстве практических задач его уже заменил криптографический протокол TLS (версий 1.0, 1.1 и 1.2).

Для защиты от уязвимости POODLE рекомендуется полностью отключить поддержку SSLv3 как на стороне клиента, так и на стороне сервера и в дальнейшем использовать только TLS. Для пользователей устаревшего ПО (например, использующих IIS 6 на Windows XP) это означает, что они более не смогут просматривать HTTPS страницы и использовать другие SSL-сервисы . В том случае, если поддержка SSLv3 не отключена полностью, а по умолчанию предлагается используется более сильное шифрование, уязвимость POODLE все равно будет иметь место. Связано это с особенностями выбора и согласования протокола шифрования между клиентом и сервером, т.к. при обнаружении неисправностей в использовании TLS, происходит автоматический переход на SSL.

Рекомендуем проверить все свои сервисы, которые могут использовать SSL/TLS в любом виде и отключить поддержку SSLv3. Проверить свой веб-сервер на наличие уязвимости можно с помощью онлайн теста, например, тут: http://poodlebleed.com/.

Примечание. Нужно четко понимать, что отключение SSL v3 на уровне всей системы будет работать только для ПО, которое использует системные API для SSL-шифрования (Internet Explorer, IIS, WebDav , SQL NLA, RRAS, Direct Access и др.). Программы, которые используют собственные крипто средства (Firefox, Opera и т.д.) нужно обновить и настроить индивидуально.

Отключаем SSLv3 в Windows на уровне системы

В ОС Windows управление поддержкой протоколов SSL/TLS осуществляется через реестр.

Совет. Перед выполнением указанных изменений рекомендуем создать резервную копию указанной ветки с помощью функции редактора реестра Экспорт.

В этом примере мы покажем, как полностью на уровне системы (как на уровне клиента, так и сервера) отключить SSLv3 в Windows Server 2012 R2:

1. Откройте редактор реестра (regedit.exe) с правами администратора
2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSchannelProtocols
3. Создайте новый раздел с именем SSL 3.0 ( New -> Key)
4. В созданном разделе SSL 3.0 создайте еще два подраздела с именами Client и Server.
5. Затем в разделе Client создайте новый параметр типа DWORD (32-bit) с именем DisabledByDefault
6. В качестве значения ключа DisabledByDefault укажем 1.
7. Затем в ветке Server создайте новый параметр типа DWORD (32-bit) с именем Enabled и значением 0.
8. Для вступления изменений в силу необходимо перезагрузить сервер

Отключаем SSLv2 (Windows 2008 / Server и ниже)

В ОС, предшествующих Windows 7 / Windows Server 2008 R2 по-умолчанию используется еще менее безопасный и устаревший протокол SSL v2, который также следует отключить из соображений безопасности (в более свежих версиях Windows, SSLv2 на уровне клиента отключен по умолчанию и используется только SSLv3 и TLS1.0). Для отключения SSLv2 нужно повторить описанную выше процедуру, только для раздела реестра SSL 2.0.

В Windows 2008 / 2012 SSLv2 на уровне клиента отключен по умолчанию.

Включаем TLS 1.1 и TLS 1.2 в Windows Server 2008 R2 и выше

Windows Server 2008 R2 / Windows 7 и выше поддерживают алгоритмы шифрования TLS 1.1 и TLS 1.2, но по-умолчанию эти протоколы отключены. Включить поддержку TLS 1.1 и TLS 1.2 в этих версиях Windows можно по схожему сценарию

1. В редакторе реестра откройте ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols
2. Создайте два раздела TLS 1.1 и TLS 1.2
3. Внутри каждого раздела создайте по подразделу с именами Client и Server
4. В каждом из разделов Client и Server создайте по ключу типа DWORD:
   • DisabledByDefault со значением 0
   • Enabled со значением 1
5. После внесенных изменений сервер следует перезагрузить.

Утилита для управления системными криптографическими протоколами в Windows Server

Существует бесплатная утилита IIS Crypto, позволяющая удобно управлять параметрами криптографических протоколов в Windows Server 2003, 2008 и 2012. С помощью данной утилиты включить или отключить любой из протоколов шифрования можно всего в два клика.

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

Hello, and please accept my humble thanks in advance.The problem that I’m having is the protocols listed below must be disabled on my Windows 2003 (IIS) Servers before we can pass a PCI audit. Now I’ve taken care of all of this on Windows 2008R2, but not
without days and nights of searching the internet for information that is not only clear to understand but accurate, however, I’m not having much luck with 2003.

Vulnerabilities:

SSL Server Supports CBC Ciphers for SSLv3
SSL Server Supports CBC Ciphers for TLSv1
SSL Server Supports RC4 Ciphers for SSLv3
SSL Server Supports RC4 Ciphers for TLSv1
SSL Server Supports Weak MAC Algorithms for SSLv3
SSL Server Supports Weak MAC Algorithms for TLSv1

Here’s what I’ve tried, I’ve done the registry edit as follows, it did not work;

Here’s what I’ve tried, I’ve installed the Microsoft Security Bulletin MS12-006 — Important Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584), it did not work for those issues but it did close the SSLv2.0 problem.

Is there ANY reason why the registry edit would not work?

Again, thank you.

Don

Also,

Has anyone seen or used this Hotfix… what is it and how would it relate to this issue.

Hello, and please accept my humble thanks in advance.The problem that I’m having is the protocols listed below must be disabled on my Windows 2003 (IIS) Servers before we can pass a PCI audit. Now I’ve taken care of all of this on Windows 2008R2, but not
without days and nights of searching the internet for information that is not only clear to understand but accurate, however, I’m not having much luck with 2003.

Vulnerabilities:

SSL Server Supports CBC Ciphers for SSLv3
SSL Server Supports CBC Ciphers for TLSv1
SSL Server Supports RC4 Ciphers for SSLv3
SSL Server Supports RC4 Ciphers for TLSv1
SSL Server Supports Weak MAC Algorithms for SSLv3
SSL Server Supports Weak MAC Algorithms for TLSv1

Here’s what I’ve tried, I’ve done the registry edit as follows, it did not work;

Here’s what I’ve tried, I’ve installed the Microsoft Security Bulletin MS12-006 — Important Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584), it did not work for those issues but it did close the SSLv2.0 problem.

Is there ANY reason why the registry edit would not work?

Again, thank you.

Don

Also,

Has anyone seen or used this Hotfix… what is it and how would it relate to this issue.

Hello, and please accept my humble thanks in advance.The problem that I’m having is the protocols listed below must be disabled on my Windows 2003 (IIS) Servers before we can pass a PCI audit. Now I’ve taken care of all of this on Windows 2008R2, but not
without days and nights of searching the internet for information that is not only clear to understand but accurate, however, I’m not having much luck with 2003.

Vulnerabilities:

SSL Server Supports CBC Ciphers for SSLv3
SSL Server Supports CBC Ciphers for TLSv1
SSL Server Supports RC4 Ciphers for SSLv3
SSL Server Supports RC4 Ciphers for TLSv1
SSL Server Supports Weak MAC Algorithms for SSLv3
SSL Server Supports Weak MAC Algorithms for TLSv1

Here’s what I’ve tried, I’ve done the registry edit as follows, it did not work;

Here’s what I’ve tried, I’ve installed the Microsoft Security Bulletin MS12-006 — Important Vulnerability in SSL/TLS Could Allow Information Disclosure (2643584), it did not work for those issues but it did close the SSLv2.0 problem.

Is there ANY reason why the registry edit would not work?

Again, thank you.

Don

Also,

Has anyone seen or used this Hotfix… what is it and how would it relate to this issue.

Протокол SSL был разработан фирмой Netscape, достаточно давно. Я осознанно пропущу исторические подробности, так как они сейчас уже не особо интересны. В его задачи входило следующее:

• Обязательность подтверждения подлинности сервером
• Опциональная проверка подлинности клиента
• Совместная генерация случайного сеансового ключа
• Поддержка различных симметричных алгоритмов для шифрования данных
• Поддержка различных алгоритмов хэширования для реализации проверки целостности через MAC

Первая версия SSL не особо показывалась публике, отсчёт рабочих версий можно начинать с SSL 2.0 (1995й год). Эта версия была первой, которая эксплуатировалась в production, и достаточно оперативно она была доработана до SSL 3.0. Заметим, что хотя это произошло достаточно давно – в 1996 году – стандарт от этого не стал общим и открытым; он оставался стандартом, разработанным конкретной фирмой Netscape, и для его использования в ряде случаев нужна была лицензия. Опубликован IETF он был совсем недавно, в августе; RFC 6101 описывает то, что 15 лет уже стандарт де-факто для защиты сессий множества приложений. Но по сути, с ним уже давно пора прощаться; TLS существует годы (с 1999, если быть точнее), а достаточно безопасная на данный момент версия 1.1 – с 2006 года. Пора, пора.

На данный момент есть три версии протокола TLS: 1.0, 1.1 и 1.2. Они, соответственно, имеют внутренние идентификаторы версии 3.1, 3.2 и 3.3, поэтому иногда называются SSL 3.1, SSL 3.2 и SSL 3.3. Все эти версии поддерживаются как клиентским, так и серверным ПО Microsoft (начиная с IIS 7.5 и IE9), надо только включить. Про клиентское ПО (типа того же Internet Explorer) я уточню ниже, в отдельном пункте – на то оно и клиентское, чтобы включение поддержки данного функционала было бы там несложной операцией. Основное в статье – про серверные вопросы. Давайте чуть разберёмся в функционале версий протокола TLS, а после – включим их поддержку, отключим SSL и закрутим гайки.

ПРО TLS 1.0

Версия 1.0, по сути, является базовой, и представляет собой доработанный и открытый для всех, а не только для Netscape, вариант SSL 3.0. Хотя, надо отметить, напрямую TLS 1.0 и SSL 3.0 не совместимы; TLS 1.0 “умеет” работать в режиме совместимости с SSL, но именно в режиме, а не “идентично”, как иногда можно прочитать.

Например, у SSL 3.0 есть встроенная в протокол неприятность – половина master key будет создаваться из MD5-хэша достаточно предсказуемых данных, что может привести (учитывая текущее положение MD5) к успешной атаке на коллизию (в результате станет известна половина бит ключа, которым будет шифроваться сессия, а это практически равнозначно компрометации процесса). У TLS 1.0 это поправили, и схема усложнена – берутся и MD5 и SHA-1 хэши, после чего xor’ятся, что сводит возможность вышеуказанной атаки к нулю.

ПРО TLS 1.1

В версии TLS 1.1 делаются небольшие изменения – в частности, меняется логика задания IV (вектора инициализации), для защиты от атак, имеющих своей целью слабость реализации метода CBC в TLS 1.0, улучшается обработка ошибок и переподключения, а также вносятся другие мелкие изменения, не являющиеся фундаментальными с точки зрения использования протокола. Но по сути, это самая минимальная версия TLS, для которой отсутствуют известные атаки, поэтому её использование – это правильный выбор.

ПРО TLS 1.2

В TLS 1.2 же список добавлений относительно велик – в нём будут многочисленные улучшения поддержки новых криптографических протоколов, отказ от потенциально уязвимых моментов (например, для процесса генерации псевдослучайного числа – замена MD5/SHA-1 на SHA-256 либо на явно указанную хэш-функцию), ужесточение многих проверок, обязательность реализации AES и отключение одиночного DES и IDEA, отмена обязательности совместимости реализации с SSLv2 и подобное.

Для нас ключевым является разумное повышение уровня безопасности, поэтому мы будем нацеливаться на TLS 1.1. Не потому что TLS 1.2 плохой, а потому что если “закрутить гайки” только на TLS 1.2, не все клиенты смогут корректно подключаться. Если бы все браузеры с криптографической точки зрения были бы уровня IE9, то можно было бы и TLS 1.2 включить, а остальное объявить старым, но реальность состоит в том, что нам надо хотя бы отсечь гарантированно старые и уязвимые протоколы.

ПРО TLS 1.2 И WINDOWS XP SP3

Например вот один момент, который надо учитывать при поддержке TLS 1.2. Дело в том, что стандартным методом проверки целостности (MAC – Message Authentication Code), используемым в TLS 1.2, является SHA-2. SHA-2 – это семейство алгоритмов, состоящее из SHA-224, SHA-256, SHA-320, SHA-512, и подобных. Соответственно, “натуральная” поддержка этих алгоритмов приходит только в ядре NT 6.0, с новой версией CryptoAPI. В распространённой же Windows XP данная поддержка (т.е. просто понимаение, что есть SHA-2) появляется только в Service Pack 3, притом поддерживается только 3 варианта SHA-2 – SHA-256, SHA-320, SHA-512. То есть, говоря проще, XP SP2 нормально с TLS 1.2 работать не может никак. Вообще. Потому что будетNTE_BAD_ALGID.

ПРО TLS 1.2 И WINDOWS SERVER 2003 SP2

К сожалению, ситуация с поддержкой TLS 1.2 на Windows Server 2003 SP2 хуже, чем на XP. В последний Service Pack для 2003го сервера поддержка SHA-2 не вошла. Поэтому попытка проверить целостность в TLS 1.2 при помощи одного из алгоритмов семейства SHA-2, да и, к примеру, посчитать хэш у x.509 сертификата или *.crl приведёт к ошибке.
Поддержка SHA-2 аналогичная XP SP3 реализована через патч 938397. Но это ещё не всё. Ведь приключения, связанные с тем, что у NT 5.1 / NT 5.2 есть CAPI2, а у NT 6.0 – CNG, только начинаются. В случае, если в Вашей сети есть Windows XP и/или Windows Server 2003, и есть служба Certification Authority на Windows 2008 и старше, то даже в случае установленного патча 938397 они не смогут корректно запрашивать сертификаты у этого CA. Чтобы они могли это делать, есть патч 968730. Он и добавляет частичную поддержку SHA-2, и учит CAPI2 дружить на уровне запросов сертификата с CNG. Полностью перекрывая собой предыдущий патч. Обязательно установите 968730 на Windows XP SP3 / Windows Server 2003 SP2, если ещё не сделали это.

BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0

Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто.
Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.

Если попробовать рамочно описать алгоритм атаки, можно это сделать так.

• Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
• Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
• Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
• Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
• Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный

Очевидно, что при реализации этой штуки через ботсеть можно наловить очень много полезного.

Обращу внимание, что атака не зависит от используемого симметричного алгоритма, а лишь использует то, что в SSL/TLS используется схема CBC, а не ECB. AES-128, как понятно, я выбрал, чтобы блок был 16 байт. Как понимаете, в случае AES-256 время вырастет не на 2^128, как в случае линейного криптоанализа, а всего лишь в два раза – надо будет вскрыть не 16, а 32 байта. Ну, а в случае DES с блоком в 64 бита, всё только грустнее.

Поэтому надо защищаться.

Включаем TLS на Windows-системе

Сразу обращаю внимание – этот метод включает TLS на уровне операционной системы. Продукты в большинстве своём просто пытаются согласовать варианты протоколов SSL/TLS, начиная “с верхнего доступного”, явных настроек у них обычно нет.

Для отключения TLS 1.0 и включения поддержки TLS 1.1 и TLS 1.2 необходимо проделать следующие действия – зайти в реестр, открыть ключ

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server

создать в нём значение DisabledByDefault и выставить его в единицу, а в ключах

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server

выставить то же самое значение в нуль. Это нужно сделать обязательно, т.к. отсутствие этого ключа равняется “отсутствию отмены запрета на поддержку TLS 1.x”.

В случае необходимости в явном виде управлять данными протоколами на уровне клиента – всё то же самое, но вместо раздела Server надо указать Client.

Теперь пора отключить небезопасные протоколы.

Отключаем SSL на Windows-системе

Согласно RFC 6176 от марта 2011 года, все, кто думают о безопасности, и хотят называться TLS-серверами и клиентами, должны вести себя так:

• TLS-клиенты обязаны никогда не отправлять в сообщениях CLIENT-HELLO версии ниже 3.0
• TLS-сервера обязаны сразу прерывать попытку подключения, если противоположная сторона сообщает о том, что максимально поддерживаемая ей версия протокола – 2.0

Вот так, достаточно четко и строго.
Давайте сделаем всё так же.
Для этого надо будет отключить PCT 1.0 (т.к. он тоже не TLS, если что) и SSL 2.0. SSL 3.0 отключается абсолютно аналогично.

КАК ОТКЛЮЧИТЬ SSL 2.0/3.0 НА WINDOWS-СИСТЕМЕ

Нам надо зайти в ключ реестра

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Client

и поставить там значение DisabledByDefault (вида DWORD32) в единицу. Аналогично – для ключа

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server

Если сразу хотите отключить и SSL 3.0, то поступите по аналогии, создав (если его нет, что часто бывает) ключ с именем SSL 3.0 на том же уровне иерархии, где находится раздел с SSL 2.0, и создав соответствующие подключи Client и Server.

КАК ОТКЛЮЧИТЬ PCT 1.0 НА WINDOWS-СИСТЕМЕ

Тут чуть иначе.

Если у Вас Windows Server 2003 – этот протокол уже выключен. Если 2008 – то даже не включится. Но на всякий случай – знайте, как это делается. Надо зайти в ключ

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsPCT 1.0Server

и добавить в него значение Enabled (вида DWORD32), выставив его в нуль.

Вроде как всё. PCT 1.0 убили, все SSL тоже, TLS 1.0 тоже. Делайте это всё аккуратно, очень тщательно проверяя, что ПО после этого функционирует. Учтите, что при закручивании гаек в плане “Давайте выключим весь SSL на клиентах” – т.е. не при добавлении старших версий TLS, а при явном запрете младших – с гарантией часть внешних сервисов будет недоступна. Например, большинство социальных сетей, которые декларируют “Доступ к нам теперь по HTTPS, а, значит, безопасен!”, на самом деле крайне экономят силы, включая согласование минимальных версий и самых простых криптоалгоритмов. Их можно понять; 99.9% клиентов глубоко пофиг, DES там или 3DES, а вот что вычислительно задача станет в 3 раза сложнее – очевидно. По моему личному опыту, при “замораживании” на клиенте TLS 1.1 и выше, например, не работает https://twitter.com/ . Т.е. будьте осторожны и тестируйте. Вполне возможно, что вполне даже рабочие ресурсы – типа электронной торговой площадки – будут использовать старые алгоритмы.

Ну, а теперь давайте закручивать гайки.

Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе

К стандартам семейства TLS есть интересные дополнительные механизмы, не вошедшие в основные спецификации. Данные механизмы известны гораздо меньше, чем что-то вида “ну ё, TLS же новый, SSL старый, значит включаешь TLS и безопаснее становится”, но не в моих правилах подходить к вопросу с такой стороны.

Безопасное пересогласование TLS описывается в стандарте RFC 5746 и решает проблему безопасности, которая возникает в случае работы классического TLS 1.2, который по RFC 5246.

По сути, Windows-хост может работать в плане этого RFC в двух режимах – в режиме совместимости (т.е. допускать и небезопасное, “классическое” пересогласование TLS 1.2), и в “безопасном”, допуская только пересогласование в новом формате. По умолчанию, работа идёт в режиме совместимости. Это не всегда полезно, поэтому надо знать, как включать только безопасное пересогласование TLS 1.2.

ВКЛЮЧАЕМ ПОДДЕРЖКУ TLS RENEGOTIATION INDICATION EXTENSION

Мы будем работать с ключом реестра

HKEY_LOCAL_MACHINESystemCurrentControlSetControlSecurityProvidersSCHANNEL

В нём будет необходимо создать следующие ключи: AllowInsecureRenegoClients,AllowInsecureRenegoServers, UseScsvForTls, DisableRenegoOnClient, DisableRenegoOnServer. Все – обычные DWORD 32. Теперь подробнее про каждый.

Параметр AllowInsecureRenegoClients будет обозначать, можно ли клиентам, подключающимся к данному хосту, использовать небезопасный вариант пересогласования. Обратите внимание – это серверная настройка; т.е. она анализируется, когда какой-либо сервис на этом хосте “слушает” входящие подключения по TLS. Например, IIS. Если хотите, чтобы можно было подключаться всем – поставьте единицу, если только “умным” клиентам, поддерживающим RFC 5746 – то нуль.

Параметр AllowInsecureRenegoServers будет обозначать, можно ли будет с этого хоста подключаться к серверам, которые не поддерживают механизм безопасного пересогласования. Если параметр равен нулю – клиенты будут прерывать фазу согласования TLS, если сервер ведёт себя некорректно. Если хотите, чтобы можно было подключаться к любым TLS-серверам, вне зависимости от реализации на них поддержки RFC 5746 – поставьте единицу.

Параметр UseScsvForTls заслуживает отдельного обсуждения. Дело в том, что в RFC 5746 указывается, что данное расширение необходимо упаковывать в сообщение “ClientHello” протокола TLS. Но это может быть причиной проблем, потому что некоторые сервера – заметьте, именно сервера, т.е. это клиентская настройка – которые не поддерживают данный стандарт, не просто не смогут переключиться на новый механизм, а просто не смогут обработать этот неизвестный им подвид сообщения ClientHello. Это, например, Vista без SP. Чтобы подстраховаться от ситуации, когда “новый” клиент посылает “новый вариант” ClientHello и серверная сторона рвёт связь, надо установить этот параметр в единицу. В этом случае клиент просто отправит т.н. “Signaling Cipher Suite Value” (как раз SCSV). Ставьте этот параметр только в случае, когда Вам реально нужно подключаться к системе, которая “сбрасывает” сессию после ClientHello.

Можно и масштабнее. Если параметры выше описывали варианты поведения при пересогласовании TLS, то следующие будут включать-выключать поддержку пересогласования как такового.

Если параметр DisableRenegoOnClient есть и не равен нулю, то клиент со своей стороны не будет пробовать проводить пересогласование TLS (например, периодически) и не будет отвечать на запросы пересогласования (будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), то всё ОК – клиент будет поддерживать пересогласование и пробовать делать его сам.

Если параметр DisableRenegoOnServer есть и не равен нулю, то сервер со своей стороны не будет пробовать проводить пересогласование TLS и не будет отвечать на запросы пересогласования (тоже будет не рвать сессию, а именно игнорировать). Если же параметр равен нулю (или отсутствует), сервер будет поддерживать пересогласование и пробовать делать его сам.

Атака на SSL/TLS – THC-SSL-DOS

Достаточно предсказуемая атака, в основе которой лежит идея, что крайне малыми силами со стороны клиента (по сути, просто запросив) можно заставить сервер выполнить математически относительно сложную задачу по перегенерации ключевой информации. В своей практике я сталкивался с таким в 2004 году, в случае с ipsec; один талантливый админ поставил настройки смены ключей так, что они менялись через каждые 100 килобайт (он хотел мегабайты, просто ошибся). В результате сеть работала, но медленно – ipsec в основном занимался IKE/ISAKMP задачами, а не трафиком.

Атака серьёзна – при полутысяче запросов в секунду (выполнимо с домашней машины при наличии обычного широкополосного доступа на 4-8 мегабита) полностью “ложится” процессор уровня Intel Xeon E5645. 100%го способа защиты от атаки сейчас нет. Поэтому надо максимально уменьшить её вероятность.

Для борьбы можно использовать следующие методы:

1. Разгрузку SSL-задач при помощи аппаратных ускорителей
2. Отключение пересогласования TLS
3. Ограничение количества TLS-сессий – как вообще в сумме, так и с одного source ip
4. Упрощение схемы генерации ключей

ЗАЩИТА ОТ THC-SSL-DOS ПУТЁМ ПОКУПКИ SSL-УСКОРИТЕЛЯ

Метод не оптимален, но всё же в ряде случаев изменит ситуацию. Суть в том, чтобы SSL/TLS сессии терминировались не на целевом сервере, а на выделенном устройстве, которое ощутимо быстрее выполняет SSL/TLS – задачи. Проблема в том, что все такие ускорители обычно ускоряют саму работу SSL/TLS – то есть симметричное шифрование трафика и проверку его целостности, а операции вида “генерация и смена ключей”, в силу их относительно малого процента в доле нагрузки при нормальной сессии делаются на таких appliance программно. Специализированного appliance, которое умеет очень быстро именно генерить новые сеансовы ключи для TLS, а не шифровать трафик, видимо, не существует в природе. Увы.

ЗАЩИТА ОТ THC-SSL-DOS ПУТЁМ ОТКЛЮЧЕНИЯ ПЕРЕСОГЛАСОВАНИЯ TLS

Это то, что Вы реально можете сделать. Учтите, это может повлиять на совместимость с клиентским ПО, которое в обязательном порядке хочет время от времени менять ключи сессии. Я проверял и не нашёл такого ПО среди обычно используемого в сетях на базе продуктов Microsoft (тестировались Exchange 2010 SP1, Sharepoint 2010 SP1, трафик DC/GC поверх SSL, TMG 2010 SP1). Мной не было найдено аномалий поведения, разрывов TLS-сессий по причине rekeying и прочего. Поэтому Вы можете промотать эту статью чуть выше (до предыдущего пункта) и выставить в единицу параметр DisableRenegoOnServer.

ЗАЩИТА ОТ THC-SSL-DOS ПУТЁМ ОГРАНИЧЕНИЯ КОЛИЧЕСТВА TLS-СЕССИЙ – КАК ВООБЩЕ В СУММЕ, ТАК И С ОДНОГО SOURCE IP

Если Вы отключили пересогласование TLS, то Вы отсекли одну из возможностей данной атаки; впрочем, опубликованный вчера эксплойт как раз её и использовал. Но существует альтернативный вариант – когда Ваш сервер перегружают не частым пересогласованием сессии, а многими фейковыми сессиями. Здесь Вы можете бороться только на сетевом уровне – ограничивая количество сессий с одного адреса, добавляя тайм-аут между установкой новых TLS-сессий, и лимитируя общее количество TLS-сессий у сервера вообще. Лучше применить все 3 этих подхода – например, сделать тайм-аут между TLS-сессиями хотя бы 10 ms (то есть не более 100 новых сессий в секунду до сервера), и разумно ограничить допустимое количество сессий с 1го адреса.

УПРОЩЕНИЕ СХЕМЫ ГЕНЕРАЦИИ КЛЮЧЕЙ

Это – ожидаемое решение со стороны реализации TLS. Навряд ли Вы сделаете это сами. 

Закручиваем гайки: настройки криптоалгоритмов на хосте

Цель – отключить слабые алгоритмы шифрования. Чтобы они просто не участвовали в процессе согласования. Потому что на данный момент, допустим, наличие в списке поддерживаемых алгоритмов RC2 40bit – это очень плохо, и это необходимо убирать незамедлительно.

Алгоритмы, используемые в SSL/TLS, можно модифицировать двумя основными способами – через групповые политики или через реестр. Первый способ, так как является штатным, предпочтительнее. Выполняется он следующим способом.

КАК ЧЕРЕЗ ГРУППОВУЮ ПОЛИТИКУ ИЗМЕНИТЬ СПИСОК ПОДДЕРЖИВАЕМЫХ SSL/TLS КРИПТОАЛГОРИТМОВ

Откройте объект групповой политики, через который Вы решите это сделать. Если настраиваете локальный хост –gpedit.msc. Выберите там раздел для компьютера, потом административные шаблоны, потом сеть, потом SSL Configuration Settings. Откройте данный параметр и сделайте следующее.

1. Скопируйте в Блокнот все cipher suites, которые там есть.
2. Удалите те, которые включают в себя согласование нестойких алгоритмов и методов (например, RC2, RC4, DES, MD5 и прочее. всякие ужасы вида TLS_RSA_WITH_NULL_MD5 Вам же не нужны, правда?).
3. Превратите список в одну большую строку, которая состоит из cipher suites, разделённых запятыми, и не содержит больше ничего. Пробелов тоже.
4. Вставьте эту строку в окно данной настройки групповой политики.

Учтите, что не всё, что поддерживается системой, присутствует в этом списке. И наоборот – данный список не прикажет системе начать поддерживать неизвестные ей криптоалгоритмы. Например, если у Вас есть системы на Windows XP / Windows Server 2003, убедитесь, что на них установлено обновление KB 948963, которое добавляет поддержку AES-128 и AES-256, необходимых для TLS.

А вот как можно изменить этот список через реестр.

КАК ЧЕРЕЗ РЕЕСТР ИЗМЕНИТЬ СПИСОК ПОДДЕРЖИВАЕМЫХ SSL/TLS КРИПТОАЛГОРИТМОВ

Откройте редактор реестра. Ваша задача – ключи вида:
HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersидентификатор_алгоритма размерность_ключа1/размерность_ключа2

где идентификатор алгоритма – это, например, RC4, а размерность ключа – например, 128. Понятное дело, что данных комбинаций фиксированное число, поэтому для отключения всех из них в явном виде надо забежать в MSDN и найти эти комбинации. Например, для старых симметричных алгоритмов семейства RCx это будут:

• RC4 128/128
• RC2 128/128
• RC4 64/128
• RC4 56/128
• RC2 56/128
• RC4 40/128
• RC2 40/128

Во всех этих ключах надо будет создать параметр Enabled (как обычно, DWORD32) и выставить его в нуль.

Интересным моментом является отключение возможности установить “пустой” SSL – без криптоалгоритма. Ну, типа как в PPP можно вообще без фазы авторизации, так и тут – есть такая тонкость. Чтобы эту тонкость тоже убрать, надо зайти в ключ:

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphersNULL

и опять же создать там Enabled со значением 0×0.

ОТКЛЮЧАЕМ ИСПОЛЬЗОВАНИЕ ХЭШ-ФУНКЦИИ MD5 В SSL/TLS

И даже это можно. Через групповую политику нет (только вручную удалив из полного списка все suites с упоминанием MD5), а через реестр – пожалуйста.

Учтите только, что данная настройка – лидер по количеству приключений после её применения. Классика – умирающий SharePoint 2010; он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.

Заходим:

HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELHashesMD5

и отключаем аналогично – Enabled в 0×0. Заодно и MD4 можно, он в принципе может встретиться в IPSec, но если не используется в реальности – имеет смысл его отключить аналогичным способом.

Проверяем работу TLS 1.1 и 1.2

Если Вы выяснили, что после отключения поддержки TLS 1.0 вы никуда не можете зайти, и подозреваете, что браузер сломался, есть отличный тестовый сайт:

Это специальный сайт, который зарегистрирован на одну из вымышленных и использующихся в курсах Microsoftорганизаций – Woodgrove Bank, а по сути – голый IIS с самоподписанным сертификатом, который поддерживает все виды SSL/TLS и нужен для диагностики. Зайдите на него, установите сертификат (их, кстати, несколько – специально для проверки поддержки различных криптоалгоритмов подписи) и проверите, что и как работает.

Есть второй вариант – https://www.mikestoolbox.net/. Тут возможностей поменьше, но зато быстрее и нагляднее видно – какой протокол поддерживается, что согласовалось.

Управляем настройками согласования SSL/TLS в браузерах

INTERNET EXPLORER

Если Вы дочитали до этого места и всё поняли, но не знаете, как включить TLS в IE, то это, по сути, уникальная ситуация. Но тем не менее. Для включения поддержки TLS старших версий необходимо зайти в меню Internet Options -> Advanced, там в списке промотать до раздела Security и сделать соответствующие изменения (как минимум отключить SSL 2.0 и включить TLS 1.1 и TLS 1.2, остальное – на усмотрение).

GOOGLE CHROME

У меня под рукой кроме IE только хром, но, как известно из фольклора, оно не браузер. Что хорошо подтверждается тем, что никакого TLS 1.1 и TLS 1.2 в доступной сейчас рабочей версии (14.0.835.137) нет. Т.е. можно сказать проще – на сегодняшний день, 2.10.2011, все поддерживаемые хромом виды безопасных соединений на основе SSL/TLS уязвимы для сентябрьской атаки и данный инструмент не имеет смысла использовать для, допустим, финансовых транзакций, онлайн-платежей и прочих security sensitive штук.

OPERA

Поставил оперу 11.51. Пожалуй, тут лучше всех сделано – можно не только выставить нужные протоколы (доступен выбор из SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2), но и нужные комплекты алгоритмов. Делается это зайдя в меню, там – Settings -> Preferences -> Advanced -> Security -> Security Protocols -> Details.
Правда, сделано плохо, потому что при включенном варианте “TLS 1.0 + 1.1 + 1.2″ согласовывать начинает с TLS 1.0. Специально перепроверил, плюс посмотрел через netmon – удивительно, реально начинает с 1.0, согласовывает и успокаивается. Т.е. если включить все эти 3 протокола в Internet Explorer, то на тестовых сайтах клиент будет определяться как “TLS 1.2 compatible”, а в случае оперы – “TLS 1.0″. Плохо, по сути перечеркивает всё преимущество тонкой настройки – т.е. ну поддерживает она 1.2, что с того-то, если согласовывать пробует 1.0 для начала. То есть или надо вручную выключать TLS 1.0 (тогда большинство публичных https-сайтов типа gmail или facebook отвалятся), или сидеть с уязвимой версией.

После таких “мелочей” люди удивляются, почему IE является корпоративным стандартом.

Что делать, если у меня нет возможности включить TLS новых версий

Если у Вас нет возможности “правильно” обеспечить себе безопасность от атаки BEAST’а, можно использовать тонкий трюк.

Надо зайти в вышеуказанный параметр групповой политики, посвящённый последовательности согласования криптографических комплектов, и выставить единственным TLS_RSA_WITH_RC4_128_MD5. Тонкость в том, что атака BEAST не работает в случае применения данного криптоалгоритма (RC4). Безусловно, в таком случае нельзя отключать RC4 и MD5, а также включать FIPS140-2. Да, конечно, RC4 хуже, чем AES, но если нет возможность включить AES, то чем не вариант? В случае клиентских браузеров это позволяет обезопасить от атаки IE7 и выше.

Краткие рекомендации

• Включите через групповую политику протоколы TLS 1.1 и 1.2 для всех клиентов и серверов в домене.
• Обязательно отключите SSL 2.0 на всех клиентах и серверах.
• Обязательно отключите SSL 3.0 на всех серверах, используемых для внутренних сервисов (DC, порталы, CA, всё подобное).
• Осторожно отключите SSL 3.0 и TLS 1.0 на всех клиентах, проверив, все ли требуемые для работы внешние сервисы будут доступны в этом случае.
• Включите на всех клиентах и серверах пересогласование TLS.
• Включите его (пересогласования) строгое соответствие RFC 5746 – не имеет смысла устанавливать “высокотехнологичный” TLS последней модели, и при этом не брать во внимание well-known security hole.

Более жесткое закручивание гаек – по вкусу.

Заключение

Я надеюсь, что эти несложные действия ощутимо помогут Вам в том, чтобы Вы могли читать про штуки, аналогичные BEAST, только в новостях

Обзор

В этой статье описываются способы добавления поддержки для более надежные комплекты шифров улучшенный стандарт шифрования (AES) в Пакет обновления 2 (SP2 для) Windows Server 2003 и как отключить слабые шифры.

Дополнительные сведения

Шаг 1: Для добавления поддержки более надежные комплекты шифров AES в Windows Server 2003 SP2, установите обновление, описанное в следующей статье базы знаний Майкрософт:

948963 обновление доступно для добавления поддержки комплекты шифров TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA и TLS_RSA_WITH_AES_256_CBC_SHA AES256 SHA AES в Windows Server 2003
Шаг 2: Чтобы отключить слабые шифры (включая экспорт шифры) в Windows Server 2003 с пакетом обновления 2, выполните следующие действия.

Важно. Этот раздел, метод или задача содержат действия, содержащие указания по изменению реестра. Однако, при некорректных изменениях реестра могут возникнуть серьезные проблемы. Поэтому выполняйте следующие действия внимательно. Для дополнительной защиты сделайте резервную копию реестра перед внесением изменений. В таком случае при возникновении неполадок можно будет восстановить реестр. Чтобы узнать дополнительные сведения о резервном копировании и восстановлении реестра, щелкните следующий номер статьи базы знаний Майкрософт:

322756 Как сделать резервное копирование и восстановление реестра Windows

Для изменения этих параметров реестра, выполните следующие действия.

1. Нажмите кнопку Пуск, выберите пункт Выполнить, в поле Открыть введите команду regedit и нажмите кнопку ОК

2. Найдите и выделите следующий подраздел реестра:

   HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELCiphers
   

3. В меню Правка выберите пункт Создать и выберите Раздел. Введите имя ключа в соответствии со следующими именами шифрования:

   DES 56 56
   ЗНАЧЕНИЕ NULL
   RC2 40/128
   RC2 56/128
   RC2 56/56
   RC4 40/128
   RC4 56/128
   RC4 64/128

4. В меню Правка выберите пункт Создатьи затем щелкните Значение DWORD.

5. Введите в качестве имени параметра DWORD включено и нажмите клавишу ВВОД.

6. Щелкните правой кнопкой мыши включени нажмите кнопку Изменить.

7. В поле значение введите 00000000и нажмите кнопку ОК.

8. В меню файл выберите команду Выход , чтобы закрыть редактор реестра.

Примечание. Повторите эти действия для отключения каждого слабого шифрования.

В порядке предпочтения комплекты шифров, доступные после успешного выполнения этих действий таковы:

• TLS_RSA_WITH_AES_128_CBC_SHA

• TLS_RSA_WITH_AES_256_CBC_SHA

• TLS_RSA_WITH_RC4_128_MD5

• TLS_RSA_WITH_RC4_128_SHA

• TLS_RSA_WITH_3DES_EDE_CBC_SHA

• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Как отключить SSLv3

Протокол SSL и его преемник TLS — это криптографические протоколы, предназначенные для обеспечения безопасности сетевых соединений в интернет. Кроме распространенного HTTPS, предназначенного для веб-соединений, они используются и многими другими приложениями. SSLv1 никогда публично не выпускался, SSLv2 быстро оказался небезопасным. Был создан SSLv3, он все еще используется для защиты транспортного уровня интернет соединений вместе с TLSv1 / 1.1 / 1.2.

Не так давно инженеры Google обнаружили уязвимость протоколе SSLv3, благодаря которой данная версия SSL подвержена POODLE атаке , и его использование крайне не желательно. Существует патч, но он не решает данную проблему полностью, поскольку исправлены должны быть обе стороны соединения, клиент и сервер.

Протоколу SSLv3 почти 18 лет, тем не менее он все еще очень распространен в сети, не смотря на это, необходимо как можно скорее отказаться от использование данной версии протокола SSL, как на стороне сервера так и клиента. Хотя существует небольшая часть интернет-пользователей, которые используют очень устаревшие системы и вообще не поддерживают TLS, в связи с этим они ограничены в возможности подключения к вашему сайту или сервису.

• Отключение SSLv3 на распространенных веб серверах
• Отключение протокола SSLv3 в основных веб браузерах
• Отключение протокола SSLv3 на почтовых серверах
• Отключение протокола SSLv3 в некоторых других сетевых сервисах

Отключение PCT 1.0, SSL 2.0, SSL 3.0 и TLS 1.0 в службах IIS в Windows

Набор серверов и сетевых служб IIS (Internet Information Services) от Microsoft, как известно, использует для защиты соединения между сервером и клиентом различные криптографические протоколы, такие как SSL, TLS и PCT. Самым актуальным из них является TLS. В этой статье разберём, как отключить ненужные нам протоколы в IIS.

Как должно быть понятно из названия, смысл криптографических протоколов в повышении защиты передаваемой информации от перехвата. В криптографических протоколах время от времени находят уязвимости, это приводит к разработке новых стандартов этих самых протоколов. К сожалению, моментально перейти на новый протокол нельзя из-за соображений обратной совместимости. Тем не менее, разработчики ПО постепенно внедряют в свои творения поддержку новых протоколов. Таким образом, иногда целесообразно отключать старые протоколы, если они уже не используются.

В операционных системах семейства Windows управление поддержкой протоколов PCT/SSL/TLS осуществляется на уровне реестра. Нас интересует ветка HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols. В ней вы можете увидеть следующие подразделы:

• PCT 1.0;
• SSL 2.0;
• SSL 3.0;
• TLS 1.0.

Наличие или отсутствие подразделов зависит от версии операционной системы. Отсутствующие подразделы и параметры в них можно добавить.

Подразделы с именами протоколов, в свою очередь, содержат подразделы Client и Server с настройками, как ни странно, клиента и сервера.

В настройках клиента и сервера можно прописать параметры DisabledByDefault (выключен по умолчанию) и Enable (включен), которые и отвечают за использование криптографических протоколов. Тип параметров DWORD (32 бита), значения, которые они могут принимать: 0 и 1.

Настройки протокола SSL 2.0 в Windows.

Немного о значениях:

Параметр	Значение	Описание
DisabledByDefault	0	Включен по умолчанию
1	Выключен по умолчанию
Enable	0	Выключен
1	Включен

Может показаться, что параметры дублируют друг друга, но в них есть различия. Если говорить в двух словах, параметр DisabledByDefault это более мягкий вариант отключения, который допускает исключения для приложений. А вот Enable — более жесткий параметр. Enable имеет приоритет над DisabledByDefault, т.е. Enable = 0 отключит протокол, несмотря на DisabledByDefault = 0.

Таким образом вы можете включить или выключить любой из перечисленных протоколов. Например, если мы хотим отключить протоколы SSL 2.0 и SSL 3.0, то нужно создать в ветке HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols подразделы SSL 2.0 и SSL 3.0 (при отсутствии), в них подразделы Client и Server (также при отсутствии), а там создать или отредактировать параметры DisabledByDefault (в значении 1 для отключения) и Enable (в значении 0 для отключения) в зависимости от того, насколько «жёстко» мы хотим запретить протоколы.

Похожим образом можно включить поддержку более новых криптографических протоколов. Например, в Windows 7 и Windows Server 2008 R2, которые всё ещё весьма распространены, по умолчанию отключены протоколы TLS 1.1 и TLS 1.2. Для их включения нужно создать одноимённые подразделы в реестре с соответствующими настройками.

Включаем по умолчанию TLS 1.2 в Windows 7.

Для применения параметров нужно перезагрузить систему.

Напоследок отметим, что выставленные параметры применяются только для ПО, которое использует системные API. Если программа имеет собственные средства криптографии, то её нужно настраивать отдельно.

Network Manager не видит сеть

Более сложная неисправность, которая заключается в том, что Network Manager вообще не видит сетевых адаптеров, причины ее возникновения нам неизвестны, но приходилось достаточно часто сталкиваться с ней на промежуточных выпусках Ubuntu.

Кстати, данная неисправность может послужить причиной ручной настройки сетевого интерфейса, которое в последствии будет блокировать работу Network Manager, но ее также несложно вылечить, для этого нужно создать пустой файл:

И перезапустить службу:

Для дальнейшей работы Network Manager наличие данного файла необязательно, т.е. вы можете его удалить, но Network Manager продолжит работать нормально.

Как видим, предложенные нами способы восстановления здоровья Network Manager просты и, надеемся, помогут вам сэкономить время и нервы, когда вы столкнетесь с подобной проблемой.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Как включить или отключить TLS 1.0

• Нажмите сочетание клавиш Win+R и введите inetcpl.cpl, чтобы быстро открыть свойства интернета.
• Перейдите во вкладку «Дополнительно«.
• В списке найдите протокол TLS 1.0, TLS 1.1 или TLS 1.2.
• Поставьте галочку, чтобы включить и уберите, чтобы отключить.

Добрый день.
Имеется система Kubuntu 14.04 x64
Для получения удалённого управления компьютера с Windows 7 необходимо установить SSL Network Extender.
Может кто подскажет как правильньно установить SSL Network Extender в Kubuntu.

Arium — 16 Февраль, 2015 — 18:26

При проверке по зависимостям выдает следующее:
sudo ldd /usr/bin/snx
linux-gate.so.1 => (0xf7709000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf75b1000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7595000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xf757c000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7577000)
libpam.so.0 => not found
libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xf755e000)
libstdc++.so.5 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf73ae000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf738c000)
/lib/ld-linux.so.2 (0xf770a000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf7388000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7381000)

как установить недостающие библиотеки

Chibiko — 16 Февраль, 2015 — 18:40

sudo apt-get install недостающая_библиотека

Arium — 16 Февраль, 2015 — 18:48

В том то и дело, что apt-get не находит таких пакетов.

MacLeod — 17 Февраль, 2015 — 11:21

[email protected]:/var$ apt-file search libstdc++.so.5
libstdc++5: /usr/lib/x86_64-linux-gnu/libstdc++.so.5
libstdc++5: /usr/lib/x86_64-linux-gnu/libstdc++.so.5.0.7
[email protected]:/var$ apt-file search libpam.so.0
libpam0g: /lib/x86_64-linux-gnu/libpam.so.0
libpam0g: /lib/x86_64-linux-gnu/libpam.so.0.83.1
Названия пакетов слева.

Fierta — 16 Февраль, 2015 — 18:45

Гость — 17 Февраль, 2015 — 18:28

Проверил: пакеты libpam0g libstdc++5 установлены, но они находятся в каталоге /usr/lib/x86_64-linux-gnu/
Попробовал сделать символические ссылки типа
sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.5 /usr/lib/i386-linux-gnu/libstdc++.so.5
Это не помогло результат тот же.

Fierta — 17 Февраль, 2015 — 19:12

Не нужно симлинкать 64х битные библиотеки в каталог с 32х битными. Необходимо дополнительно поставить 32х битные библиотеки:
sudo apt-get install libpam0g:i386 libstdc++5:i386

Arium — 17 Февраль, 2015 — 20:09

Установил, перезапустил Firefox.
Заработало, залетел на прокси.
Запустил KRDC, выбрал режим rdp, последовательно вписал ip компьютера, доменпользователь, пароль. Зависает на несколько минут, потом выдает — не удается подключиться к удалёному хосту. Под виндой на ноутбуке, который приносил с работы, удаленный доступ работает.

Fierta — 17 Февраль, 2015 — 20:30

Соединение по VPN установлено с сервером? «Играйтесь» с настройками, попробуйте другой клиент, например remmina и т.д.