Tls как включить linux

Обновлено: 05.07.2024

MySQL – самая популярная в мире реляционная система управления базами данных с открытым исходным кодом. Современные менеджеры пакетов упрощают запуск MySQL, однако после установки следует выполнить дополнительную настройку СУБД. В частности, это касается безопасности данных.

По умолчанию MySQL принимает только локальные соединения. Прежде чем настроить поддержку удалённых соединений, очень важно позаботиться о безопасности. Данное руководство поможет настроить MySQL на сервере Ubuntu 16.04 для поддержки удалённых соединений с помощью шифрования SSL/TLS.

Требования

Для работы вам понадобятся два сервера Ubuntu 16.04 (первый будет использоваться в качестве сервера MySQL, второй – в качестве клиента).

Пользователь с доступом к sudo на каждом сервере.
На сервер MySQL нужно установить серверное программное обеспечение СУБД. Инструкции вы найдёте здесь.
На клиенте установите клиентское программное обеспечение MySQL:

sudo apt-get update
sudo apt-get install mysql-client

Проверка состояния SSL/TLS

Примечание: Выполните этот раздел на сервере MySQL.

Подключитесь к серверу MySQL и проверьте текущее состояние SSL/TLS.

Запустите сессию root-пользователя MySQL. Флаг –h позволяет указать локальный loopback-интерфейс IPv4, чтобы клиент подключался к TCP вместо локального сокета. Это позволит проверить статус SSL для TCP-соединений:

mysql -u root -p -h 127.0.0.1

По запросу введите root-пароль MySQL, после чего откроется интерактивная сессия.

Запросите состояние переменных SSL/TLS:

Переменные have_openssl и have_ssl отключены (отмечены как DISABLED). Это значит, что сервер поддерживает функции SSL, но пока что шифрование не включено.

Проверьте состояние текущего соединения:

\s
--------------
mysql Ver 14.14 Distrib 5.7.17, for Linux (x86_64) using EditLine wrapper
Connection id: 30
Current database:
Current user: root@localhost
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server version: 5.7.17-0ubuntu0.16.04.1 (Ubuntu)
Protocol version: 10
Connection: 127.0.0.1 via TCP/IP
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
TCP port: 3306
Uptime: 3 hours 38 min 44 sec
Threads: 1 Questions: 70 Slow queries: 0 Opens: 121 Flush tables: 1 Open tables: 40 Queries per second avg: 0.005
--------------

На данный момент подключение не использует SSL даже несмотря на то, что это TCP-подключение.

Закройте текущую сессию MySQL:

Генерирование SSL/TLS-сертификатов и ключей

Примечание: Данный раздел также выполняется на сервере MySQL.

Чтобы включить поддержку SSL в MySQL, сначала нужно сгенерировать соответствующий сертификат и ключ. Утилита mysql_ssl_rsa_setup, которая поставляется вместе с MySQL 5.7+, позволяет ускорить этот процесс. Ubuntu 16.04 предоставляет версию MySQL, совместимую с этой утилитой.

Файлы будут созданы в каталоге данных MySQL, /var/lib/mysql. Процесс MySQL должен иметь возможность читать сгенерированные файлы, поэтому в качестве владельца сгенерированных файлов нужно указать пользователя mysql:

sudo mysql_ssl_rsa_setup --uid=mysql

При этом будет сгенерирован такой вывод:

Generating a 2048 bit RSA private key
. +++
. +++
writing new private key to 'ca-key.pem'
-----
Generating a 2048 bit RSA private key
. +++
. +++
writing new private key to 'server-key.pem'
-----
Generating a 2048 bit RSA private key
. +++
. +++
writing new private key to 'client-key.pem'
-----

Проверьте созданные файлы:

sudo find /var/lib/mysql -name '*.pem' -ls
256740 4 -rw-r--r-- 1 mysql mysql 1078 Mar 17 17:24 /var/lib/mysql/server-cert.pem
256735 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/ca-key.pem<^>
256739 4 -rw-r--r-- 1 mysql mysql 451 Mar 17 17:24 /var/lib/mysqlsql/public_key.pem<^>
256741 4 -rw------- 1 mysql mysql 1679 Mar 17 17:24 /var/lib/mysqlsql/client-key.pem<^>
256737 4 -rw-r--r-- 1 mysql mysql 1074 Mar 17 17:24 /var/lib/mysqlsql/ca.pem<^>
256743 4 -rw-r--r-- 1 mysql mysql 1078 Mar 17 17:24 /var/lib/mysqlsql/client-cert.pem<^>
256736 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/private_key.pem<^>
256738 4 -rw------- 1 mysql mysql 1675 Mar 17 17:24 /var/lib/mysqlsql/server-key.pem<^>

