The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Опубликован первый черновик стандарта Strict Transport Security для SMTP

21.03.2016 14:34

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, опубликовал первый черновой вариант спецификации SMTP Strict Transport Security (SMTP STS), подготовленной экспертной группой из представителей компаний Google, Yahoo, Comcast, Microsoft и LinkedIn. SMTP STS реализует механизм, позволяющий почтовым службам информировать клиента, установившего соединение через незащищённый канал связи, о возможности установки защищённого TLS-соединения и применяемых схемах проверки сертификатов, а также предоставления верифицированной привязки домена к почтовому серверу и определения политики отклонения сообщений, которые не могут быть доставлены безопасно.

По своей сути SMTP STS близок к протоколу HSTS (HTTP Strict Transport Security), который позволяет администратору web-сайта указать на необходимость обращения только по HTTPS и автоматизировать проброс на HTTPS при изначальном обращении по ссылке на HTTP. Только вместо HTTPS и HTTP, объектами действия SMTP STS являются STARTTLS и SMTP. Отличия SMTP STS от похожего механизма DANE (DNS-based Authentication of Named Entities) сводятся к тому, что DANE проводит аутентификацию через DNSSEC, в то время как SMTP STS полагается на инфраструктуру открытых ключей с удостоверяющими центрами. Эталонная реализация SMTP STS подготовлена для почтового сервера Exim и может быть применена без модификации исходных текстов.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Релиз почтового сервера Postfix 2.11.0 с поддержкой DANE
  3. OpenNews: Выпуск почтового сервера Exim 4.85 с поддержкой DANE
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/44079-mail
Ключевые слова: mail, smtp, tls
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (22) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 14:46, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Google, Yahoo, Comcast, Microsoft и LinkedIn.

    собрались главные велосипедостроители и решили замутить очередной костыль

     
     
  • 2.5, Аноним (-), 15:50, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, главные знатоки, как другим жить, с кем говорить и о чем
     
     
  • 3.6, Нимано (?), 16:10, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Нет, главные знатоки, как другим жить, с кем говорить и о чем

    А так же каким ДЕ, браузером, плагинами к нему, версией ядра и системой инициализации пользоваться. Только я не понял, к чему тут опеннетчиков упоминать? o_O


     

  • 1.2, Аноним (-), 15:04, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Непонятно нихрена. Если у меня постфикс работает только через starttls, накой эта хрень нужна?
     
     
  • 2.3, Moomintroll (ok), 15:15, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    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

     
     
  • 3.4, Аноним (-), 15:26, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    примерно понятно, но всё равно похоже на кривой костыль
     
  • 3.8, Sw00p aka Jerom (?), 17:05, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>any attacker who can delete parts of the SMTP session

    ну пусть человек по середине удаляет 250 STARTTLS - постфикст не примет соединение если стоит smtpd_tls_security_level = encrypt

     
     
  • 4.14, None (??), 20:58, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну решишь ты эту задачу одним параметром в конфиге и что?
    А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...
     
     
  • 5.19, Sw00p aka Jerom (?), 17:49, 22/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А тут - новый протокол, комитеты, заседания, фуршеты, такие бюджеты корпоративные осваиваются...

    Новый протокол ? да я только рад этому, и давно нуно списать смтп на покой. в место того чтобы толкать эту фигню - лучше бы дейн тлс продвигали бы. днссек поголовно имплементировали бы.



     
     
  • 6.21, . (?), 05:59, 23/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Му-ха-ха :-) Д***л, smtp никто не трогает. Они упорядочили танцы вокруг starttls и всио, мучайсо! :-р
     
     
  • 7.22, Sw00p aka Jerom (?), 15:30, 23/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Они упорядочили танцы вокруг starttls

    а тут по подробонее, что это там упорядочили?

    >>Д***л, smtp никто не трогает.

    взаимно Д***б

     
  • 4.17, Аноним (-), 08:28, 22/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    никто не запретит быть шифрованному каналу от тебя до этого типа, а от типа до отправителя - не шифрованному.
     
     
  • 5.18, Sw00p aka Jerom (?), 17:47, 22/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    smtp_tls_security_level = verify

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

    принимать и отправлять только по тлс - вырезай не вырезай start tls - без установки тлс ничего не приментся и не отправится.

     
  • 2.10, Admino (ok), 17:32, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А почту от других пользователей ты не получаешь?
     
     
  • 3.12, Аноним (-), 17:57, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    получаю, и старттлс все могут
     

  • 1.7, Sailfish (ok), 16:55, 21/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Для веба, несомненно, актуальнее. Но почему бы и нет.
    А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо -- даёт некую гарантию, что один и тот же стандарт будут использовать все вместо кучи вендорных расширений протокола.
     
     
  • 2.9, dr Equivalent (ok), 17:30, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, никаких гарантий это не дает :(
     
     
  • 3.11, Sailfish (ok), 17:42, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, уж они-то хотя бы будут следовать, раз сами договорились? :-)
     
     
  • 4.13, Аноним (-), 18:01, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Ну, уж они-то хотя бы будут следовать, раз сами договорились? :-)

    Микрософт будет следовать чему-то кроме того, что шепчут ему грибы?

     
  • 2.15, None (??), 21:04, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Для веба, несомненно, актуальнее. Но почему бы и нет.
    > А то, что нелюбимые вами корпорации присутствуют, то это, наоборот, хорошо --
    > даёт некую гарантию, что один и тот же стандарт будут использовать
    > все вместо кучи вендорных расширений протокола.

    Я так понимаю, всё идёт к тому, что без валидного сертификата отправить что либо на @gmail.com и т.п. нельзя будет.

     
     
  • 3.24, scorry (ok), 12:27, 24/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать, что получение валидного сертификата сейчас составляет какую-то трудность.
     
  • 2.16, Ан (??), 21:30, 21/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    То что тут пытаются что-то стандартизировать не даст ровным счётом ничего. В почтовых серверах полно своих особенностей у всех вендоров.
    А как показала история на примере OpenGL даже 1 стандарт не гарантирует того что каждый вендор не будет тянуть одеяло на свою половину.
    Хорошо конечно что эти гиганты договариваются, но остальным от этого ни холодно ни жарко.
     
     
  • 3.25, scorry (ok), 12:30, 24/03/2016 [^] [^^] [^^^] [ответить]  
  • +/

    > В почтовых серверах полно своих особенностей у всех вендоров.
    > А как показала история на примере OpenGL даже 1 стандарт не гарантирует
    > того что каждый вендор не будет тянуть одеяло на свою половину.

    Как только с особенного сервера перестанет доходить почта до другого, не особенного, админы со скоростью, превышающей световую, понесутся исправлять неисправленное. Причём помогать им будет пистон полуметровой, как минимум, длины, вставленный в необходимое технологическое отверстие кем-то вроде CTO или CEO.

     

  • 1.20, Аноним (-), 00:36, 23/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    SMAP / IMAP

    SMTP и  POP3 не нужны

     
     
  • 2.26, Онаним (?), 20:18, 25/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В принципе да (для клиент-серверного общения я бы вообще оставил только IMAP - пусть бы клиент просто клал исходящую почту в специальную Outbox-папку и никаких SMTP ему не надо), но учитывая уровень кривизны и разнообразие реализации того же IMAP в разных клиентах, на практике я до сих пор предпочитаю использовать POP3 там где это уместно.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру