Тип безопасности ssl tls или starttls

тут блог

Общественные обязательства интроверта.
Сообщения на ИТ тематику, но не обязательно.

О STARTTLS

SSL, который Secure Sockets Layer, бывает разный. И как минимум с 1999 года он называется TLS — Transport Layer Security. Впрочем, сути это не меняет.

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

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

SSL/TLS — это гибридная криптосистема. У нас есть клиент, и есть сервер. Клиент всегда подключается к серверу. У сервера есть приватный ключ, который всегда при нём. И у сервера есть публичный ключ, в виде сертификата, подписанного каким-то центром сертификации. Ну или подписанный ключом самого сервера — самоподписанный сертификат. Сертификат содержит имя сервера, сведения о его владельце и прочее. Правильность этих сведений подтверждается подписью. Центры сертификации подписывают сертификаты за деньги. Это организации, которые дорожат своей репутацией, а мы им доверяем. И на этом доверии всё и держится.

Клиент, когда подключается к серверу, получает его сертификат. Он проверяет: а действительно ли это сертификат того сервера, к которому мы подключаемся? А не истёк ли срок действия сертификата? А доверяем ли мы тому центру сертификации, что подписал этот сертификат? Иногда сертификат бывает и у клиента, и он предъявляет его серверу, а сервер производит подобные же проверки. Если всё ок, то идём дальше.

Используя ассиметричное шифрование, приватные ключи и публичные ключи из сертификатов, клиент и сервер договариваются о ключе сессии. Это ключ уже симметричного шифрования. И этим ключом будут зашифрованы последующие данные. Всё секурно и красиво, если вы пользуетесь свеженькими реализациями TLS. Все SSL, версии от 1.0 до 3.0, нынче считаются небезопасными. Безопасные — это TLS 1.1 или 1.2, и, может быть, TLS 1.0.

Хорошо, у нас есть надёжный способ шифровать TCP соединения. Но у нас есть и старые добрые, уже работающие протоколы. Как добавить к ним шифрование?

Поначалу решили: а давайте назовём это новым протоколом и повесим на отдельный TCP порт. К имени протокола как правило добавляют буковку S — Secure. Так HTTP стал HTTPS и переехал с порта 80 на порт 443. FTP стал FTPS, вместо портов 21-20 стал использовать порты 990-989. Не путать с SFTP, который использует шифрование SSH, а не SSL. SMTP, протокол пересылки почты, стал SMTPS и перехал с порта 25 на порт 465. В почте вообще много протоколов: POP3→POP3S — 110→995, IMAP→IMAPS — 143→993. Даже в Jabber, он же XMPP, сначала пошли по этому пути, для клиентских SSL подключений вместо порта 5222 взяли порт 5223, для междусерверных подключений вместо 5269 взяли порт 5270. О боже, даже telnets придумали, на порту 992.

Этот подход, когда для SSL шифрования выделяется отдельный порт, сам исходный протокол никак не меняется, а просто заворачивается в SSL, называется SSL wrapping. Даже была утилитка, которая так и называлась sslwrap, и позволяла добавить SSL к любому протоколу.

У такого оборачивания есть свои недостатки. У нас добавляется целый новый порт. По-хорошему, его надо регистрировать в IANA. Его надо открывать в файерволах. Этот порт должен кто-то слушать, а значит, у нас будет в два раза больше демонов: на старом незашифрованном порту, и на новом SSL порту. Наконец, так как обмен сертификатами и договорённость о параметрах шифрования происходят ещё до начала работы нашего прикладного протокола, некоторые возможности этого протокола перестают работать.

Хороший пример: виртуальный хостинг в HTTP, он перестал работать в HTTPS. У нас есть один HTTP сервер, а обслуживает он несколько сайтов, с разными доменными именами. В HTTP/1.1 клиент в каждом запросе указывает заголовок Host , куда помещает соответствующую часть URL. Сервер смотрит на этот заголовок, и выбирает, к какому обслуживаемому сайту относится запрос. Всё просто. Но в случае с SSL клиент запрашивает и проверяет сертификат сервера ещё до передачи каких-либо заголовков. И в сертификате содержится доменное имя сервера. И клиент удостоверяется что это именно то имя, к которому он обращается. По-хорошему, у каждого сайта должен быть свой сертификат. А здесь получается, что на одном 443 порту может быть только один сертификат, который не может соответствовать всем сайтам сразу. Вот и не работает.

