Почта, которая доходит: все проверки internet.nl и их смысл

РЕЗУЛЬТАТ

Как проверить конфигурацию

internet.nl - бесплатная проверка правительства Нидерландов и группы интернет-организаций. Здесь важны две ее части: сайт и почтовый домен. Каждый тест дает результат "пройден" или "не пройден", и результаты открыты.

Вы можете самостоятельно проверить ave17.com; план работ описывает предполагаемую публикацию результатов с датами.

Стоит сказать и о том, чего результат не означает. Он измеряет конфигурацию, а не поведение: идеальный результат доказывает, что домен трудно подделать и что его почта передается с шифрованием. Он ничего не говорит о том, отвечают ли люди за этим доменом на письма.

КТО ОТПРАВИЛ

SPF, DKIM и DMARC в порядке их применения

Вместе эти три механизма отвечают на один вопрос: действительно ли письмо пришло от этого домена. Их обычно внедряют в неверном порядке, поэтому многие домены имеют все три и все равно допускают подделку.

SPF

Перечисляет машины, которым разрешено отправлять почту от имени домена. Недорого, но само по себе ненадежно: пересылка письма ломает проверку, потому что пересылающего сервера нет в списке.

DKIM

Подписывает само письмо, поэтому подпись сохраняется при пересылке. Мы подписываем двумя ключами, RSA и Ed25519: некоторые получатели еще не понимают второй, а мы предпочитаем не выбирать между ними.

DMARC

Указывает получателю, что делать, если первые две проверки не прошли, и запрашивает отчет об этом. У нас p=reject: отклонить письмо. Более мягкая политика - вежливая просьба, которую большинство отправителей игнорирует.

Рабочий порядок: сначала DKIM, затем SPF, затем DMARC в режиме наблюдения, пока отчеты не станут спокойными, и только потом reject. Немедленный переход к reject заставляет организацию публично обнаружить, какие ее системы незаметно для всех отправляли почту.

КАК ПИСЬМО ДОШЛО

Шифрование, которое нельзя отключить по дороге

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

MTA-STS

Политика по HTTPS: "Всегда используйте TLS с этими именами хостов; если это невозможно, не доставляйте". Мы публикуем ее в режиме enforce, единственном режиме, который действительно действует.

DANE

Сертификат, ожидаемый от получателя, публикуется в DNS и подписывается DNSSEC. Отправляющий сервер проверяет сертификат по домену, а не по списку центров сертификации. Мы публикуем TLSA-записи для submission, submissions, IMAPS и самого почтового обменника.

DNSSEC

Подписи самих DNS-ответов. Без них любая перечисленная запись - утверждение, которое атакующий может переписать при передаче. Поэтому DANE требует DNSSEC, и поэтому каждая наша зона подписана.

MTA-STS и DANE намеренно перекрывают друг друга. Первый проще внедрить, и он доверяет системе веб-сертификатов; второй сложнее и доверяет DNSSEC. С обоими механизмами домен защищен, до какого бы из них ни добрался атакующий.

ВЕБ-ЧАСТЬ

Что требует проверка сайта

Веб-часть той же проверки в основном проверяет ту же идею: соединение нельзя понизить до менее защищенного, а сертификат нельзя подменить.

• IPv6 для сайта и его серверов имен, доступность и тот же контент, что по IPv4
• DNSSEC для зоны, чтобы нельзя было подменить сам адрес
• HTTPS с современными шифрами, HSTS и без пути к менее защищенному соединению
• DANE также для веб-сертификата; это почти нигде не применяется
• Закрытая CAA-политика: только названный нами центр может выдать сертификат домена
• Заголовки безопасности, предотвращающие встраивание страницы в чужую рамку и подмену типа ее содержимого

ДВА ВАЖНЫХ НЮАНСА

Где результат может ввести в заблуждение

Во-первых, DMARC с p=reject для домена, который никогда не отправляет почту, настраивается элементарно. Домен с реальной почтой приходит к этому только после нескольких недель чтения отчетов. Результат один, работа совершенно разная. Если сравниваете поставщиков по этому показателю, спросите, какой из двух случаев у них был.

Во-вторых, DANE требует проверки на принимающей стороне, а большая часть мира ее не выполняет. Публикация защищает при получателях, которые проверяют DANE, и ничего не стоит при остальных. Но она не гарантирует, что любое конкретное письмо прошло с шифрованием. Этого никто не может гарантировать.

И еще один неудобный, но честный факт: ничто из этого не останавливает убедительное письмо с домена, похожего на ваш. Это другая проблема, которую решают люди, а не записи.

ВО ЧТО ЭТО ОБОШЛОСЬ

Честно

День на правильные записи первого домена и около двадцати минут на каждый следующий: к тому времени уже был шаблон. Настоящее время уходит не на конфигурацию, а на две недели чтения DMARC-отчетов до безопасного перехода к reject. Эту часть нельзя купить или ускорить.

Мы управляем этим сами, а не через почтового провайдера, поэтому можем это описать. Если вы предпочитаете иначе, это вполне разумно, а перечисленные записи все равно стоит запросить у своего провайдера.