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

Необходимый минимум знаний об SSL/TLSTLS и 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. Если есть вопросы/дополнения, пишите в комментарии.

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

  1. cl-service.com

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

    1. mnorin Автор записи

      Так и есть. Но некоторые сертификационные центры генерируют CSR сами, например, WoSign. Клиент и не должен передавать ключ, он должен передавать только sign request. На виртуальном сервере у администраторов хостинга есть доступ вообще ко всему. Но тут есть один момент. Если использовать ключевую фразу, то доступ к сертификату с ключом без нее бесполезен. Хотя тут есть и минус. При запуске сервера придется руками эту фразу вводить, поэтому сервер автоматически стартовать при старте системы не сможет.

  2. Доброжелатель.

    Тема сисек не раскрыта, ибо описанная технология работы PKI не имеет ничего общего с заголовком темы. Хоть бы для причия ссылки на rfc привел.
    P.S. Был такой анекдот про собаку и блоху.

    1. mnorin Автор записи

      Как говорится, отрицаешь — предлагай.
      Тема с описанной технологией связана напрямую, потому что именно то, что описано, в большинстве случаев и называют «Как работает SSL».
      Ну и RFC по заявке читателя:
      RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0
      RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
      И да, тебе тоже добра.

  3. Доброжелатель.

    Нивкоем случае не хотел тебя обидеть. Искал инфу о различии SSl и TLS на практике и твоя ссылка в гугле была первая. Был заинтрегован названием темы. Все круто, так держать!

  4. DrAibolit

    Благодарю за толковые пояснения о цифровой сертификации. Я новичок в этом=)
    Надеюсь разъясните следующий вопрос.
    Поскольку в интернет индустрии очень развита тема мошенничества, хотелось бы научиться определять на «вшивость» самостоятельно посещаемые мною сайты (особенно, где присутствуют кашельки и оплаты, инвестиции и т.д) и определять исходя из этого степень моего доверия (приходится часто регистрироваться, оставлять личную информацию, совершать покупки, транзакции, инвестиции). Если я правильно понял, что наличие данной сертификации позволяет сделать такую оценку. Ну и с другой стороны, получить ее не проблема и даже бесплатно.
    Как или с помощью какой программы можно определить наличие цифрового сертификата у того или иного сайта? и желательно его категорию, которая присваивается при выдаче спецорганом SSL DV (выдача сертификата проводится с проверкой только домена), SSL OV (с проверкой организации), EV (с расширенной проверкой юрлица). Мошеннические сайты скорее всего последним вариантом сертификации пользоваться не станут..
    Буду рад, если поведаете еще способы определения надежности сайтов))

    1. mnorin Автор записи

      Какой-то определенной программы для этих целей я еще не встречал, но пару советов по этому поводу могу дать.
      Можно использовать, например, Chromium или Google Chrome. Возьмем, например, сайт https://www.thawte.com/ — компания, которая собственно цифровымисертификатами и занимается.
      В адресной строке будет написано название компании и зеленый замочек. Это значит, что организация проверена, это как минимум SSL OV.
      Если кликнуть на замочек, а в выпавшем окошке «Details», а затем «View Certificate», то можно увидеть информацию о сертификате. Для Thawte сертификат подписан следующим сертификатом: «thawte Extended Validation SHA256 SSL CA», а сертификат для click.alfabank.ru тоже подписан Thawte, но другим сертификатом. Это «thawte EV SSL CA — G3», то есть они тоже проходили Extended Validation.
      Как-то так.

      1. xfiles

        зеленую строку с названием организации можно получить только с EV сертификатом ?

  5. Руслан

    Раздел «Принцип работы SSL и TLS», «Клиент генерирует случайную цифровую последовательность».

    Я был уверен что клиент генерирует сеансовый закрытый и, соответственно, открытый ключи (который вы, очевидно, и назвали «цифровая последовательность»). Открытый ключ передаётся серверу и сервер шифрует пакеты в сторону клиента сеансовым открытым клиентским ключом.

    Уточните, пожалуйста.

    1. Maxim Norin Автор записи

      Я лучше дам ссылку на technet.microsoft.com, раздел «Key exchange». В статье написано, естественно, упрощенно, чтобы просто объяснить принцип работы, при этом не сильно вдаваясь в детали.

  6. Новичок

    Статья очень полезная! Даже есть практические примеры=) Только я не понял одну вещь — в чем различие между корневым сертификатом и серверным? или это одно и тоже?

    1. Maxim Norin Автор записи

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

  7. Виталий

    Здравствуйте.
    Хостер предложил услугу — SSL для виртуальных серверов. Воспользовались. Оказалось, что для третьего уровня, т.е. http://www.site.ru сертификат недействителен, только для site.ru. Притом, посетителей упорно кидает на протокол https, не важно, заходят они на site.ru или на http://www.site.ru. Разумеется, во втором случае браузер начинает истошно ругаться, а посетитель до сайта так и не добирается.
    А для тех, кто до сайта таки добрался, сайт стал выглядеть криво, пропала часть меню, перестала отображаться часть картинок в выдаче некоторыми компонентами.

    Решили отключить эту кривую заразу. Не тут то было! В контрольной панели у хостера отключили. Доступ к сайту из сети пропал вообще. По-прежнему бросает на протокол https, и браузеры ругаются:
    «site.ru использует недействительный сертификат безопасности. К сертификату нет доверия, так как он является самоподписанным. Сертификат недействителен для имени site.ru.»
    Техподдержка предложила… восстановить сайт из бэкапа!

    Вот и стою на асфальте, в лыжи обутый. То ли лыжи не едут, то ли …
    Подскажите пожалуйста, чайнику. Оно так и должно было работать? Или всё же кривые сертификаты с кривыми настройками серверов у хостера, или как?
    Спасибо. С уважением,
    Виталий

    1. Maxim Norin Автор записи

      Добрый день.
      Это не должно так работать однозначно. Обычно в нормальных сертификатах указываются ДНС имена, для которых он выдан (с www и без www).
      То, что вы описываете, бывает либо с сертификатами, в которых DNS-имена не указаны, либо с wildcard-сертификатами.
      Я думаю, что это кривые сертификаты и настройки у хостера все-таки.
      Плюс, возможно на самом сайте захардкожен протокол http в разных местах, поэтому контент отображается частично. Такие проблемы решаются либо проксированием, либо правкой сайта.

      1. Виталий

        Спасибо, Максим.
        То, что сайт в одном из компонентов стал криво отображаться из-за захардкоженного http, я понял. Но оказалось, что и в админку стало не попасть для того, чтобы проверить эти косяки )))
        А техподдержка хостера предлагает восстановление из бэкапа ))) Вместо того, чтобы, по моему пониманию, разобраться с настройками сервера, который, несмотря на удаление сертификата, по-прежнему инициирует https-соединение.
        Пока спорил с ними, и читал про SSL, во время чего и попал к Вам на сайт, немного понял, как это должно работать, и что на деле работает некорректно.
        Спасибо за подтверждение моих предположений. Мне следует осваивать тему глубже.
        С уважением,
        Виталий

  8. Сергей

    Добрый день. Сразу оговорюсь, что очень далек от администрирования Unix-серверов, сетевой безопасности и прочего, посему вопрос может быть сформулирован несколько некорректно, за что прошу прощения.
    При работе с API Telegram методом Webhook требуется наличие сертификата, насколько я понимаю из официальной документации (https://core.telegram.org/bots/webhooks#how-do-i-get-a-server-with-a-domain-name) достаточно самоподписанного. Опять же, насколько мне понятно, наличие доменного имени необязательно, в таком случае IP должен использоваться в качестве CN (Common Name?). Имеется VDS с установленной Centos, доменное имя не регистрировал. Пытался получить обновления по инструкции на оф. сайте, но не добился желаемого результата, вероятно, из-за того, что не понял, что такое «IP в качестве CN» и проигнорировал данный пункт. Хотя, сервер Telegram посылает в ответ OK и код 200, что должно свидетельствовать о том, что сертификат принят и всё должно работать.
    Подскажите, мне стоит сгенерировать сертификат с указанием IP сервера в качестве CN? Нужно ли при этом проводить какие-либо манипуляции с ранее сгенерированными сертификатами или достаточно их просто удалить с сервера и отправить Telegram новые?

    1. Maxim Norin Автор записи

      Добрый день. Нужно сгенерировать новые сертификаты с указанием IP в качестве имени сервера (поле CN), оно же FQDN. С уже сгенерированными сертификатами ничего сделать не получится.

      1. Сергей

        Что, помимо сертификата, необходимо для доступа по https? Настройка веб-сервера? Ткните в сторону нужного направления.

        1. Maxim Norin Автор записи

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *