Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, опубликовал (https://tools.ietf.org/html/draft-margolis-smtp-sts-00) первый черновой вариант спецификации SMTP Strict Transport Security (SMTP STS), подготовленной экспертной группой из представителей компаний Google, Yahoo, Comcast, Microsoft и LinkedIn. SMTP STS реализует механизм, позволяющий почтовым службам информировать клиента, установившего соединение через незащищённый канал связи, о возможности установки защищённого TLS-соединения, применения различных схем проверки сертификатов и определения политики отклонения сообщений, которые не могут быть доставлены безопасно.
По своей сути SMTP STS близок к протоколу HSTS (https://ru.wikipedia.org/wiki/HSTS) (HTTP Strict Transport Security), который позволяет администратору web-сайта
указать на необходимость обращения только по HTTPS и автоматизировать проброс на HTTPS при изначальном обращении по ссылке на HTTP. Только вместо HTTPS и HTTP, объектами действия SMTP STS являются STARTTLS и SMTP. Отличия SMTP STS от похожего механизма DANE (https://ru.wikipedia.org/wiki/DANE) (DNS-based Authentication of Named Entities) сводятся к тому, что DANE проводит аутентификацию через DNSSEC, в то время как SMTP STS полагается на инфраструктуру открытых ключей с удостоверяющими центрами. Эталонная реализация SMTP STS подготовлена (https://github.com/mrisher/smtp-sts/) для почтового сервера Exim и может быть применена без модификации исходных текстов.
URL: https://news.ycombinator.com/item?id=11320680
Новость: http://www.opennet.me/opennews/art.shtml?num=44079
> Google, Yahoo, Comcast, Microsoft и LinkedIn.собрались главные велосипедостроители и решили замутить очередной костыль
Нет, главные знатоки, как другим жить, с кем говорить и о чем
> Нет, главные знатоки, как другим жить, с кем говорить и о чемА так же каким ДЕ, браузером, плагинами к нему, версией ядра и системой инициализации пользоваться. Только я не понял, к чему тут опеннетчиков упоминать? o_O
Непонятно нихрена. Если у меня постфикс работает только через starttls, накой эта хрень нужна?
The STARTTLS extension to SMTP [@!RFC3207] allows SMTP clients and hosts to establish secure SMTP sessions over TLS. In its current form, however, it fails to provide (a) message confidentiality — because opportunistic STARTTLS is subject to downgrade attacks — and (b) server authenticity — because the trust relationship from email domain to MTA server identity is not cryptographically validated.While such "opportunistic" encryption protocols provide a high barrier against passive man-in-the-middle traffic interception, any attacker who can delete parts of the SMTP session (such as the "250 STARTTLS" response) or who can redirect the entire SMTP session (perhaps by overwriting the resolved MX record of the delivery domain) can perform such a downgrade or interception attack.
Ну и далее по тексту: https://github.com/mrisher/smtp-sts/blob/master/spec.md
примерно понятно, но всё равно похоже на кривой костыль
>>any attacker who can delete parts of the SMTP sessionну пусть человек по середине удаляет 250 STARTTLS - постфикст не примет соединение если стоит smtpd_tls_security_level = encrypt
Ну решишь ты эту задачу одним параметром в конфиге и что?
А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...
> А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...Новый протокол ? да я только рад этому, и давно нуно списать смтп на покой. в место того чтобы толкать эту фигню - лучше бы дейн тлс продвигали бы. днссек поголовно имплементировали бы.
Му-ха-ха :-) Д***л, smtp никто не трогает. Они упорядочили танцы вокруг starttls и всио, мучайсо! :-р
>> Они упорядочили танцы вокруг starttlsа тут по подробонее, что это там упорядочили?
>>Д***л, smtp никто не трогает.
взаимно Д***б
никто не запретит быть шифрованному каналу от тебя до этого типа, а от типа до отправителя - не шифрованному.
smtp_tls_security_level = verifyкакая разница, суть в том, что отправитель должен верефицировать получателя
принимать и отправлять только по тлс - вырезай не вырезай start tls - без установки тлс ничего не приментся и не отправится.
А почту от других пользователей ты не получаешь?
получаю, и старттлс все могут
Для веба, несомненно, актуальнее. Но почему бы и нет.
А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо -- даёт некую гарантию, что один и тот же стандарт будут использовать все вместо кучи вендорных расширений протокола.
К сожалению, никаких гарантий это не дает :(
Ну, уж они-то хотя бы будут следовать, раз сами договорились? :-)
> Ну, уж они-то хотя бы будут следовать, раз сами договорились? :-)Микрософт будет следовать чему-то кроме того, что шепчут ему грибы?
> Для веба, несомненно, актуальнее. Но почему бы и нет.
> А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо --
> даёт некую гарантию, что один и тот же стандарт будут использовать
> все вместо кучи вендорных расширений протокола.Я так понимаю, всё идёт к тому, что без валидного сертификата отправить что либо на @gmail.com и т.п. нельзя будет.
Можно подумать, что получение валидного сертификата сейчас составляет какую-то трудность.
То что тут пытаются что-то стандартизировать не даст ровным счётом ничего. В почтовых серверах полно своих особенностей у всех вендоров.
А как показала история на примере OpenGL даже 1 стандарт не гарантирует того что каждый вендор не будет тянуть одеяло на свою половину.
Хорошо конечно что эти гиганты договариваются, но остальным от этого ни холодно ни жарко.
> В почтовых серверах полно своих особенностей у всех вендоров.
> А как показала история на примере OpenGL даже 1 стандарт не гарантирует
> того что каждый вендор не будет тянуть одеяло на свою половину.Как только с особенного сервера перестанет доходить почта до другого, не особенного, админы со скоростью, превышающей световую, понесутся исправлять неисправленное. Причём помогать им будет пистон полуметровой, как минимум, длины, вставленный в необходимое технологическое отверстие кем-то вроде CTO или CEO.
SMAP / IMAPSMTP и POP3 не нужны
В принципе да (для клиент-серверного общения я бы вообще оставил только IMAP - пусть бы клиент просто клал исходящую почту в специальную Outbox-папку и никаких SMTP ему не надо), но учитывая уровень кривизны и разнообразие реализации того же IMAP в разных клиентах, на практике я до сих пор предпочитаю использовать POP3 там где это уместно.