Установка StartSSL сертификатов — Postfix/Dovecot/Nginx / Хабр

Что такое tls и зачем он патрику

TLS (Transport Layer Security) – это протокол защиты транспортного уровня. Он нужен для того, чтобы никто не мог вас «прослушать» и узнать какую-то важную информацию (чаще всего пароли, если говорить о работе в сети). А еще для того, чтобы защититься от подделывания и модификации трафика в процессе передачи. Именно в этих двух вещах состоит назначение TLS.

Для наглядности давайте рассматривать TLS handshake как звонок Патрика Губке Бобу. Во время звонка кто-то может подслушать разговор (стоя рядом с Патриком либо включившись в середине линии), и вообще на другом конце может быть не Губка Боб – все эти проблемы актуальны. И чтобы их порешать, Патрик хочет использовать TLS.

Вкратце, верхнеуровневый handshake выглядит так:

Патрик: Хочу использововать TLS, шифры-версии такие-то.Губка Боб: Ок, давай использовать шифры-версии такие-то.

Что дальше?

Итак, после того, как сертификат получен, сервер передает данные сеансового ключа – это то, с помощью чего дальше будет осуществляться шифрование. Если сервер считает, что нужно аутентифицировать клиента (например, доступ открыт только определенному кругу лиц), он может спросить: клиент, кто ты? И тогда клиенту надо будет послать свой сертификат. После получения сообщения

ServerHelloDone

клиент понимает, что пора проверять сертификаты и работать с ключами.

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

Вторая часть: Введение в TLS для п̶р̶а̶к̶т̶и̶к̶о̶в̶ Патриков (часть 2)

Caa rr

Есть такая проблема, что люди, которым все верят, иногда не очень хорошие. Одна из причин того, что Symantec стал частью DigiCert, состоит в том, что он (Symantec) выписывал сертификаты без запроса от владельцев домена. Так делать нельзя, обидно было всем, но больше всех самому Symantec, потому что пришлось продать свой бизнес.

Для того, чтобы сервер меньше зависел от таких недобросовестных товарищей, есть такая штука как CAA RR – запись в DNS, где написано, кому владелец разрешает выписывать сертификаты для своего домена. Эта функция есть и в Plesk, она пока используется мало, примерно как DNSSec, – но тем не менее.

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

Также CAA RR с того момента, как мы делали их поддержку в Plesk, расширились указанием методов валидации (то есть, можно также указать здесь, каким методом ты валидируешь, что этот домен твой) и Account URI (Uniform Resource Identifier). Популярный среди пользователей Plesk Let’s Encrypt уже всё это поддерживает (молодец!).

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

Connect: ftp

Здесь мало что можно сказать. Основная проблема – SNI (это когда на одном IP разные домены). На уровне FTP имя домена не передается. В эксплицитном варианте работать не может, потому что некуда его писать. Существует несколько вариантов решения — одни предлагают так, другие так, общее решение пока не принято, стандарта нет.

Кратко: поддержка TLS для FTP в каком-то виде есть (FTPS, SFTP — аналог FTP, реализованный через SSH), но некоторые аспекты не охвачены в силу технических ограничений самого FTP.

Connect: mail

Многие клиенты считают, что на 587-м порту должен быть TLS, но здесь тоже есть нюансы: кто-то ожидает TLS по умолчанию, а кто-то ждет явного запроса

STARTTLS

от клиента. Из-за этого в разных сочетаниях mail-сервера и mail-клиента иногда возникают нежелательные эффекты. Например, клиент заходит на 587 порт, ожидая, что там будет TLS, в то же время сервер ждет, что клиент сам явно запросит

STARTTLS

. Ничего не получив, клиент откатывается на 25-й порт. В итоге – молчаливое переключение на небезопасное соединение по SMTP. При тестировании и разработке стоит помнить о таких эффектах сочетаний клиента и сервера. В Autodiscover есть разные возможности указать про TLS: как оно должно быть, что ожидается и что делать. Многие mail-клиенты понимают эти вещи.

Кратко: с поддержкой TLS в mail-серверах и mail-клиентах все в общем и целом нормально, но в частных случаях могут быть проблемы и расширения TLS поддерживаются не очень хорошо.

Dns-challenge

Кроме ACME, есть еще DNS-challenge. Например, тебе говорят: заведи в своей DNS-зоне txt-запись, положи в нее данные. Есть и другие способы, но мало распространённые, а один вообще отменили, потому что он оказался уязвимым. Что у нас в Plesk: wildcard-сертификаты (которые могут быть выписаны только по DNS-challenge) у многих людей не работают, потому что очень часто Plesk не управляет DNS-зонами домена и экстеншн

не может автоматизировать создание записи в DNS-зоне.

Domain validation

Субъектом является домен, то есть здесь мы проверяем только его. Раньше, когда не было автоматических валидаторов, валидация происходила в основном по e-mail через сервис Whois. Это считалось достаточным основанием для того, чтобы считать, что ты владелец этого домена.

Dovecot

С довекотом все оказалось намного проще и у меня все заработало с первого раза

How do tls/ssl and starttls work?

To understand the role of encryption in email transmissions, we need to briefly explain what the ‘handshake’ is about. In the same way that humans in many cultures tend to shake each other’s hands at the start of a conversation, email clients and servers also follow a similar ritual.

When an email is sent, a client reaches out to a server to verify its reliability. It shares which SSL/TLS versions it’s compatible with and also the encryption method one can expect from it. The server responds with its digital certificate to confirm its identity. When it checks out, the two sides generate and exchange a unique key that will now be used to decrypt messages.

Mdaemon

Nginx

С ним тоже все очень просто и в целом процедура не отличается от dovecot’овской

Organization validation

В поле «subject», кроме доменного имени, указывается еще и имя организации. Проверка состоит в валидации, принадлежит ли домен данной организации и работает ли там тот, кто пришел за сертификатом. Как это делается: по реестрам организации ищут, звонят, просят что-то сделать (телефон оказался верным, правильный человек ответил – значит, скорее всего всё хорошо).

Postfix

С постфиксом я намучился больше всего. Казалось бы, есть документация, куча примеров и тд, должно быть все просто, но нет, перепробовав кучу вариантов попутно перечитывая документацию я убил не мало времени пока все стало работать.

Ssl and tls – what are they all about?

As you can read in our article on SMTP security, this protocol is not secured by default. As such, it’s quite easy for the internet villains to intercept emails and make use of confidential information. Luckily, there are encryption methods in place that make their lives a bit more difficult.

Ssl/tls version history

As we mentioned before, SSL has been deprecated for a few years already and TLS is considered to be the most reliable development in email encryption. Despite that, some platforms still use SSL, despite its vulnerabilities.

Tls handshake

Итак, теперь мы знаем, как инициировать общение с использованием TLS в разных соединениях и Патрик смог сообщить о своем желании Губке Бобу. Как только они договорились, что будут использовать TLS, производится TLS Handshake. Его результатом должна стать договорённость клиента и сервера о том, как они всё это шифруют.

What’s the role of starttls?

STARTTLS is not a protocol but an email protocol command. It’s used to tell an email server that an email client (such as Gmail, Outlook, etc.) wants to upgrade an existing insecure connection to a secure one, using SSL or TLS.

Note that the name ‘STARTTLS’ doesn’t indicate that only a TLS connection can be established. SSL can also be used with this command.

STARTTLS, except for SMTP, is also used with IMAP protocol, traditionally used for retrieving emails from an email server. POP3, another protocol for receiving emails, uses a similar command called STLS.

Wrapping up

Be aware that, even with ancient technology as SMTP, things can change pretty quickly. A new version of TLS or even a completely different protocol may be introduced. Some ports could become redundant while others will rise to fame. When that happens, we’ll be sure to update the article, but try to always be on the lookout for the latest news and trends in the industry.

Еще два слова о let’s encrypt

Важный аспект в работе с сертификатами Let’s Encrypt – лимиты. В случае сомнений (или подозрений, что они достигнуты) лучше всего пройти по ссылочке:

Иногда их обновляют. Есть неочевидные лимиты, про которые люди забывают: чаще всего, судя по обращениям в поддержку, они сталкиваются с лимитом в 100 доменных имен в сертификате. Еще у Let’s Encrypt есть staging-сервер и там лимиты больше, но такие сертификаты считаются не доверенными (non-trusted) и для браузера они аналогичны самоподписанным.

На практике с лимитом в 100 имен к нам приходят редко (при том, что у сайтов на Plesk в общей сложности 1 300 000 Let’s Encrypt сертификатов). Медиана, согласно нашей статистике, – 20 имен на сертификат. Так что, если что-то не работает, посмотрите – возможно, достигнут лимит. У Let’s Encrypt хороший error reporting, и обычно можно понять, что произошло.

Как же получить сертификат?

Вкратце – вот так:

Патрик говорит центру сертификации (Certificate Authority): мне нужен сертификат. Этот человек (или организация) проверяет, действительно ли это Патрик. Проверки могут быть самыми разными. Конечно, Патрик как клиент может и не иметь сертификата, а вот если сертификата нет у сервера, то никакого TLS не будет.

Проверяется, всё ли правильно указано в заявке сертификата, действительно ли Патрик владеет этим субъектом (subject), на который просит сертификат. Этим занимаются вышестоящие удостоверяющие центры (Certificate Authority centres) – условные люди, которым все верят. Чтобы выписать сертификат, нужно составить CSR (Certificate signing request, запрос на выдачу сертификата).

Это тоже структура, работать с которой довольно сложно, потому что сервисов, позволяющих всё задать, указать, проверить и посмотреть, мало.

Итого, мы генерируем пару публичный ключ: приватный ключ, но отдаем только публичный, а приватный прячем. Затем формируем Certificate Signing Request и подписываем своим приватным ключом. Отправляем всё это центру сертификации, и тот начинает проверку. Она может быть разной, для особо крутых сертификатов есть специальные хитрые процедуры, но мы остановимся на общем случае.

Погдотовка

У вас уже есть 3 файла

Подготовка

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

Получение сертификата: автоматизация

Теперь поговорим об автоматизированном получении DV сертификатов. Для наглядности посмотрим, как это делает наш любимый Let’s Encrypt. У него вообще хорошая документация, если кому интересно, и даже на русском.

Собственно сертификат

Вместе с ответом «Давай делать вот так» сервер посылает свой сертификат или сертификаты – их может быть много.

Что представляет собой сертификат? Это связь информации (subject) – чаще всего это имя домена или организации, — и публичного ключа (public key). То есть, сертификат говорит: «Чувак, мой public key вот такой. Сейчас мы с его помощью договоримся о сессионных ключах».

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

Таким образом, сертификат – это структура ‘Subject: Public key’ плюс подпись того ишьюера (issuer в транслитерации на русский выглядит ужасно, но самый близкий синоним здесь — не очень близкий по контексту «эмитент»), который этот сертификат выписал.

Давайте пробежимся по сертификату и посмотрим, какие с ним могут быть проблемы.

Во-первых, serial Number подразумевает уникальность только в пределах ишьюера, хотя некоторый софт считает, что он уникален во всей вселенной. К счастью, чаще всего он действительно полностью уникален.

Также в сертификате указывается, какие алгоритмы используются для шифрования и подписи: RSA или ECDSA — то есть, какую криптографию использовать для работы с этим публичным ключом. Основная разница между RSA и ECDSA в том, что математический принцип работы ECDSA основан на эллиптических кривых, а RSA — просто на натуральных числах, поэтому он медленнее и для того, чтобы его нельзя было взломать, используются огромные биты ключей (3-4 тысячи).

А для ECDSA достаточно ключа длиной в 300 бит и работает он быстрее. Поэтому многие переходят на ECDSA – handshake сам по себе тяжелый и хочется его сократить. ECDSA можно попросить при выписке сертификата, и если ишьюер его поддерживает, он вам сделает.

А вот подпись сертификата зависит от того, какой приватный ключ есть в данный момент у ишьюера, а не от того, попросили вы ECDSA или RSA. Поэтому браузеры могут показывать, что в подписи одно, а в публичном ключе другое и не надо бояться, если в подписи не ECDSA.

Типы сертификатов

Их три:

Шифры и версии

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

Набор шифров есть в реестре IANA, а в протоколе TLS в бинарном виде лежит только его ID. Как видно на рисунке, здесь не просто (и не только) шифр, а еще режим его работы и другие детали, необходимые для TLS-handshake. Углубляться в подробности Патрику не нужно. Всё, что важно на данном этапе, это запомнить, что эти буквочки — это хорошо (а остальные — нехорошо):

Картинка для запоминания хороших шифров:

Если запоминать тяжело, есть хорошие сервисы, которые могут вам про это рассказать, например, сервис от Mozilla ssl-config.mozilla.org.

Тут же можно посмотреть, что где и как поддерживается – за этим ребята из Mozilla пытаются следить.

Интересная деталь: клиент передает шифры в порядке приоритета согласно своим предпочтениям, но решение остается за сервером – он выбирает шифр, который ему кажется наилучшим из списка поддерживаемых клиентом.

Также обе стороны указывают максимальную поддерживаемую версию протокола – в данном случае Патрик более продвинутый, чем Губка Боб.