В попытке обойти эти трудности решили пойти другим путём. Расширить протоколы, чтобы можно было начать сеанс связи без шифрования, а потом переключиться на шифрование, если и клиент, и сервер его поддерживают. Это красиво называется Opportunistic TLS. А команда, включающая шифрование, называется STARTTLS.

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

В случае SMTP это выглядит примерно так. Можно проверить обычным telnet .

Клиент спрашивает у сервера, какие фичи он поддерживает: командой EHLO . Сервер говорит, что, среди прочего, он умеет STARTTLS: 250-STARTTLS . Клиент говорит STARTTLS . Сервер говорит: я готов, начинай. После этого и надо начинать TLS, только telnet этого не умеет.

В XMPP, так как это протокол на основе XML, STARTTLS выглядит как XML тэг: .

В OpenSSL есть встроенный клиент, который умеет делать STARTTLS. Например для SMTP.

Клиент довольно убогий, но оно и понятно, ибо только для тестов. Он очень забавно воспринимает некоторые символы, поэтому команды SMTP лучше набирать маленькими буквами: rcpt to: , потому что большая R заставляет этот клиент делать реконнект. Тем не менее, он умеет делать STARTTLS для smtp, pop3, imap и ftp (параметр -starttls ).

Использовать один и тот же порт для незашифрованных и для шифрованных соединений оказалось так удобно, что отдельные порты для SSL быстренько объявили устаревшими. Так что теперь стандартный и кошерный способ делать TLS — это STARTTLS.

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

А вот с HTTPS как-то не сложилось. Возможно, потому, что в HTTP не предусмотрено длительных сессий между клиентом и сервером, STARTTLS просто некуда воткнуть. Впрочем, подобная попытка предпринималась в RFC 2817, но не прижилась. Там предлагалось делать Upgrade протокола до TLS, примерно как сейчас делается для WebSocket или для одновременной поддержки HTTP и HTTP/2.

OpenSSLный клиент можно и для SSL wrapper использовать. (Заголовок Host для запроса в HTTP/1.1 является обязательным)

Но сейчас виртуальные хостинги вполне живут под HTTPS, выкручиваются. Можно взять wildcard сертификат, на домен *.myhost.example , и все поддомены смогут прикрываться этим сертификатом. Можно включить в один сертификат несколько доменных имён, чаще всего с помощью расширения для сертификатов под названием subjectAltName. Мы просто указываем в одном сертификате доменные имена всех сайтов на нашем сервере. Вот только для добавления ещё одного сайта сертификат придётся перевыпускать.

Ну а самый кошерный способ: Server Name Indication, описанный аж в 2003 году в RFC 3546, но реально реализованный лишь в последние годы. Это расширение к самому протоколу TLS, имя сервера передаётся открытым текстом ещё до обмена сертификатами, и сервер может выбрать, какой сертификат возвращать. Полноценный аналог заголовка Host . И полноценная поддержка виртуального хостинга с разными сертификатами для разных сайтов.

В HTTP/2 всё остаётся без существенных изменений. Спецификация не требует обязательного TLS, существуют URL со схемой http и https . Но существующие реализации работают только с TLS. При этом требуется TLS 1.2 или выше и поддержка Server Name Indication.

Тем не менее, для HTTP/2 есть забавный черновик Opportunistic Security for HTTP. Чтобы для http URL работал TLS, если клиент с сервером договорятся. Вместо одной команды STARTTLS в этом черновике предполагается обмен JSONами.

Является ли STARTTLS менее безопасным, чем TLS /SSL?

В Thunderbird (и я предполагаю, что у многих других клиентов тоже) у меня есть выбор между «SSL /TLS» и «STARTTLS».

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

Или другими словами:

Является ли STARTTLS менее безопасным, чем SSL /TLS, потому что он может вернуться к открытому тексту без уведомления?

7 ответов

Ответ на основе STARTTLS RFC для SMTP ( RFC 3207 ):

STARTTLS менее безопасен, чем TLS.

Вместо того, чтобы говорить сам, я позволю RFC говорить сам за себя, с четырьмя соответствующими битами, выделенными в BOLD :

