Ssl или starttls что лучше
Ssl или starttls что лучше
При подключении к почтовому серверу по протоколам IMAP / POP3 клиентская программа запрашивает протокол по которому необходимо устанавливать соединение — среди опций подключения: SSL TLS starttls.
SSL TLS Starttls разница при подключении к почтовому серверу
Что означают аббревиатуры:
SSL (Secure Sockets Layer) — метод шифрования данных и протокол прикладного уровня модели OSI. Для шифирования используются SSL сертификат и приватный ключ. Существуют версии 1.0, 2.0, 3.0. На основе последней разработан протокол TLS
TLS (Transport Layer Security) — следующее поколение SSL, по сути механизм не поменялся, изменились некоторые криптографические алгоритмы. Версии TLS: 1.0, 1.1, 1.2, 1.3. С 2014 года фактически используется TLS, SSL не применяется как недостаточно защищенный.
Для шифрования может использоваться SSL сертификат, специально для этого выпущенный или сгенерированный на сервере. Файлы, относящиеся к сертификату, размещаются на сервере и подключаются в конфигурации почтового сервера.
StartTLS — расширение протокола обмена текстовой информацией в открытом виде. Т.е. основным способом передачи является plain text. StartTLS при установлении сессии опрашивает другую сторону и выясняет поддерживает ли она шифрование. Если поддержка SSL/TLS присутствует, и также она есть на сервере который пытается установить соединение — данные будут шифроваться.
Если поддержки SSL/TLS нет информационный обмен будет происходить в виде открытого текста, что очень небезопасно. Если данные не шифруются — их можно записать при помощи снифера и увидеть просматривая дамп трафика.
Передавая информацию в нешифрованном виде StartTLS никаким образом не предупредит пользователя. Таким образом механизм дает иллюзию того, что происходит шифрование, фактически его часто не происходит.
Использования StartTLS следует избегать если это возможно.
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 порту. Наконец, так как обмен сертификатами и договорённость о параметрах шифрования происходят ещё до начала работы нашего прикладного протокола, некоторые возможности этого протокола перестают работать.
В попытке обойти эти трудности решили пойти другим путём. Расширить протоколы, чтобы можно было начать сеанс связи без шифрования, а потом переключиться на шифрование, если и клиент, и сервер его поддерживают. Это красиво называется Opportunistic TLS. А команда, включающая шифрование, называется STARTTLS.
Сначала клиент подключается к серверу как обычно, без шифрования. В ходе начала переговоров, по правилам данного протокола, клиент и сервер выясняют свои возможности. Если и клиент, и сервер могут и хотят шифроваться, клиент посылает команду STARTTLS. После этого начинается обычная для TLS процедура обмена сертификатами и согласования ключей. Если она завершается успешно, последующие команды в сеансе между клиентом и сервером уже идут по зашифрованному каналу.
В OpenSSL есть встроенный клиент, который умеет делать STARTTLS. Например для SMTP.
Использовать один и тот же порт для незашифрованных и для шифрованных соединений оказалось так удобно, что отдельные порты для SSL быстренько объявили устаревшими. Так что теперь стандартный и кошерный способ делать TLS — это STARTTLS.
Может показаться, что это небезопасно, ведь мы начинаем сессию без шифрования. Но шифрование включается сразу же, как обе стороны решат, что оно им нужно. Открытым текстом видны только общие поддерживаемые возможности клиента и сервера. И клиент, и сервер можно настроить так, чтобы они требовали использование команды STARTTLS. В этом случае требуется, чтобы STARTTLS был одной из первых команд в сессии, до передачи важных данных. Иначе дальнейшая работа блокируется согласно протоколу.
А вот с HTTPS как-то не сложилось. Возможно, потому, что в HTTP не предусмотрено длительных сессий между клиентом и сервером, STARTTLS просто некуда воткнуть. Впрочем, подобная попытка предпринималась в RFC 2817, но не прижилась. Там предлагалось делать Upgrade протокола до TLS, примерно как сейчас делается для WebSocket или для одновременной поддержки HTTP и HTTP/2.
OpenSSLный клиент можно и для SSL wrapper использовать. (Заголовок Host для запроса в HTTP/1.1 является обязательным)
Тем не менее, для HTTP/2 есть забавный черновик Opportunistic Security for HTTP. Чтобы для http URL работал TLS, если клиент с сервером договорятся. Вместо одной команды STARTTLS в этом черновике предполагается обмен JSONами.
Является ли STARTTLS менее безопасным, чем TLS /SSL?
В Thunderbird (и я предполагаю, что у многих других клиентов тоже) у меня есть выбор между «SSL /TLS» и «STARTTLS».
Или другими словами:
Является ли STARTTLS менее безопасным, чем SSL /TLS, потому что он может вернуться к открытому тексту без уведомления?
7 ответов
Ответ на основе STARTTLS RFC для SMTP ( RFC 3207 ):
STARTTLS менее безопасен, чем TLS.
Вместо того, чтобы говорить сам, я позволю RFC говорить сам за себя, с четырьмя соответствующими битами, выделенными в BOLD :
Нет никакой разницы в безопасности между двумя параметрами.
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 за пределами этого типа ошибки конфигурации.
Вкратце, в этой заметке теперь рекомендуется:
В какой-то степени ответ зависит от того, что вы подразумеваете под «безопасным».
Во-первых, ваше резюме не совсем отражает разницу между SSL /TLS и STARTTLS.
Если клиент настроен на требование TLS, два подхода более или менее одинаково безопасны. Но есть некоторые тонкости о том, как STARTTLS необходимо использовать, чтобы сделать его безопасным, и для реализации 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-порту также терпит неудачу. Вам нужно знать, что он будет делать, и выбрать безопасные настройки. И программы должны использовать безопасные значения по умолчанию.
Про порты и шифрование в почтовых серверах
При настройке сервера исходящей почты на почтовом клиенте вы видите 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, после чего в зашифрованном виде клиент авторизуется и передаёт сообщение, которое не видно для перехватчика трафика.
STARTTLS менее безопасен, чем TLS / SSL?
В Thunderbird (и я полагаю, во многих других клиентах) у меня есть возможность выбора между «SSL / TLS» и «STARTTLS».
Или другими словами:
Является ли STARTTLS менее безопасным, чем SSL / TLS, потому что он может перейти на обычный текст без уведомления меня?
Ответ, основанный на RFC STARTTLS для SMTP ( RFC 3207 ):
STARTTLS менее безопасен, чем TLS.
Вместо того, чтобы говорить самому, я позволю RFC говорить за себя, с четырьмя соответствующими битами, выделенными жирным шрифтом :
Как видите, сам RFC утверждает (не очень четко, но достаточно четко), что НИЧЕГО не требуется клиентам устанавливать безопасное соединение и информировать пользователей в случае сбоя безопасного соединения. Это явно дает клиентам возможность устанавливать молчащие текстовые соединения.
Нет никакой разницы в безопасности между этими двумя вариантами.
SSL / TLS сначала открывает соединение SSL / TLS, а затем начинает транзакцию SMTP. Это должно происходить на порте, на котором еще не запущен SMTP-сервер без SSL / TLS; из-за природы протоколов невозможно настроить один порт для обработки как простого текста, так и зашифрованных соединений.
STARTTLS запускает SMTP-транзакцию и ищет поддержку на другом конце для TLS в ответе на EHLO. Если клиент видит STARTTLS в списке поддерживаемых команд, он отправляет STARTTLS и начинает согласование для шифрования. Все это может (и обычно происходит) происходить на стандартном SMTP-порту 25, частично для обратной совместимости, но также и для обеспечения возможности произвольного шифрования между конечными точками, которые обе поддерживают его, но не обязательно требуют его.
Обычно SSL / TLS используется только между конечными клиентами и серверами. STARTTLS чаще используется между MTA для защиты межсерверного транспорта.
С учетом этих двух реализаций STARTTLS может быть истолкован как небезопасный, если пользователь или администратор предполагают, что соединение зашифровано, но на самом деле не настроили его для шифрования. Однако используемое шифрование точно такое же, как и для SSL / TLS, и, следовательно, не более или менее уязвимо для атаки «человек посередине» за пределами этого типа ошибки конфигурации.
Вкратце, эта памятка теперь рекомендует, чтобы:
Ответ в некоторой степени зависит от того, что вы подразумеваете под «безопасным».
Во-первых, ваше резюме не совсем отражает разницу между SSL / TLS и STARTTLS.
Если клиент настроен на использование TLS, оба подхода более или менее одинаково безопасны. Но есть некоторые тонкости в том, как STARTTLS должен использоваться, чтобы сделать его безопасным, и для реализации STARTTLS немного сложнее понять эти детали правильно.
Поэтому простой ответ: если вы подключаетесь к серверу, который, как вы уже знаете, поддерживает TLS (как и в случае отправки или чтения электронной почты), вам следует использовать SSL / TLS. Если соединение атаковано, попытка соединения не удастся, но ваш пароль и адрес электронной почты не будут скомпрометированы.
С другой стороны, если вы подключаетесь к какой-либо службе, которая не знает, поддерживает ли она TLS, STARTTLS может быть немного лучше.
Когда был изобретен STARTTLS, «пассивные» атаки только для прослушивания были очень распространены, «активные» атаки, при которых злоумышленник вводил трафик, пытаясь снизить уровень безопасности, были менее распространенными. За 20 лет или около того, активные атаки стали более выполнимыми и более распространенными.
Например, если вы пытаетесь использовать ноутбук в аэропорту или каком-либо другом общественном месте и пытаетесь читать почту через предоставленный там wifi, вы не представляете, что эта сеть wifi делает с вашим трафиком. В сетях Wi-Fi очень распространено направление определенных видов трафика к «прокси», которые размещаются между вашими клиентскими приложениями и серверами, с которыми они пытаются общаться. Эти прокси-серверы тривиально отключают STARTTLS и «пробуют один порт, а затем другой», пытаясь заставить вашего клиента переключиться на открытый текст. Да, это происходит, и это только один пример того, как ваш трафик может отслеживаться сетью. И такие атаки не ограничиваются трехбуквенными государственными агентствами,
Да, вы правильно поняли основы. И да, STARTTLS определенно менее безопасен. Он может не только вернуться к незашифрованному тексту без уведомления, но и потому, что подвергается атакам типа «человек посередине». Поскольку соединение начинается в открытом виде, MitM может исключить команду STARTTLS и предотвратить шифрование. Однако я считаю, что почтовые серверы могут указывать, что передача происходит только после настройки зашифрованного туннеля. Так что вы можете обойти это.
Так почему же такая вещь существует? По причинам совместимости. Если какая-либо из сторон не поддерживает шифрование, вы все равно можете захотеть, чтобы соединение было установлено правильно.