Google и Microsoft создают электронную почту, которую нельзя перехватить

Новое расширение для SMTP Группа независимых исследователей совместно с пятью компаниями — Google, Microsoft, Yahoo, Comcast и LinkedIn — предложили стандартизировать новое расширение для протокола SMTP, которое сделает электронную почту более защищенной от перехвата. Свое предложение они направили в организацию Internet Engineering Task Force (IETF). Появление STARTTLS Разработанный в 1982 г. протокол для отправки электронной почты SMTP не поддерживает шифрование. Он был изобретен тогда, когда интернет только развивался, и необходимости в защите переписки между всего лишь несколькими тысячами подключенных к сети компьютеров не было. В 2002 г. для SMTP было разработано расширение STARTTLS, позволившее отправлять письма в зашифрованном виде. После того как в 2013 г. Эдвард Сноуден (Edward Snowden) рассказал о приемах Агенства национальной безопасности США, шифрование набрало популярность. В 2014 г. соцсеть Facebook, отправляющая миллиарды почтовых уведомлений в день, выяснила, что 58% этих уведомлений проходят по защищенным каналам. К августу того же года эта цифра возросла до 95%. Недостаток STARTTLS Расширение STARTTLS используется и по сей день, но оно не гарантирует защиту данных, так как содержит в себе ряд изъянов, позволяющих хакерам успешно выполнить свою работу. http://filearchive.cnews.ru/img/cnews/2016/03/22/inbox500.jpg"> [b]Предложено новое расширение для защиты электронной почты[/b] Используя недостатки расширения, злоумышленник может фальсифицировать почтовый сервер и убедить приложение на ПК или другой почтовый сервер отправить сообщение в виде простого текста. Сделать это можно путем принудительного отказа от шифрования (в штатном режиме такая необходимость может возникнуть тогда, когда принимающий сервер не поддерживает шифрование) либо путем использования поддельного сертификата. [b]Функция STS[/b] Поэтому авторы инициативы предложили создать расширение STS (Strict Transport Security), которое обеспечит надежную проверку подлинности участников соединения. В теории STS аналогично расширению HSTS для HTTPS. Как и HSTS, оно должно обеспечить зашифрованный обмен служебными сообщениями между сторонами. STS будет гарантировать безопасное соединение и определит поведение серверов на тот случай, когда подлинность одного из них проверить не удастся. Что будет предприниматься в этом случае, не уточняется. Правила STS будут задаваться посредством специальных DNS-записей, которые будут добавляться к домену провайдера почтового сервиса. Предполагается, что это позволит защитить пользователей электронной почты от атак вида «человек посередине», когда злоумышленник имеет возможность фальсифицировать второго участника соединения и получить его данные. [b]Статус обсуждения[/b] Пока расширение STS представлено в виде черновика стандарта со сроком действия до 19 сентября 2016 г. По мере возникновения интереса, работа над стандартом будет продолжена. Черновики в IETF не имеют никакого официального статуса и могут быть удалены в любой момент. Официальный статус появляется только после того, как за разработку берется рабочая группа либо когда документ приобретает внутренний статус Requests for Comments.[img]http://filearchive.cnews.ru/img/cnews/2016/03/22/inbox500.jpg">
Предложено новое расширение для защиты электронной почты Используя недостатки расширения, злоумышленник может фальсифицировать почтовый сервер и убедить приложение на ПК или другой почтовый сервер отправить сообщение в виде простого текста. Сделать это можно путем принудительного отказа от шифрования (в штатном режиме такая необходимость может возникнуть тогда, когда принимающий сервер не поддерживает шифрование) либо путем использования поддельного сертификата. Функция STS Поэтому авторы инициативы предложили создать расширение STS (Strict Transport Security), которое обеспечит надежную проверку подлинности участников соединения. В теории STS аналогично расширению HSTS для HTTPS. Как и HSTS, оно должно обеспечить зашифрованный обмен служебными сообщениями между сторонами. STS будет гарантировать безопасное соединение и определит поведение серверов на тот случай, когда подлинность одного из них проверить не удастся. Что будет предприниматься в этом случае, не уточняется. Правила STS будут задаваться посредством специальных DNS-записей, которые будут добавляться к домену провайдера почтового сервиса.
Предполагается, что это позволит защитить пользователей электронной почты от атак вида «человек посередине», когда злоумышленник имеет возможность фальсифицировать второго участника соединения и получить его данные.
Статус обсуждения Пока расширение STS представлено в виде черновика стандарта со сроком действия до 19 сентября 2016 г. По мере возникновения интереса, работа над стандартом будет продолжена. Черновики в IETF не имеют никакого официального статуса и могут быть удалены в любой момент. Официальный статус появляется только после того, как за разработку берется рабочая группа либо когда документ приобретает внутренний статус Requests for Comments.