Атаку «человек в середине» можно запустить, удалив «250 STARTTLS «от сервера. Это приведет к тому, что клиент не будет чтобы попытаться запустить сеанс TLS. Другая атака «человек в середине» чтобы сервер мог объявить о своей возможности STARTTLS, но изменить запрос клиента на запуск TLS и ответ сервера. В чтобы защитить от таких атак, как клиенты, так и серверы ДОЛЖНЫ быть , чтобы требовать успешного согласования TLS соответствующий набор шифров для выбранных хостов до сообщений может быть успешно перенесен. Дополнительная опция использования TLS, когда возможно ДОЛЖНО также предоставляться. Реализация MAY обеспечивает способность записывать, что TLS использовался при общении с данным сверять и генерировать предупреждение, если оно не используется в более позднем сеансе.

Если согласование TLS завершается с ошибкой или если клиент получает 454 ответ, клиент должен решить, что делать дальше. Есть три основные варианты: выполните оставшуюся часть сеанса SMTP , [. ]

Как вы можете видеть, сам RFC заявляет (не очень четко, но достаточно ясно), что нет НИЧЕГО, требуя от клиентов устанавливать безопасное соединение и информировать пользователей о неудачном соединении. Он явно предоставляет клиентам возможность тихо устанавливать соединения с открытым текстом .

Нет никакой разницы в безопасности между двумя параметрами.

SSL /TLS сначала открывает соединение SSL /TLS, затем начинает транзакцию SMTP. Это должно произойти на порту, который не имеет уже запущенного SMTP-сервера без SSL /TLS; невозможно настроить один порт для обработки как обычного текста, так и зашифрованных соединений из-за характера протоколов.

STARTTLS запускает транзакцию SMTP и ищет поддержку с другого конца для TLS в ответе на EHLO. Если клиент видит STARTTLS в списке поддерживаемых команд, он отправляет STARTTLS и начинает переговоры для шифрования. Все это может (и обычно происходит) на стандартном SMTP-порту 25, частично для обратной совместимости, но также для обеспечения оппортунистического шифрования между конечными точками, которые поддерживают его, но не обязательно требуют его.

Как правило, SSL /TLS используется только между конечными клиентами и серверами. STARTTLS чаще используется между MTA для обеспечения межсерверного транспорта.

Учитывая эти две реализации, STARTTLS может быть истолковано как небезопасное, если пользователь или администратор предполагают, что соединение зашифровано, но на самом деле не настроило его на необходимость шифрования. Тем не менее, используемое шифрование точно такое же, как SSL /TLS, и поэтому не более или менее уязвимо для атаки Man-in-the-middle за пределами этого типа ошибки конфигурации.

Для электронной почты, в частности, в январе 2018 года был выпущен RFC 8314 , в котором явно рекомендуется, чтобы «Неявный TLS» используется в предпочтении механизма STARTTLS для сообщений IMAP, POP3 и SMTP.

Вкратце, в этой заметке теперь рекомендуется:

• Версия TLS версии 1.2 или выше будет использоваться для всего трафика между MUA и почтовые серверы отправки, а также между MUA и Mail Access Серверы.
• Поставщики MUA и почтовых услуг (MSP) (a) препятствуют использованию протоколы открытого текста для почтового доступа и отправки почты и (b) отказаться от использования протоколов cleartext для этих целей в качестве как только это практически осуществимо.
• Подключения к серверам отправки почты и серверам почтового доступа сделанный с использованием «Неявный TLS» (как определено ниже), в предпочтении подключение к порту «cleartext» и согласование TLS с использованием STARTTLS или аналогичной команды.

В какой-то степени ответ зависит от того, что вы подразумеваете под «безопасным».

Во-первых, ваше резюме не совсем отражает разницу между SSL /TLS и STARTTLS.

• С SSL /TLS клиент открывает TCP-соединение с «SSL-портом», назначенным прикладному протоколу, который он хочет использовать, и сразу же начинает говорить TLS.
• С помощью STARTTLS клиент открывает TCP-соединение с «портом cleartext», связанным с протоколом приложения, который он хочет использовать, затем спрашивает сервер «какие расширения протоколов вы поддерживаете?». Затем сервер отвечает на список расширений. Если одно из этих расширений — «STARTTLS», клиент может сказать «хорошо, давайте использовать TLS», а два начинающих говорящих TLS.

Если клиент настроен на требование TLS, два подхода более или менее одинаково безопасны. Но есть некоторые тонкости о том, как STARTTLS необходимо использовать, чтобы сделать его безопасным, и для реализации STARTTLS немного сложнее получить эти данные.