В последнем столбце показаны имена сгенерированных файлов. Столбцы, в которых содержится значение «mysql», указывают, что сгенерированные файлы имеют принадлежат правильному пользователю и группе.

Эти файлы – это ключи и сертификаты для центра сертификации (название файла начинается с «ca»), а также для сервера и клиента MySQL (файлы с названиями server и client соответственно). Файлы private_key.pem и public_key.pem MySQL использует для безопасной передачи паролей вне SSL.

Включение SSL на сервере MySQL

Современные версии MySQL ищут файлы сертификатов в каталоге данных MySQL при запуске сервера. Потому для включения поддержки SSL не нужно изменять конфигурацию MySQL.

Достаточно просто перезапустить сервис MySQL:

sudo systemctl restart mysql

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

mysql -u root -p -h 127.0.0.1

Попробуйте снова запросить состояние переменных SSL:

Теперь вместо DISABLED переменные have_openssl и have_ssl имеют значение YES. Кроме того, переменные ssl_ca, ssl_cert и ssl_key теперь содержат имена соответствующих файлов.

Снова введите команду:

\s
--------------
. . .
SSL: Cipher in use is DHE-RSA-AES256-SHA
. . .
Connection: 127.0.0.1 via TCP/IP
. . .
--------------

На этот раз отображается специальный SSL-шифр, а это значит, что для защиты соединения используется SSL.

Вернитесь в оболочку:

Теперь сервер поддерживает шифрование данных.

Настройка защищенных подключений для удаленных клиентов

Теперь, когда сервер поддерживает SSL, можно начать настройку безопасного удаленного доступа. Для этого необходимо:

Настроить поддержку удаленных подключений только по SSL.
Подключиться к общедоступному интерфейсу.
Создать пользователя MySQL для удаленных подключений.
Настроить брандмауэр для поддержки внешних подключений.

Настройка удаленного доступа

На данный момент сервер MySQL поддерживает подключения SSL от клиентов. Но он также поддерживает и незашифрованные удалённые соединения, а это небезопасно.

Поскольку сокеты доступны только внутренним подключениям сервера, единственным способом подключения, доступным для удаленных пользователей, будет SSL.

Чтобы включить этот параметр, откройте файл /etc/mysql/my.cnf в текстовом редакторе:

sudo nano /etc/mysql/my.cnf

В файле вы найдёте две директивы !includedir для ссылки на дополнительные конфигурационные файлы. Нужно разместить свои настройки под этими строками, чтобы они переопределяли конфликтующие настройки.

Создайте раздел [mysqld], чтобы определить процесс MySQL. Добавьте директиву require_secure_transport со значением ON.

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

По умолчанию MySQL прослушивает только соединения, поступающие от локальной машины. Чтоб ынастроить прослушивание удалённых соединений, укажите другой интерфейс в bind-address.

Чтобы система MySQL могла принимать соединения на любой свой интерфейс, укажите в bind-address значение 0.0.0.0.

Сохраните и закройте файл.

sudo systemctl restart mysql

Убедитесь, что MySQL прослушивает 0.0.0.0 вместо 127.0.0.1.

sudo netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 4330/mysqld
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1874/sshd
tcp6 0 0 . 22 . * LISTEN 1874/sshd

Как видите, теперь MySQL прослушивает 0.0.0.0, то есть поддерживает соединения на всех интерфейсах.

Теперь нужно открыть MySQL в брандмауэре.

sudo ufw allow mysql
Rule added
Rule added (v6)

Настройка удаленного пользователя MySQL

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

Откройте сессию root-пользователя MySQL:

Создайте нового удалённого пользователя с помощью команды CREATE USER.

Используйте IP-адрес клиентского компьютера в качестве хоста нового пользователя, чтобы ограничить подключение к этой машине.

На случай если опция require_secure_transport будет отключена, добавьте REQUIRE SSL, чтобы ограничить пользователя только SSL-соединениями.

