Как настроить tls соединение

Что такое SSL и TLS, как установить и настроить

Основная установка и настройка будет проходить под Debian 8 Jessie, вебсервер NGINX, в бекенде Apache или PHP-FPM.
Инструментарий: Far Manager и Putty.
Команды вводятся в консоль SSH.
Если вы авторизованы не под root , добавляйте перед консольными командами sudo

Что такое SSL, TLS

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

TLS (англ. Transport Layer Security — безопасность транспортного уровня) — криптографический протокол, обеспечивающий защищённую передачу данных от сервера к клиенту. TLS является потомком SSL 3.0. В основе работы лежат симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации и коды аутентичности сообщений для сохранения их целостности.

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

Сегодня, когда говорят об SSL, то, как правило, подразумевают его потомка TLS. Поэтому, когда говорят, что нужно установить SSL сертификат на сайт, то, как правило, подразумевают установку TLS сертификата.

Почему нужно использовать SSL/TLS

Есть как минимум одна веская причина: вы не сможете воспользоваться преимуществами нового протокола HTTP2 (HTTP/2 приходит на смену текущему стандарту HTTP/1.1), если для вашего сайта не установлен и настроен сертификат безопасности SSL/TLS.

Также безопасность данных в интернете является всё более востребованной и актуальной темой. И чем дальше, тем больше: Google заявил, что наличие SSL-шифрования на сайте является положительным фактором в ранжировании сайта в поисковой выдаче. Также, наличие HTTPS является обязательным атрибутом для каждого e-commerce сайта: интернет-магазинов, сервисов по приёму платежей, обменников, а также платных сервисов, данные пользователей которых являются желанной добычей хакеров. Чтобы предотвратить фишинг-атаку на пользователя и не дать обмануть его, и нужно настроить SSL-сертификат безопасности и шифрования данных, чтобы он видел подтверждение того, что находится на правильном сайте.

Бесплатные сертификаты SSL/TLS от Let’s Encrypt

Рекомендую воспользоваться сертификатами SSL/TLS от Let’s Encrypt, так как:

1. Они бесплатные;
2. Подойдут большинству проектов;
3. Установка и настройка относительно несложные, и не займут много сил и времени.

Из минусов — сертификат актуален 90 дней, поэтому настроим его обновление на автомате.

Если у Вас виртуальный хостинг, можете написать в службу поддержки, вам помогут получить сертификат и всё настроят. Если же у вас свой сервер, описание получения сертификата SSL, TLS и его настройки на сервере будет дальше.

Установка Certbot

Сам гайд по установке Let’s Encrypt советует делать всё через Certbot. Сработает, если есть доступ по SSH.

Certbot — это утилита от Let’s Encrypt, помогающая в настройке SSL/TLS сертификата на сервер и его дальнейшем обновлении.

Установка Certbot в Debian 8 Jessie

Помощник Certbot в выборе версии сервера

Сначала убедимся, что certbot ещё не установлен:
certbot —help
Если увидите ошибку, значит, надо его установить.

Если вылезла ошибка The value ‘jessie-backports’ is invalid for APT::Default-Release as such a release is not available in the sources
, нужно настроить поддержку Backports

Как настроить поддержку Backports

Пишете в консоль (добавляет дополнительный источник для пакетов):

Потом обновляете список пакетов:

и снова пробуете установить Certbot:

Затем проверяете, как вышло

Установка Certbot в CentOS 7

Установка происходит так:

Если у Вас CentOS 6, воспользуйтесь универсальной инструкцией ниже.

Универсальная инструкция по установке Certbot

1. Скачиваем Certbot:
2. Даём права на исполнение с помощью chmod
3. Перемещаем certbot-auto к остальным бинарным файлам, чтобы появилась возможность начинать команды с certbot
4. Проверяем, что получилось:

Настройка Certbot

Теперь, когда certbot установлен (а вы можете убедиться в этом, задав команду
certbot —help ), советую заглянуть в cron-задачи

В директории должен появиться файл certbot с примерно следующим содержанием

Самая последняя строчка — это правило cron, которое будет проверять сертификаты SSL, TLS дважды в день и обновлять устаревшие. К сожалению, он не перезагружает вебсервер, поэтому Вам нужно добавить правило && /etc/init.d/nginx reload вручную в конец строки.