С другой стороны, если клиент настроен на использование TLS только в том случае, если TLS доступен, и использовать cleartext, когда TLS недоступен, то, что может сделать клиент, сначала попробуйте подключиться к порту SSL, используемому протоколом, и если это не удается, подключитесь к порту cleartext и попробуйте использовать STARTTLS и, наконец, вернитесь к cleartext, если TLS недоступен в любом случае. Для злоумышленника довольно легко заставить соединение с портом SSL выйти из строя (все, что требуется, это некоторые своевременные пакеты TCP RST или блокировка порта SSL). Это немного сложнее, но только немного — для злоумышленника, чтобы победить переговоры STARTTLS и заставить трафик оставаться в открытом виде. А затем злоумышленник не только прочитает вашу электронную почту, но и получит ваше имя пользователя /пароль для будущего использования.

Таким образом, простой ответ заключается в том, что если вы подключаетесь к серверу, который вы уже знаете, поддерживает TLS (как это должно быть в случае отправки или чтения электронной почты), вы должны использовать SSL /TLS. Если соединение атаковано, попытка подключения завершится неудачно, но ваш пароль и адрес электронной почты не будут скомпрометированы.

С другой стороны, если вы подключаетесь к какой-либо службе, которую вы не знаете, поддерживает ли она TLS, STARTTLS может быть немного лучше.

Когда был изобретен STARTTLS, «пассивные» атаки только для прослушивания были очень распространены, «активные» атаки, в которых злоумышленник вводил трафик, чтобы попытаться снизить уровень безопасности, были менее распространены. Через 20 или около того лет с тех пор активные атаки стали более осуществимыми и более распространенными.

Например, если вы пытаетесь использовать ноутбук в аэропорту или в каком-либо другом общественном месте и пытаетесь прочитать свою почту через Wi-Fi, который предоставляется там, вы не знаете, что делает сеть Wi-Fi с вашим трафиком. Для сетей Wi-Fi очень часто направлять определенные виды трафика на «прокси», которые вставляются между вашими клиентскими приложениями и серверами, с которыми они пытаются разговаривать. Для этих прокси-серверов тривиально отключить как STARTTLS, так и «попробовать один порт, а затем другой», чтобы заставить вашего клиента вернуться к cleartext. Да, это происходит, и это всего лишь один пример того, как ваш трафик может отслеживаться сетью. И такие атаки не ограничиваются трехбуквенными агентствами, поддерживающими государство, их можно снять подростком с компьютером за 35 долларов, который где-то скрыт в общественном месте.

Да, у вас есть основы правильно. И да, STARTTLS определенно менее безопасен. Мало того, что он может вернуться к открытому тексту без уведомления, а потому, что он подвержен атакам «человек-в-середине». Поскольку соединение начинается в режиме очистки, MitM может лишить команду STARTTLS и предотвратить распространение шифрования. Тем не менее, я считаю, что почтовые серверы могут указывать, что переводы происходят только после настройки зашифрованного туннеля. Поэтому вы можете обойти это.

Так почему же такая вещь существует? По соображениям совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете получить правильное соединение.

Согласитесь с @Greg. Эти атаки возможны. Однако MTA могут быть сконфигурированы (в зависимости от MTA), чтобы использовать «обязательный TLS», а не «оппортунистический TLS». Это означает, что TLS и только TLS используются (это также включает STARTTLS) для транзакций электронной почты. Если удаленный MTA не поддерживает STARTTLS, письмо отскакивает.

Нет, это не менее безопасно, когда ваше приложение обрабатывает его правильно.

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

• Нет TLS
• TLS на выделенном порту (только пытается TLS)
• Использовать TLS, если он доступен (Tries starttls , использует незашифрованное соединение при его отсутствии)
• Всегда используйте TLS (используется starttls ) и сбой, если он не работает)

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

Но в целом безопасность зависит от обработки ошибок безопасности. Программа может решить переключиться на открытый столбец, когда TLS на TLS-порту также терпит неудачу. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.

Сертификаты SSL и TLS: предназначение, отличия и проверка

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

Другое дело, когда спустя сотню запросов мы находим нужную вещь для покупки, но она расположена на сомнительном ресурсе. И тут уже возникает вопрос: «А не будет ли мне это стоить всего моего состояния?». Давайте разберемся, как уберечь себя от потери личных данных и проверить сайт на наличие SSL и TLS сертификатов.