CREATE USER 'remote_user'@'mysql_client_IP' IDENTIFIED BY 'password' REQUIRE SSL;

Затем предоставьте пользователю права на требуемые базы данных или таблицы. Для примера создайте базу данных example и передайте новому пользователю право на неё:

CREATE DATABASE example;
GRANT ALL ON example.* TO 'remote_user'@'mysql_client_IP';

Затем очистите привилегии, чтобы обновить настройки БД:

Закройте оболочку MySQL:

Тестирование удалённых подключений

Примечание: Этот подраздел нужно выполнить на клиенте MySQL.

Подключитесь к клиенту MySQL и убедитесь, что можете создать удалённое подключение к серверу. Опция –u указывает удалённого пользователя, -h задаёт IP-адрес MySQL.

mysql -u remote_user -p -h mysql_server_IP

Предоставьте пароль указанного в команде пользователя, после чего вы будете подключены к удалённому серверу.

Убедитесь, что подключение шифруется:

\s
--------------
. . .
SSL: Cipher in use is DHE-RSA-AES256-SHA
. . .
Connection: mysql_server_IP via TCP/IP
. . .
--------------

Вернитесь в оболочку системы:

Попробуйте создать соединение без шифрования:

mysql -u remote_user -p -h mysql_server_IP --ssl-mode=disabled

После запроса пароля соединение будет сброшено:

ERROR 1045 (28000): Access denied for user 'remote_user'@'mysql_server_IP' (using password: YES)

Как видите, поддерживаются только SSL-соединения, а незашифрованные соединения сбрасываются.

На данный момент сервер MySQL поддерживает безопасные удалённые подключения. В целом, этого достаточно для обеспечения безопасности данных. Однако есть некоторые дополнительные рекомендации, которые можно использовать.

Проверка подлинности подключений MySQL (опционально)

В настоящее время сервер MySQL использует SSL-сертификат, подписанный сгенерированным на локальной машине центром сертификации (CA). Сертификата сервера и пары ключей будет достаточно для шифрования входящих соединений.

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

Чтобы настроить проверку подлинности, нужно:

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

Перемещение сертификата на клиент

Передайте файлы сертификата клиента MySQL с сервера на клиентскую машину.

Подключитесь к клиенту MySQL. В домашнем каталоге создайте каталог для хранения сертификатов, client-ssl.

Ключ сертификата нужно хранить в секрете. Ограничьте доступ к каталогу, в котором хранится ключ.

Теперь права доступа есть только у текущего пользователя.

Скопируйте сертификат с сервера на клиент.

Перейдите на сервер MySQL и отобразите содержимое следующего файла:

sudo cat /var/lib/mysql/ca.pem
-----BEGIN CERTIFICATE-----
. . .
-----END CERTIFICATE-----

Скопируйте весь результат (включая строки BEGIN CERTIFICATE и END CERTIFICATE).

Вернитесь на клиент MySQL, создайте файл в каталоге для сертификатов:

Вставьте в него скопированный сертификат. Сохраните и закройте файл.

Вернитесь на сервер MySQL и отобразите содержимое файла:

sudo cat /var/lib/mysql/client-cert.pem
-----BEGIN CERTIFICATE-----
. . .
-----END CERTIFICATE-----

Снова скопируйте весь результат (включая строки BEGIN CERTIFICATE и END CERTIFICATE).

Перейдите на клиент MySQL и создайте файл в каталоге для сертификатов:

Вставьте в него скопированный сертификат, сохраните и закройте файл.

Снова вернитесь на сервер MySQL и отобразите содержимое следующего файла:

sudo cat /var/lib/mysql/client-key.pem
-----BEGIN RSA PRIVATE KEY-----
. . .
-----END RSA PRIVATE KEY-----

Скопируйте полученный результат, включая строки BEGIN CERTIFICATE и END CERTIFICATE.

Вернитесь на клиент MySQL, создайте файл в каталоге:

В этот файл вставьте скопированные данные, сохраните и закройте файл.

Теперь у клиента есть все необходимые данные для подтверждения подлинности соединения.

Настройка удаленного пользователя

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

Перейдите на сервер MySQL. Откройте сессию пользователя root в MySQL:

Измените параметры удалённого пользователя. Вместо REQUIRE SSL укажите REQUIRE X509. Теперь, помимо обязательного SSL-соединения, сервер будет запрашивать у удалённого пользователя сертификат, подписанный центром, которому доверяет сервер MySQL.

Чтобы изменить параметры пользователя, введите:

ALTER USER 'remote_user'@'mysql_client_IP' REQUIRE X509;

Вернитесь в стандартную оболочку:

Тестирование проверки подлинности соединений

Теперь нужно убедиться, что сервер запрашивает сертификат клиента.

Перейдите на клиентскую машину MySQL и попробуйте создать соединение без сертификата.

mysql -u remote_user -p -h mysql_server_IP
ERROR 1045 (28000): Access denied for user 'remote_user'@'mysql_client_IP' (using password: YES)

Как видите, без сертификата клиент не сможет создать удалённое подключение.

mysql -u remote_user -p -h mysql_server_IP --ssl-ca=

Сервер должен принять такое подключение. Закройте сессию MySQL:

Создание конфигурационного файла клиента

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

Подключитесь к клиенту MySQL.

Откройте домашний каталог и создайте в нём скрытый файл

Добавьте в файл раздел [client]. В нём можно указать опции ssl-ca, ssl-cert и ssl-key со всеми путями к соответствующим файлам.

Опция ssl-ca проверяет сертификат сервера MySQL и подтверждает, что он подписан центром, которому можно доверять.

Опции ssl-cert и ssl-key указывают пути к файлам сертификата и ключа, которые позволяют подтвердить подлинность сертификата.

Сохраните и закройте файл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мануал

TLS 1.3 повышает производительность и безопасность

С TLS 1.3 требуется только одна поездка туда и обратно.

Это имеет большое значение для пользователей в мобильных сетях или в отдаленных местах.

Что касается безопасности, TLS 1.3 удалил поддержку старых наборов шифров, которые отвечают за эксплойты, такие как атака ROBOT.

Это, конечно, упрощенное объяснение.

Требования к включению TLS 1.3

Есть два требования, чтобывключить TLS 1.3 с Nginx.

Ваша версия Nginx должна поддерживать TLS 1.3. Это означает Nginx 1.13 или выше.
Nginx необходимо построить с помощью OpenSSL 1.1.1 или выше.

Ubuntu 18.10 с OpenSSL 1.1.1

Ubuntu 18.10 поставляется с OpenSSL 1.1.1, а пакет Nginx из репозитория Ubuntu 18.10 собран с OpenSSL 1.1.1.

Таким образом, пользователи Ubuntu 18.10 могут все реализовать.

Установка последней версии Nginx с OpenSSL 1.1.1 на Ubuntu 18.04, 16.04 и 14.04

Пакет Nginx из Ubuntu 18.04, 16.04, 14.04 репозиториев не собран с OpenSSL 1.1.1.

Вы можете вручную скомпилировать Nginx с OpenSSL 1.1.1, но требуется дополнительное время, и вам придется перекомпилировать все это, когда выйдет новая версия Nginx.

К счастью, мы можем установить Nginx из PPA (личный пакетный архив) Ondřej Surý, который является разработчиком Debian и важной фигурой в сообществе DNS.

Он поддерживает множество пакетов для репозитория Debian, включая Apache, BIND, MariaDB, PHP и т. д.

Он также является одним из разработчиков официального сертификата PPA.

Поэтому я доверяю его PPA и использую его на своих серверах.

Например, у меня есть другой репозиторий Nginx, определенный в файле /etc/apt/sources.list.d/nginx-repo.list.

Я просто закомментирую все строки в этом файле, чтобы отключить его.

Чтобы добавить Ondřej Surý Nginx PPA в Ubuntu, выполните следующую команду:

Затем удалите существующий пакет Nginx. (Ваши файлы конфигурации Nginx не будут удалены.)

И установите Nginx из PPA.

Ваш плагин Nginx вашего certbot может быть удален вместе с Nginx, поэтому установите его обратно.

Теперь проверьте версию Nginx.

Теперь вы должны увидеть следующее:

Этот PPA также предоставляет OpenSSL 1.1.1 для Ubuntu 18.04.

Если ваш Nginx на Ubuntu 18.04 все еще работает с OpenSSL 1.1.0, вам необходимо обновить пакет OpenSSL.

Это связано с тем, что пакет OpenSSL 1.1.1 конфликтует с некоторыми пакетами Google.