В итоге, строка будет выглядеть примерно так:

1. Открываем расписание планировщика (сначала приведу пример для nano, затем для vim):
2. Добавляем новое правило в конце планировщика:
3. Затем сохраняем ( Ctrl + X , сохранить кнопкой Y )

Далее, подготовка, тестирование и установка сертификата для сайта.

Подготовка и тестирование конфигурации SSL, TLS

Перед тем, как получить сертификат SSL/TLS, хорошей практикой будет протестировать правильность настройки сервера. Дело в том, что если есть проблема, которая не даст получить или обновить сертификат: центр сертификации имеет жёсткие лимиты обращений к нему (10 в час). И если есть ошибка, которую никак не удаётся выявить, то можно очень быстро упереться в лимит. Чтобы избежать этой проблемы, можно воспользоваться Staging Environment от Let’s Encrypt.
Staging Environment — это тестовая среда, полностью имитирующая общение с центром сертификации, и выдающая недоверенные сертификаты-пустышки. Однако, она имеет повышенные лимиты обращения к ней и служит исключительно для тестирования и настройки конфигурации сервера:

• Выдача и обновление сертификата на 1 домен имеет лимит 30 000 в неделю.
• Ошибка валидации имеет лимит 60 раз в час.

Чтобы воспользоваться тестовой окружающей средой, достаточно для certbot использовать ключ —staging .
Например, так можно протестировать выдачу сертификата:

Кстати, посмотреть, как происходит обновление сертификатов, но без реального обновления, просто проверить правильность конфигурации, можно командой:

А обновить все сертификаты на сервере вручную можно командой

После перезагрузите NGINX

Установка сертификата SSL, TLS от Let’s Encrypt

Вводим команду в консоль Putty:

• -w /var/www/example.com — путь до директории с файлами сайта
• -d example.com -d www.example.com — прописываем имена доменов
• —email [email protected] — ваш email, куда можно будет восстановить доступ
• —agree-tos — согласие с лицензионными требованиями

Если домен в кириллице, надо получить его Punnycode (например, яндекс.рф имеет код xn--d1acpjx3f.xn--p1ai ) и пользоваться этим кодом. Сделать это можно с помощью Punycode-конвертера.

Если всё нормально, вам выдаст сообщение об успешном завершении создания сертификата

Итак, сертификат установлен в директорию /etc/letsencrypt/live/<тут_ваш_домен>/

Идём настраивать NGINX.

Настройка SSL, TLS в NGINX

Открываем конфигурационный файл вашего сайта.
Если NGINX настроен как тут, то конфигурационный файл может быть расположен тут:
/etc/nginx/vhosts/example.com.conf

Для уменьшения загрузки процессора официальная документация рекомендует

• установить число рабочих процессов равным числу процессоров,
• разрешить keep-alive соединения,
• включить разделяемый кэш сессий,
• выключить встроенный кэш сессий
• и, возможно, увеличить время жизни сессии (по умолчанию 5 минут):

Изменения я буду комментировать

Сохранили, проверили, перезагрузили

Настройка SSL, TLS на WordPress

Для примера, возьмём сайт на WordPress и настроим на нём SSL/TLS, сделаем его доступным по HTTPS.
Нужно будет обязательно пройтись по списку и внести соответствующие изменения:

1. Переписать в базе данных все ссылки, заменив http://example.com на https://example.com
   Для этого, вы можете воспользоваться WP-Cli или специальной утилитой Seach Replace DB
2. Переписать в файлах темы все ссылки, заменив http:// на https:// или //
3. Отредактировать wp-config.php , а именно, перед define(‘WP_DEBUG’, false); добавить:

2 и 3 строки не обязательны, если выполнили первый пункт списка.

Как перенести сайт с HTTP на HTTPS правильно

Я считаю, что можно не ждать склейки http и https, и сразу настроить редирект на https, они всё равно склеятся, но далее приведу рекомендации, которые дают специалисты по поисковому продвижению

Если вы переводите существующий проиндексированный сайт на SSL, то сначала рекомендуется, чтобы Yandex склеил http и https версии сайта. Для этого, вы должны сначала настроить сайт так, чтобы он был доступен и по http, и по https верно, а затем прописать в robots.txt нужный адрес в директиве Hosts.

Не забудьте добавить новую версию сайта на HTTPS в Яндекс Вебмастер и Google Webmasters.