Сертификаты SSL и TLS: зачем они нужны

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

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

SSL расшифровывается как Secure Socket Layer, что означает «уровень защищенных сокетов». TLS же обозначается как Transport Layer Security, «безопасность транспортного уровня». По своей сути обе технологии занимаются одним делом – защитой пользовательской информации от злоумышленников.

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

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

Специфика работы сертификатов SSL/TLS

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

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

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

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

Как проверить сертификаты SSL/TLS

Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.

SeoLik

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

Проверяем наличие HTTPS соединения:

1. Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ».
2. В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков.

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

SSL Shopper

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

1. Переходим в онлайн-сервис и вводим ссылку, которую требуется проверить.
2. После выполнения запроса мы видим, что сайт надежно защищен.
3. Если пролистать немного ниже, то можно посмотреть дополнительную информацию о сертификатах.

Wormly Web Server Tester

Один из самых популярных инструментов для проверки сайтов, который помогает не только узнать о наличии SSL/TLS, но и дает возможность просмотреть данные о шифровании, различные протоколы и многое другое. Работает это следующим образом:

1. Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
2. Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires».

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

Immuni Web

Это многофункциональный гигант, который анализирует поддержку протоколов, проверяет на совместимость PCI DSS и делает много всего, что недоступно в предыдущих инструментах. Конечно, здесь можно проверить и сайт на безопасность.

1. Переходим по ссылке и в строку запроса «Enter your website or mail server address here» вписываем адрес для проверки. Далее кликаем по кнопке запуска справа от строки.
2. Как только появятся результаты, перед нами отобразится новая страница. Пролистываем немного вниз и находим две строчки «Valid From» и «Valid To». Первая информирует о том, когда был выдан сертификат, вторая указывает на окончание срока действия.

При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report».

SSL Checker

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

1. Переходим по ссылке и вводим адрес. Справа от строки запроса кликаем по кнопке «Check».
2. Перед нами отобразится вся нужная информация. Для того чтобы напомнить об истечении срока действия сертификата, достаточно кликнуть по кнопке «Remind me SSL is about to expire» и указать свою почту.

На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте. Спасибо за внимание!

Про установку SSL-сертификатов вы можете почитать тут и тут.

Про порты и шифрование в почтовых серверах

При настройке сервера исходящей почты на почтовом клиенте вы видите 3 опции для шифрования — без шифрования, SMTPS и STARTTLS, а также 3 возможных порта — 25, 465, 587. Что тут выбрать и для чего — давайте разбираться.

Previous DNS записи для почтовых серверов

Когда вы отправляете кому-то сообщение, ваш почтовый клиент использует протокол ESMTP для передачи этого сообщения, а затем ваш почтовый сервер использует тот же протокол, если ему нужно передать это сообщение на другой сервер. И хотя все говорят и пишут SMTP, речь обычно идёт про ESMTP – тот же самый SMTP, но с набором расширений, таких как авторизация и шифрование. Да, когда-то SMTP не поддерживал даже авторизацию.

Теперь немного про SMTPS. Когда-то интернет был настолько простым, что всё в нем передавалось в открытом виде. Потом появились криптографические протоколы шифрования, тот же самый SSL. И сервисы, которые раньше передавали информацию в открытом виде, начали заворачивать трафик в SSL.

Но сделать это на тех же стандартных портах оказалось непросто – клиент и сервер должны договориться о методе шифрования, а чтобы сервис на одном порту одновременно работал для одних с шифрованием, а для других без – требовало бы изменений в протоколах. И чтобы не усложнять всё, начали лепить отдельные порты для шифрованных соединений – так появился 443 для HTTPS и 465 для SMTPS. Но тут спохватились – выделенных портов мало, количество сервисов растёт, а если еще каждый для своих целей будет использовать по несколько портов с шифрованием и без – беда.

И в итоге решили немного доработать протоколы. В некоторых случаях это не очень получилось, например для HTTP, а в случае с SMTP получился вполне себе годный вариант. Для этого в SMTP добавили расширение STARTTLS. Вообще, расширение STARTTLS используется не только для SMTP, в целом это команда для начала переговоров о шифровании. В отличие от SMTPS, который использует выделенный порт 465 и сразу шифрует соединение, STARTTLS лишь расширение для SMTP, а значит сессия инициируется как обычная SMTP сессия. Почтовые сервера приветствуют друг друга, а потом предлагают начать шифроваться и выбирают доступные криптографические протоколы.