Для обновления OpenSSL вам потребуется выполнить следующую команду.

Включить TLS 1.3 в виртуальном хосте Nginx

Когда у вас есть готовый пакет Nginx с OpenSSL 1.1.1, откройте свой файл виртуального хоста Nginx.

Чтобы включить TLS 1.3, просто добавьте TLSv1.3 в директиву ssl_protocols в блоке сервера SSL.

Кстати, certbot по умолчанию разрешает TLSv1, который небезопасен, его можно удалить.

Сохраните и закройте файл.

Затем перезапустите Nginx, чтобы изменения вступили в силу.

Проверка версии TLS в веб-браузере

Используя Firefox 63 или выше, перезагрузите свою веб-страницу, щелкните правой кнопкой мыши на пустой области и выберите View Page Info в контекстном меню.

Перейдите на вкладку « Security », и вы увидите, что TLS 1.3 используется.

Используя Google Chrome 70 или выше, перезагрузите веб-страницу на своем сайте.

Затем нажмите Ctrl + Alt + I, чтобы открыть Инструменты разработчика.

Используется ли TLSv1.3 между Cloudflare и сервером Origin?

Нет. Хотя Cloudflare поддерживает TLS 1.3 на переднем сервере, в настоящее время он использует TLSv1.2 при подключении к исходному серверу.

Чтобы проверить, какая версия TLS используется, вы можете создать собственный формат журнала в файле /etc/nginx/nginx.conf.

Сохраните и закройте файл.

Затем добавьте директиву access_log в контексте SSL-сервера.

Журнал находится в формате comb_ssl.

Сохраните и закройте файл. Затем перезагрузите Nginx.

В файле журнала доступа вы увидите что-то вроде того, что изображено ниже, что указывает на то, что TLS 1.2 используется.

Данный пост написан вследствие победы желания докопаться до сути над усталостью, сонливостью, ~~соблазном опрокинуть очередную бутылочку пива пятничным вечером.~~ Сразу скажу, что ничего супер сложного не раскрываю, всего лишь включение TLS v1.3 в Nginx.

Наверняка на Хабре найдутся те, кто уже 100 раз это делал, поэтому данная статья — больше для новичков или для тех, кто хочет найти готовое решение в виде мануала, не тратя много времени на поиски, как я, например. Вспомнив, что давно не писал на Хабре и поставив статье метку «tutorial», принялся за дело.

Беглый поиск по Хабру показал, что на данную тему постов не было, а на «тостере» был топик, где вопрошающему ответили в комментариях в стиле «сам дурак».

и можно было бы спокойно закрыть таск в Jira и идти домой, но тут мой взор привлёк пункт о поддержке TLS 1.3. Точнее, там было указано, что этой самой поддержки TLS 1.3 как раз нет!

Ну что ж, как говорится,

Конечно, я видел этот пункт и раньше, но как-то не придавал значения, всё было не до того. А в этот раз сказал себе мысленно: «хватит это терпеть!» Надо всё же разобраться, как включить новый протокол.

Немного предыстории. Выход TLS v1.3 это не новость последних дней, работа над новой версией ведётся уже много лет. Со времени анонсирования TLS v1.2 прошло почти 10 лет. И вот, в апреле 2017 года вышла версия nginx 1.13.0, которая поддерживает TLS v1.3.

Если уважаемый читатель думает, что достаточно установить nginx >=1.13.0 и прописать

в настройках virtualhost, не спешите делать выводы и расходиться, я тоже попался на этот «развод» :)

При установленной версии nginx >=1.13.0 и при наличии вышеуказанной строчки в конфиге

не выдаёт ошибок, это плюс, но тест ssllabs показывает, что TLS 1.3 всё же не включён, а это большой минус.

Позже, изучив требования, я понял, что заставить работать новую версию протокола можно путём компиляции nginx >=1.13.0 с поддержкой openssl >=1.1.1, который сейчас разработке, причём версия черновика протокола — строго 18. Если брать другие версии draft, результат будет отличаться. Я не вдавался в подробности, почему-то на текущий момент за основу взяли именно 18ю версию черновика, о чём любезно сообщает ssllabs в своём disclaimer-е в результатах теста

Порядок действий:

1. Сохраняем содержимое /etc/nginx куда-нибудь в /backup, если до этого уже настроили требуемый virtualhost, чтобы не делать всё заново. Можно сразу же сделать

2. Скачиваем и распаковываем исходники openssl 1.1.1 tls1.3 draft 18.

3. Подготовительные работы для openssl

4. Собираем openssl.

Переходим в каталог с распакованным содержимым архива openssl

5. Подготовительные работы для nginx

При запуске конфигуратора nginx важно указать правильный путь к распакованным исходникам openssl нужной нам версии. У меня это /root/openssl-tls1.3-draft-18, если у вас другой путь к каталогу с исходниками openssl, тогда внесите изменения в опцию --with-openssl=.

На этапе выполнения конфигуратора openssl и/или nginx могут появиться ошибки, в основном лечатся обычным гуглением. Как правило, будет не хватать каких-то lib, ничего особенного.
90% решается тем, что берём название компонента/пакета, которого не нашёл конфигуратор и делаем

и снова запускаем конфигуратор. Повторяем процедуру, пока конфигуратор не отработает без ошибок.

Последняя команда устраняет баг компиляции nginx. Он связан с тем, что openssl v1.1.1 сейчас только на стадии разработки, и в nginx по этому поводу что-то не учтено на данный момент.

6. Компиляция nginx

После успешной компиляции не спешите делать make install, лучше сделать всё красиво

Создавать каталоги надо до выполнения checkinstall, так как после сборки deb пакета будет попытка установить его в систему, если какого-то каталога не будет хватать, завершится fail-ом.

На этом этапе nginx должен быть установлен в системе, но если выполнить

выдаст, что nginx — нет такой команды/бинарника. Не спешите расстраиваться, всё дело в том, что установлен он не совсем по стандартному пути PATH, а вот здесь — /usr/share/nginx/sbin/nginx

Cледовательно, выполнять нужно

Чтобы было красиво, сделаем

и тогда запускаем

себе на здоровье и без ошибок.

Небольшой минус — после инсталляции nginx нет ни init.d скрипта, ни конфига для systemd.
Лечится так (один из способов):

это новый файл, мы его создаём сами, вписываем содержимое

Возвращаем обратно каталог nginx из /backup в /etc, лучше перед этим удалить /etc/nginx, так как туда что-то было положено после выполнения checkinstall и dpkg -i

Готовы к запуску nginx

Всё должно подняться, если нет, небольшой troubleshooting будет даже полезен.

Ещё один маленький штрих. Необходимо донастроить nginx virtualhost, активировать новый набор шифров.

Уже точно не помню, но точно больше часа ушло на то, чтобы найти источник, где упоминалось про шифры, и что в TLS 1.3 они должны быть такими:

В целом конфигурация nginx у меня получилась такая:

Это не готовая конфигурация для production среды, здесь нет кэширования, сжатия и других полезных и важных вещей. Напомню, цель статьи — это активировать TLS 1.3 и только.

После редактирования проверяем, что всё хорошо

Если да, делаем рестарт nginx и запускаем тест на ssllabs. Должно быть вот так

Как включить поддержку TLS 1.3 в браузерах Chrome, Firefox, чтобы протестировать новый протокол можно было прямо на локальной машине, можно найти — здесь.

В наши дни использование TLS является практически обязательным. TLS реализует защитные функции конфиденциальности и целостности данных, а так же служит для поддержки аутентификации LDAP с использованием механизма SASL EXTERNAL. TLS определён в RFC4346.

Для настройки TLS на сервере нам понадобятся SSL сертификат и ключ. Сертификат должен быть подписан доверенным удостоверяющим центром (УЦ, Certificate Authority, CA) или собственным удостоверяющим центром (на основе самоподписанного, self-signed, сертификата), если используется в тестовых целях.

С помощью OpenSSL мы создадим импровизированный удостоверяющий центр и затем настроим TLS.

Прямая цитата из Википедии:

3.1 Удостоверяющий центр на основе самоподписанного сертификата с помощью OpenSSL

Где работаем: ldap-srv

Итак, мы создаём централизованную инфраструктуру открытых ключей (PKI) в миниатюре. Для этого сформируем пару закрытый ключ/корневой сертификат удостоверяющего центра. Причём сертификат будет подписан этим же закрытым ключом (т. е. станет самоподписанным).