Вот, скажем, пример файла robots.txt для сайта sheensay.ru

Далее, рекомендуется, чтобы все внутренние ссылки были относительными либо начинались строго с протокола https:// . У всех внешних javascript скриптов, ссылок, вставленных картинок, аудио- и видеоплееров, и других внешних объектов протоколы http:// заменяются на абсолютные https:// или относительные // .
Приведу пример:

• НЕПРАВИЛЬНО: <img src=»http://placehold.it/250×250″>
• ПРАВИЛЬНО: <img src=»//placehold.it/250×250″>
• ПРАВИЛЬНО: <img src=»https://placehold.it/250×250″>

Далее, проверяем секцию head, ищем теги <rel rel canonical=»»> и <rel rel alternate=»»> , и следим, чтобы адреса в них начинались с https://
Таким образом, вы добьётесь более быстрой склейки разных версий сайта в одну.

Далее, дождавшись, когда Яндекс всё склеит правильно, можно настроить 301 редирект с http на https

Как настроить 301 редирект с HTTP на HTTPS

Для NGINX мы настраивали редирект выше, поэтому если редирект настроили в нём, в Apache ничего не меняем. Но, для примера, покажу блок, ответственный за него

301 редирект с HTTP на HTTPS в NGINX

Тут нужно указать 2 блока server , для http (там мы настраиваем редирект) и для https

301 редирект с HTTP на HTTPS в .htaccess (Apache)

Если у Вас основной сервер Apache, в его конфигурационном файле ( apache.conf ) или в .htaccess в корне сайта прописываем

Эта конструкция отлавливает все запросы к портам, отличным от 443 (а именно на 443 порту сидит SSL), и редиректит на нужную версию сайта с HTTPS.

Если у вас во фронтенде NGINX, то редирект в .htaccess может и не сработать. В таком случае, рекомендую воспользоваться редиректом в WordPress.

301 редирект с HTTP на HTTPS в WordPress

Чтобы сделать 301 редирект на https в wordpress, достаточно найти в корне сайта wp-config.php и прописать там в любом месте (если ещё не прописано, example.com меняете на свой домен):

В большинстве ситуаций этого достаточно.

Если доступа к wp-config.php нет, то есть ещё один вариант.
Код ниже используете в MU Plugin, также можно создать обычный плагин (требует активации) или вставить в functions.php рабочей темы:

Перед включением кода убедитесь, что сайту уже присвоен HTTPS: (Настройки — Общие)

Как проверить правильность работы SSL, TLS

В интернете можно найти множество сервисов, которые помогут определить, как правильно вы установили SSL и настроили сайт под него.
Один из таких сервисов: ssllabs.com

Рекомендую проверять правильность установки и настройки сертификата SSL/TLS с помощью ssllabs.com

Вы просто вводите адрес сайта и через несколько минут получаете результаты теста. Например, вот высший результат тестирования ( A+ ) по домену https://sheensay.ru

Результат тестирования SSL/TLS

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности.
Чтобы добиться заветного A+ , нужно правильно настроить NGINX.
Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

Затем, необходимо присутствие следующих записей в конфигурации сервера:

После всех манипуляций, не забудьте перезагрузить NGINX

Видео установки и настройки SSL сертификата в хостинге Beget

Если Вы хотите установить SSL, TLS сертификат на сайт, который расположен в Beget, Вам пригодится следующая видеоинструкция:

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт.
Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту 443 уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны.
Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это /root ):

• cert.pem — это сертификат SSL/TLS;
• key.pem — это ключ к сертификату.

Самоподписанные сертификаты годится, скорее, для служебных целей, нежели чем для использования на рабочих сайтах. Дело в том, что к ним нет никакого доверия, они не обеспечивают должной защиты для пользователя, и браузеры будут предупреждать об этом. Но, скажем, в случае настройки сервера с несколькими сайтами, а также для редиректа с HTTPS на HTTP вполне годятся.

Ещё пример, когда такое решение пригодится — на CloudFlare, настроенном на Flexible SSL, плагин Broken Link Checker при сканировании выдаёт ошибки доступа к изображениям Connection Failed . И тут тоже помогут самоподписанные сертификаты на 443 порту сайта.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

• Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
• Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге /root/ . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта example.com , мы можем использовать следующую конфигурацию ( example.com заменяем на свой домен, 1.2.3.4 — на свой IP сервера):

SSL certificate problem: certificate has expired

Что делать, если при запросах curl вылезает ошибка:

curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

Самым правильным вариантом будет обновление сертификатов на сервере. В Linux Debian, Ubuntu это делается так:

Эта команда обновляет символические ссылки сертификатов в /etc/ssl/certs .

MNorin.com

Блог про Linux, Bash и другие информационные технологии

TLS и SSL: Необходимый минимум знаний

TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.

Что такое SSL и что такое TLS?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

Принцип работы SSL и TLS

Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:

Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Корневой сертификат

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

Запрос на подпись (CSR, Certificate Sign Request)

Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.

Клиентский сертификат

Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

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

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

Если необходим клиентский сертификат в формате PKCS12, создаем его:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:

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

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

На стороне клиента обращаемся к серверу, например, culr’ом:

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

Со стороны сервера ошибка выглядит так:

Со стороны клиента так:

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

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

Windows Server — настройка TLS

TLS — это критически важный протокол безопасности транспортного уровня, который используется для шифрования связи между клиентами и серверами. На данный момент рекомендуемыми протоколами на Windows Server являются TLS 1.2 и TLS 1.3.

TLS 1.1, TLS 1.0, SSL 3.0 и более ранние протоколы следует отключить из-за их слабой безопасности. В них есть ряд известных уязвимостей, которыми могут воспользоваться злоумышленники. Например:

• POODLE (Padding Oracle On Downgraded Legacy Encryption)
• BEAST (Browser Exploit Against SSL/TLS)
• CRIME (Compression Ratio Info-leak Made Easy)
• FREAK (Factoring Attack on RSA-EXPORT Keys)
• LOGJAM (Diffie-Hellman Key Exchange Weakness)

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

Здесь осуществляется включение и отключение протоколов для Schannel.dll, как клиентских, так и серверных. Для каждого протокола своя ветка.

Список и порядок просмотра наборов шифрования (чиперов).

В параметре DefaultSecureProtocols настраиваются протоколы для приложений на WinHttp API.

Настройка эллиптических кривых.

Отключение MD5 шифрования.

Настройка размера пула потоков для TLS рукопожатий в HTTP.SYS.

Управление протоколами описано в документации:

Включить TLS 1.0

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] «Enabled»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] «DisabledByDefault»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] «Enabled»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] «DisabledByDefault»=dword:00000000

Отключить TLS 1.0

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] «Enabled»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server] «DisabledByDefault»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] «Enabled»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] «DisabledByDefault»=dword:00000001

Отключить TLS 1.0 через PowerShell

Включить TLS 1.1

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] «Enabled»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] «DisabledByDefault»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] «Enabled»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] «DisabledByDefault»=dword:00000000

Отключить TLS 1.1

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] «Enabled»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server] «DisabledByDefault»=dword:00000001
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] «Enabled»=dword:00000000
• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client] «DisabledByDefault»=dword:00000001

Отключить TLS 1.1 через PowerShell

Если лень работать руками можно воспользоваться бесплатной утилитой IIS Crypto:

Если нужно настроить через групповые политики, то придётся использовать политику реестра, специальных настроек для TLS в GPO нет.

Настройка протоколов TLS на Windows Server

Написать эту статью подоткнул тот факт, что Windows Server 2016, установленный из коробки, почему-то не имеел TLS протокол, включенный как основный по умолчанию, в то время как SSL3.0 был включен. Приводит это к разным последствиям, как для безопасности, так и для функционирования различных сервисов и приложений.

Проблемы версий протоколов SSL и TLS и совместимости приложений

Для начала рассмотрим проблемы связанные с версиями SSL протоколов:

• SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
• SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
• TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
• TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1). Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

Но и это оказывается не полной правдой. Дело в том, что использование протоколов зависит не только от системных настроек, но и от того, как написаны приложения. Например, я выяснил, что .NET приложения используют свои собственные настройки безопасности. Также известно, что если включить поддержку TLS 1.2 на SQL Server (например, применив патч https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server), установленный на Windows Server 2012, то приложения .NET и JAVA потеряют возможность подключаться к SQL.

Также давно известна проблема с вэб приложениями, написанными на базе интерфейса WinHTTP API. После включения TLS 1.1/1.2 они также перестают подключаться.

Службы IIS и ADFS при этом прекрасно используют новые протоколы, следуя системным настройкам. Более того, к сервисам Azure вы не сможете подключиться через TLS 1.2, но при этом, как выяснилось, Powershell даже в Windows Server 2016 использует SSL3.0 и TLS 1.0, несмотря на то, что согласно системной настройке они отключены.

Как правильно настроить TLS для разного типа приложений?

Начнем с того, что для всего есть свои реестровые ключи, однако нужно точно понимать, какой тип приложения вы хотите настроить, чтобы избежать проблем. Начну с того, что полный список доступных системных ключей в Windows 10/Windows Server 2016/2019 доступен по ссылке https://docs.microsoft.com/ru-ru/windows-server/security/tls/tls-registry-settings. Изменяя их, вы можете настроить IIS, ADFS и прочие службы. Однако, эти ключи не влияют на работу приложений .NET (и в частности, Powershell) и WinHTTP!

В чем же дело? Дело в библиотеках. IIS и ADFS используют Schannel — поставщик поддержки безопасности (SSP), реализующий стандартные протоколы проверки подлинности SSL, TLS и DTLS Internet. Интерфейс поставщика поддержки безопасности (SSPI) является интерфейсом API, используемым системами Windows для выполнения функций, связанных с безопасностью, включая проверку подлинности. В Windows все функции SSPI выполняет библиотека Schannel.dll, в которой реализованы все протоколы и наборы шифрования.

Итак, ветки реестра, которые нас интересуют:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols — включение и отключение протоколов для Schannel.dll, как клиентских, так и серверных. Для каждого протокола — своя ветка;
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers — здесь можно изменить список и порядок просмотра (это важно!) наборов шифрования;
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp — в параметре DefaultSecureProtocols настраиваются протоколы для приложений на WinHttp API;
• HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Cryptography\ECCParameters — настройка эллиптических кривых для криптографии;
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5 — отключение MD5 шифрования для маркеров безопасности.

Теперь пройдем по конкретным примерам и настройкам.

Отключение SSL и TLS 1.0 протоколов на системном в Schannel подробно описано в документации Microsoft. Отключить небезопасные можно как через реестр, так и с помощью Powershell.

В этой же статье ниже описано, как отключить небезопасные алгоритмы шифрования, такие как RC4.

Отключить небезопасные наборы шифрования (cipher suites) можно через параметр Functions в ключе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 .

Этот параметр является многострочным текстовым значением, который просто содержит построчный список наборов (один на строку). Удалите ненужные строки.

Наборы шифрования

Порядок проверки наборов шифрования также удобно изменять с помощью групповых политик. Это также описано в документации.

Ну и наконец, для управления доступными наборами появились командлеты Powershell. Например, с помощью Disable-TlsCipherSuite вы можете отключить неугодный набор.

Отключение SSL для Powershell и других .NET приложений

Как я уже писал, системные настройки выше не влияют на Powershell сессии. Проверить, какие протоколы сейчас активны в вашей Powershell сессии, можно выполнив команду

Если в выводе команды увидите ssl30, tls, то их надо отключить.

Для этого в Windows Srver 2012 / Windows 2016 используйте ключ реестра

С помощью самого Powershell это можно изменить одной командой:

New-ItemProperty -path ‘HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319’ -name ‘SchUseStrongCrypto’ -value ‘1’ -PropertyType ‘DWord’ -Force | Out-Null

Включение TLS 1.2 для WinHTTP

Если коротко, то в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp нужно добавить параметр DefaultSecureProtocols, который в 16-ричном виде будет содержать сумму значений всех протоколов, которые необходимо включить. Например, для включения TLS 1.1 и 1.2 надо добавить значение 0x00000A00, которое будет суммой значений TLS 1.1 (0x00000200) и TLS 1.2 (0x00000800).

Готовый патч от Microsoft для исправления этого также можно скачать по ссылке KB3140245

Настройка с помощью IISCrypto

IISCrypto — это бесплатная утилита, не требующая установки, которая позволяет включить/выключить многие настройки Schannel через графический интерфейс, .NET и WinHTTP она не настраивает.

Скачать её можно с сайта разработчика без регистрации.

[Посещений: 7 334, из них сегодня: 1]