В итоге с появлением STARTTLS из стандартов решили убрать SMTPS на 465 порту как отдельный сервис. Из стандартов убрали, но сервис остался, и до сих пор используется. Насчёт шифрования я еще сделаю отдельную тему, а пока поговорим про STARTTLS.

Ранее я сказал, что при STARTTLS почтовые сервера или клиент/сервер открывают соединение без шифрования, а потом договариваются о шифровании. Для шифрования они используют тот же самый SSL/TLS. Но что, если они не смогут договориться? Получится, они будут общаться в незашифрованном виде? По интернету? А между тем, договариваются они без какого-либо шифрования, тем самым легко обмануть сервер или клиент отсутствием доступных методов шифрования. И в своё время уличили одного из провайдеров в такой атаке. И нафиг тогда такое шифрование нужно, спросите вы. Не всё так безнадёжно. На самом деле, администратор может отключить возможность передачи почты, если не удалось договориться о шифровании, а почтовые клиенты обязаны предупреждать о том, что сервер не поддерживает шифрования.

И так, мы разобрались с тем, что есть SMTP, который работает по 25 порту, есть SMTPS, который работает по 465, но есть еще один порт – 587, который также используется почтовым сервером.

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

Как итог, некоторые интернет провайдеры блокируют любые подключения пользователей к 25 порту.

Между серверами в интернете этот порт открыт, а вот для пользователей сделали отдельный сервис – MSA (message submission agent – агент отправки почты), тем самым отделив подключения пользователей от подключения серверов, которые общаются по прежнему по MTA. Вообще, даже на 25 порту работает MSA, но официальный порт для него – 587. Так что мешает спамерам использовать этот порт? То что на MSA, как правило, обязательна авторизация пользователей. Это не единственная причина существования MSA – так как он работает с почтовыми клиентами, он лучше оптимизирован под работу клиентов – сразу предупреждает о каких-либо ошибках в сообщениях, например, отсутствии доменного адреса получателя.

И напоследок, давайте проследим за процессом отправки почтового сообщения. Для этого используем wireshark, почтовый клиент и gmail аккаунт. Всё начинается со стандартного TCP хэндшейка, после чего запускается SMTP сессия. В рамках сессии почтовый клиент и сервер приветствуют друг друга, после чего почтовый клиент предлагает зашифровать сессию, сервер даёт согласие, после чего происходит обмен ключами и начинается зашифрованная сессия TLSv1.3, после чего в зашифрованном виде клиент авторизуется и передаёт сообщение, которое не видно для перехватчика трафика.

Всё о SSL-сертификатах простыми словами: устройство, типы, выбор

Если вы уже сталкивались с созданием собственного сайта, то наверняка краем уха слышали про сертификат SSL и HTTPS — поэтому в нашем новом посте расскажем, как защитить данные посетителей сайта, чем HTTPS отличается от HTTP, что такое SSL-сертификат и какие виды сертификатов существуют?

Что такое SSL-сертификат

SSL (Secure Sockets Layer — уровень защищённых сокетов) — это протокол шифрования, который позволяет кодировать данные для более безопасного обмена.

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

Благодаря SSL информация, которая передаётся, защищена от посторонних: администратора Wi-Fi сети, провайдера, оператора и других лиц — значит она не может быть перехвачена и использована в мошеннических целях. Кроме того, SSL-сертификат выступает в качестве подтверждения надёжности ресурса и даёт возможность проверить, кто является его настоящим владельцем.

Можно сказать, что SSL-сертификат — это своего рода уникальная цифровая подпись сайта.

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

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

А если на сайт установлен OV или EV сертификат, то при клике на замочек, появятся данные об организации, которой принадлежит сайт.

В таких типах сертификатов во вкладке «Подробнее» вы найдёте следующую информацию:

• доменное имя, на которое оформлен SSL-сертификат;
• юридическое лицо, которое владеет сертификатом;
• физическое местонахождение его владельца (город, страна);
• срок действия сертификата;
• реквизиты компании-поставщика SSL-сертификата.

Разница между HTTP и HTTPS

Как вы уже знаете, каждый вбитый в поисковую строку запрос проходит путь от вас (пользователя) к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP. Аббревиатура расшифровывается как Hypertext Transfer Protocol. И всем он хорош — только данные не шифрует, а значит злоумышленники могут перехватить вашу личную информацию (данные банковских карт, пароли, реквизиты).

Для безопасности данных был внедрён протокол HTTPS — HyperText Transfer Protocol Secure (то есть защищённый протокол HTTP). В этом случае передача данных осуществляется по такому же протоколу, но с криптографическим шифрованием, о чём говорит дополнительная буква «S». HTTPS работает благодаря SSL/TLS-сертификату.

SSL/TLS-сертификат ― это цифровая подпись сайта. С её помощью подтверждается его подлинность.

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

Каким сайтам нужен SSL?

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

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

Какие виды SSL-сертификатов есть и кто их выдаёт?

Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.

Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать. Например, при выборе сертификата Cloudflare учтите, что он выдаётся сразу на 50 сайтов. Тем самым сертификат будет защищать не только ваш домен, но и ещё несколько чужих, что несёт за собой риски безопасности. Также у Cloudflare нет печати доверия. Если говорить о недостатках LetsEncrypt, то сюда можно отнести поддержку далеко не всех браузеров, отсутствие гарантии сохранности данных сайта и печати доверия.

Печать доверия — это особый знак, позволяющий посетителям видеть, что соединение с вашим сайтом и все передаваемые данные надёжно защищены.

Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.

• Самоподписанные. Сертификат подписывается самим сервером. Его может сгенерировать любой пользователь самостоятельно. По сути, он бесполезен, потому что доверять ему будет только компьютер, на котором был сгенерирован такой сертификат. Большинство браузеров при посещении сайта с таким сертификатом выдаст предупреждение, что соединение не защищено.

• Подписанные доверенным центром сертификации (валидные). Речь о тех самых авторитетных УЦ выше. Сертификат корректно отображается во всех браузерах. Данные сертификата проверены и подтверждены в сертифицирующем центре.

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

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

• DV (Domain Validation) — базовый уровень сертификата, который обеспечивает только шифрование данных, но не подтверждает существование организации. Такие бюджетные сертификаты подойдут физическим и юридическим лицам.
• OV (Organization Validation) — обеспечивает не только шифрование данных, но и подтверждает существование организации. Такие сертификаты доступны только для юридических лиц.
• EV (Extended Validation) — это эффективное решение с самым высоким классом защиты, которое активно применяется в онлайн-бизнесе. Для оформления требуется пройти процедуру расширенной проверки, подтвердить законность организации и право собственности на домен.

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

• WildCard — защищает соединение с доменом и всеми его поддоменами.
• SAN — защищает домены по списку, указанному при получении SSL-сертификата.

Какой SSL-сертификат выбрать?

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

Например, если вы просто хотите уберечь пользователей вашего веб-сайта от навязчивых предупреждений браузера о посещении непроверенного сайта, будет достаточно за несколько минут получить простой DV (Domain Validation) сертификат. Если же вы используете свою интернет-площадку для операций, требующих повышенного уровня безопасности данных компании и клиентов — стоит задуматься об EV (Extended Validation) сертификате. А если вы используете не один, а несколько веб-адресов для сайта или сайтов компании — для вас на рынке представлены сертификаты Wildcard и SAN.

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

• насколько SSL совместим с основными браузерами;
• на каком уровне происходит защита данных пользователей;
• насколько масштабная проверка организации проводится;
• есть ли печать доверия.

4 причины установить SSL-сертификат

Безопасность данных

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

Доверие к сайту

Пользователи привыкают, что все крупные проекты используют SSL-сертификаты. Надпись «Защищено» и замочек дают посетителю сайта представление о том, что он и его данные находятся в безопасности.

Поддержка сторонних сервисов

Некоторые платёжные системы (Яндекс.Деньги) и сервисы (Голосовой помощник Google Chrome) работают только с сайтами с HTTPS протоколом. Если специфика вашей работы подразумевает взаимодействие с аналогичными сервисами, рекомендуем вам установить SSL-сертификат.

Фактор ранжирования

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

SSL-сертификат от авторитетного УЦ говорит о надёжной защите пользовательских данных — это не только хороший способ заслужить доверие пользователей и поисковых систем, но и большой вклад в стабильное продвижение и развитие сайта.