Затем сгенерируем новый закрытый ключ для нашей службы каталогов и создадим для неё сертификат, подписанный закрытым ключом нашего удостоверяющего центра. При этом клиенские рабочие станции должны знать только корневой сертификат. Используя его они могут установить безопасное соединение с любым сервером, который имеет закрытый ключ и соответствующий ему сертификат, подписанный нашим УЦ.

Такие пары (ключ/сертификат) можно создавать для множества задач. Например, в разделе, посвященном репликации, мы создадим второй сервер каталогов, которому тоже понадобится такая пара.

Создадим каталог для нашего удостоверяющего центра (CA) и установим безопасные права доступа. Затем зададим значение umask таким, чтобы вновь создаваемые файлы имели права доступа чтения и записи только для создавшего их пользователя:

В конфигурационном файле /etc/ssl/openssl.cnf в секции [ CA_default ] для удобства поменяем значение директивы dir = ./demoCA на dir = ./ . В этом же разделе директивой default_days задаётся срок действия выпускаемых сертификатов. Можете поменять её значение по своему усмотрению.

Файлы index.txt и serial будут играть роль своеобразной базы данных, чтобы отслеживать статус выпущенных закрытых ключей и сертификатов.

Создадим структуру каталогов и файлов для своего удостоверяющего центра:

Сгенерируем закрытый ключ удостоверяющего центра (длиной 4096 бит). Он должен хранится особенно бережно. Поэтому мы защитим его при помощи шифра AES. Вам будет предложено ввести пароль для доступа к новому закрытому ключу. Запомните его и не потеряйте. Это последний рубеж защиты от злоумышленника. Без пароля выпустить новые сертификаты не получится.

Изменим права доступа к новому ключу, чтобы ненароком его не стереть:

Откройте конфигурационный файл OpenSSL (openssl.cnf) и найдите секции [ usr_cert ] и [ v3_ca ] . Убедитесь, что в них присутствуют следующие директивы:

Сейчас мы можем выпустить корневой сертификат удостоверяющего центра, подписав его закрытым ключом rootca.key. Так как это сертификат УЦ, используем расширение v3_ca :

В качестве алгоритма хэширования мы используем SHA-2 (подвид SHA-256). Стоимость атаки на SHA-1 стремительно падает, а о практическом применении новоявленного SHA-3 говорить пока рано. Почему мы выбрали именно SHA-256, а не SHA-512? С сертификатом, использующим SHA-512, Вы сможете запустить демон slapd, но не сможете к нему подключиться. Увидите лишь такую многозначную ошибку:

Мы так же указываем количество дней, в течении которых сертификат будет действителен. Десять лет — достаточно большой срок.

С помощью модификатора subj заносим в сертификат информацию:

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

Удостоверяющий центр готов к выпуску сертификатов.

3.2 Выпуск сертификата для сервера службы каталогов

Где работаем: ldap-srv

Как правило, закрытые ключи клиентов УЦ не должны хранится в самом УЦ. Клиент может сам сформировать ключевую пару и прислать в УЦ лишь запрос на подпись (Certificate Signing Request, CSR). Запрос содержит открытый ключ. Однако мы будем создавать все ключи и хранить их в одном месте. В организации, которая серьёзно подходит к проблемам безопасности такой процесс работы может быть неприемлемым.

Продолжаем в том же каталоге /root/CA. Создадим закрытый ключ для сервера службы каталогов:

Сгенерируем запрос на подпись сертификата. Наименование организации (ExampleInc) должно совпадать с наименованием в корневом сертификате УЦ. В качестве Common Name укажем FQDN нашего сервера:

Следующим шагом должно быть подписание запроса CSR существующим доверенным удостоверяющим центром (например, VeriSign) в обмен на деньги. Но нам не хочется платить за эту услугу, или у нас нет своего (корпоративного) CA, или это просто тестовая конфигурация, а может нам просто всё равно. Поэтому мы подпишем его с помощью своего собственного CA:

Создадим каталог для ключевой информации нашего сервера и поместим туда получившиеся у нас файлы:

Установим права доступа для ключевой информации:

Поместим корневой сертификат в каталог с сертификатами операционной системы и зададим для него права доступа:

В заключение можем удалить запрос CSR, он нам больше не нужен:

Каталог /root/CA теперь выполняет роль удостоверяющего центра. Аналогичным образом его можно создать на другой машине, тогда надо будет копировать секретные ключи и подписанные сертификаты по сети с помощью scp или через съёмный носитель. Неплохой идеей будет хранить этот каталог на отдельном носителе и монтировать его только для выпуска новых сертификатов. Сам носитель можно, например, положить в сейф. Процесс создания новых пар ключ-сертификат в будущем будет состоять из трёх этапов:

Генерация секретного ключа и запроса на подписание сертификата;
Подписание сертификата с помощью закрытого ключа нашего CA (rootca.key);
Перемещение новых секретного ключа и подписанного сертификата в каталоги, где они будут использоваться.

3.3 Настройка конфигурации TLS

Где работаем: ldap-srv

Вернёмся во временный каталог:

Создадим LDIF-файл 3.2-tls-config.ldif для внесения в каталог конфигурации TLS и запишем в него:

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

Загрузим конфигурацию TLS в наш каталог:

Теперь наш сервер OpenLDAP должен поддерживать расширения TLS. Перепроверим, что всё в порядке:

Вновь отредактируем конфигурационный файл /etc/ldap/ldap.conf и включим поддержку TLS:

Обычно для конфигурации cn=config перезагрузка службы не требуется, но чтобы созданная нами ключевая информация подхватилась, придётся это сделать:

Проверьте соединение с сервером с использованием TLS (модификатор -ZZ ). На этот раз мы выполним запрос с использованием DN нашего администратора:

3.4 Создание CRL и отзыв сертификатов

Где работаем: ldap-srv

Сертификаты не вечны. Во-первых при создании задаётся его срок действия. При этом частота обновления сертификатов — баланс между безопасностью и удобством. Во-вторых он может быть скомпрометирован, если скомпрометирован его закрытый ключ. Как во втором случае оповестить субъектов доступа, что сертификат более не действителен? Для этого и служит Certificate Revocation List (CRL). Он представляет собой список серийных номеров отозванных сертификатов, подписанный УЦ, который их выпустил.

Вернёмся в каталог удостоверяющего центра:

Прежде чем мы сможем сгенерировать CRL, надо создать файл crlnumber. Он нужен openssl, чтобы отслеживать номер следующего CRL:

В стандартной конфигурации openssl использует CRL V1. Раскомментируйте строку в /etc/ssl/openssl.cnf, чтобы переключиться на CRL V2. Это хорошая идея, за исключением тех случаев, когда надо использовать именно CRL V1 (например, при использовании сильно устаревшего браузера). Создаём CRL:

Посмотреть результат можно так:

Предположим, что закрытый ключ сервера ldap-srv был скомпрометирован. Чтобы оповестить об этом клиентские машины, надо отозвать сертификат этого сервера, создать CRL, а затем — распространить CRL среди клиентов.

Заглянем в index.txt. Начало записи с нашим сертификатом теперь изменилось с V на R :

Обратите внимание, что копии новых сертификатов так же содержатся в каталоге newcerts. При этом имя файла содержит серийный номер сертификата. Когда отзываете сертификаты, вместо файлов в каталоге certs Вы можете пользоваться каталогом newcerts. Результат будет идентичен. Например:

Взглянём на содержимое CRL:

Вы должны увидеть нечто подобное:

Поместим CRL в каталог, где его увидит клиентское ПО:

Осталось только распространить этот CRL среди клиентов. Мы делаем это простым путём — копированием файлов по сети вручную.

Где работаем: ldap-client

На каждой клиентской машине надо будет запустиь:

Настроим клиентскую конфигурацию в /etc/ldap/ldap.conf и укажем, где хранится CRL:

И попробуем получить доступ к серверу каталогов:

Наш CRL работает. Но к slapd теперь не подключиться. Надо выпустить новый сертификат для сервера.

Где работаем: ldap-srv

Сделаем это простой последовательностью команд. Мы повторяем пройденное, комментарии излишни:

Перезупустим демон slapd и убедимся, что к серверу можно подключиться:

В целом по отзыву сертификатов. Иногда в реальных условиях лучше применить другой подход. Намного удобней, когда клиентские машины самостоятельно выясняют у сервера, действителен конкретный сертификат или нет. В выпускаемые сертификаты можно вносить запись CRL Distribution Points . Она заставит клиентов самих периодически скачивать новый CRL. Или можно использовать OCSP. Но эта тема выходит за рамки данного руководства.

Читайте также: