In a nutshell: MTA-STS is a way to protect emails against interception (man-in-the-middle aka MitM attacks) between email servers. It partially resolves architectural issues in email protocols and is described in a recent RFC 8461 standard.

Если кратко, то MTA-STS — это способ дополнительно защитить письма от перехвата (т.е. атак злоумышленник-в-середине aka MitM) при передаче между почтовыми серверами. Он частично решает унаследованные архитектурные проблемы протоколов электронной почты и описан в относительно свежем стандарте RFC 8461. Почта Mail.ru — первая крупная почтовая служба в Рунете, реализующая данный стандарт. А более подробно рассказывается уже под катом.

Год назад, 21 марта 2019, в баг баунти программу Mail.ru на HackerOne пришел очень хороший багрепорт от maxarr. При внедрении нулевого байта (ASCII 0) в POST-параметр одного из API-запросов веб-почты, который возвращал HTTP-редирект, в данных редиректа виднелись куски неинициализированной памяти, в которых чаще всего раскрывались фрагменты из GET-параметров и заголовков других запросов к тому же серверу.

Вечером 10 марта служба поддержки Mail.ru начала получать жалобы от пользователей на невозможность подключения к IMAP/SMTP серверам Mail.ru через почтовые программы. При этом часть коннектов не проходила, а часть показывают ошибку сертификата. Ошибка вызвана тем, что «сервер» отдает самоподписаный сертификат TLS.

SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.

Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.

TL;DR — рекомендации в конце.

A Thief on the Run by Manweri

Привет, Хабр! В этом посте мы снова поговорим о проблеме подделки отправителя (или так называемом спуфинге). В последнее время такие случаи очень участились: подделывается все: письма со счетами за ЖКХ, из налоговой инспекции, банков и так далее. Решить эту проблему помогает настройка строгой DMARC-политики. Мы как почтовая служба проверяем все приходящие к нам письма на DMARC начиная с февраля 2013 года. Мы были первым в рунете почтовым сервисом, поддержавшим стандарты DMARC. Однако чтобы минимизировать число поддельных писем, этого, к сожалению, недостаточно. Главное, чтобы строгий DMARC был поддержан на стороне отправителя. Вот почему мы не устаем качать эту тему, ведем активную разъяснительную работу и всячески призываем всех включать у себя строгий DMARC.

Позитивные сдвиги уже есть: с каждым месяцем мы видим прирост числа корпоративных отправителей, прописавших DMARC, на десятки процентов. Однако безусловно, еще есть над чем работать. Практика показывает, что IT-культура находится на очень разном уровне. Кто-то слышал краем уха про DMARC, но пока не собирается его внедрять. Есть и такие, для кого факт, что в транспортных протоколах электронной почты отсутствует какая-либо проверка и защита адреса отправителя, до сих пор является настоящим откровением. Кроме того, поддержка DMARC — задача непростая. Только на первый взгляд кажется, что достаточно опубликовать запись в DNS, и не требуется никакого дополнительного софта или технических средств (подробнее в нашей статье DMARC: защитите вашу рассылку от подделок). На практике в крупной компании с многочисленными потоками электронной почты и развесистой структурой почтовых доменов все гораздо сложнее. И есть моменты, которые следует предусмотреть и продумать заранее. Именно для таких сложных случаев мы написали эту статью, постаравшись собрать в ней все нюансы.

На днях мы анонсировали включение строгой DMARC-политики на всех доменах, принадлежащих Почте Mail.Ru. На некоторых доменах, включая bk.ru и mail.ua, политика p=reject включена уже сейчас. В этой статье мы хотим пояснить некоторые технические детали такого включения и дать рекомендации владельцам сервисов, почтовых серверов и списков рассылки.

«Даже если вы получите какое-нибудь письмо, вы не сможете его прочитать»
(Марк Твен)

Мы уже писали о том, как правильно делать рассылки, улучшать их качество и эффективность. Приводили метрики, на основе которых строится репутация отправителя. Рассказывали об интерфейсе Постмастер Mail.Ru, с помощью которого их можно отслеживать. Многие компании, как находящиеся в начале своего развития, так и довольно крупные, пренебрегают этими правилами, в результате чего начинаются проблемы с доставляемостью писем, разбирательства со службой техподдержки и т.п. Но мы надеемся что вы не принадлежите к их числу.

Итак, ваш проект набирает популярность и нравится пользователям, вы собираетесь оставаться с ними на связи. Вы ознакомились с административными требованиями (о которых мы писали ранее) и собираетесь ответственно и без спама организовать рассылку для тех пользователей, которые готовы ее получать. А может быть, вы просто собираетесь настроить корпоративную почту. Поднимаете из дистрибутива почтовый сервер, пишете скрипт, запускаете и… 70% получателей письмо не доставлено, у 15% оно попало в папку «Спам», а остальные не могут прочитать то, что в нем написано. О том, что делать, чтобы этого не случилось, я попробую рассказать в этой статье.

Тайминг-атаки являются известным слабым местом сети Tor и неоднократно обсуждались, в том числе на Хабре, где можно найти порядка 10 статей, так или иначе затрагивающих эту тему. Зачем нужна еще одна? Существует достаточно распространенное заблуждение, что подобные атаки всегда требуют статистического анализа и достаточно сложны в реализации. Ранее опубликованные статьи относятся именно к такому классу атак. Мы рассмотрим вполне реалистичный сценарий, в котором достаточно единственного запроса для деанонимизации пользователя сети.

Поскольку вопрос возможности деанонимизации пользователей Tor в очередной раз активно обсуждается в рунете, я публикую «печатную» версию фрагмента своей презентации с PHDays 2014. Приведенная ниже атака не специфична для Tor и может быть использована против любых low latency средств сокрытия источника трафика – VPN, цепочки прокси и даже их комбинации.

Mail.Ru — огромный портал, существующий более 15-ти лет. За это время мы прошли путь от небольшого веб-проекта до самого посещаемого сайта рунета. В состав портала входит огромное количество сервисов, у каждого из которых своя судьба, и над каждым из которых работает отдельная команда. Разработчикам пришлось как следует потрудиться, чтобы на всех проектах — и новых, и старых, и тех, которые присоединились к порталу по мере его развития, — использовалась единая система авторизации. А через много лет перед нами встала фактически обратная задача: разделить пользовательские сессии. О том, зачем мы это делали, какие трудности нас ожидали и как мы их обошли, я расскажу в этом посте.

21 апреля совместно с Hacker One мы запустили программу поиска уязвимостей. 20 мая завершился конкурс, ставший первым шагом этой программы. Сегодня мы хотим рассказать, как мы укрепляли нашу оборону, готовясь к конкурсу, как исследователи искали в ней бреши и что они помогли нам найти.

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

Вторая цель — рассказать о том, как защитить ящик. Мы пройдемся по базовым моментам и напомним те пункты в «плане безопасности», о которых редко задумываются. Может быть, сведения из этой статьи пригодятся вам, а возможно — вашему беспечному другу, родителям или коллеге. Возможно, нам даже удастся сделать так, чтобы звонков «У меня, кажется, ящик взломали, ты же программист, сделай что-нибудь!!!11» стало чуть меньше.