Comments 22
Чтобы добавить безопасности (TLS) надо сделать потенциальную дыру (web-сервер). Почему нельзя было как с DKIM и SPF сделать анонсирование целиком в DNS?
The primary motivation of MTA-STS is to provide a mechanism for
domains to ensure transport security even when deploying DNSSEC is
undesirable or impractical.
Потому что DNS-ответы не защищены и могут быть перехвачены так же, как сами соединения — такой стандарт ничего бы не добавил в отношении безопасности.
Так все равно же есть TXT-запись. И запрос также можно перехватить и подменить. Как минимум можно «выключить» нужному серверу шифрование.
В чем тогда профит лишнего сервиса?
В чем тогда профит лишнего сервиса?
По стандарту отсутствие TXT-записи при наличии валидной закэшированной политики не является достаточным основанием, чтобы выключить шифрование. Моя реализация это отражает. Кэширование политики пролонгируется каждый раз, когда получена TXT-запись с той же версией политики.
Действительно, если атакующий предотвратит первоначальное получение политики, либо будет срывать обновление политики вплоть до истечения срока действия политики, то ему удастся осуществить даунгрэйд.
По этому поводу написано следующее:
То есть с первоначальным обнаружением политики вопрос никак не решаем в рамках стандарта. Однако, если домен-получатель использует DNSSEC, а отправитель использует DNSSEC-совместимый резолвер, то и такой проблемы не будет — не важно, с DANE или с MTA-STS.
Действительно, если атакующий предотвратит первоначальное получение политики, либо будет срывать обновление политики вплоть до истечения срока действия политики, то ему удастся осуществить даунгрэйд.
По этому поводу написано следующее:
- Желательно выбирать как можно большее время кэширования политики max_age.
- Нужно оповещать администраторов о срывах обновления политики при наличии действующей политики.
- DANE обладает сопротивляемостью к таким атакам.
То есть с первоначальным обнаружением политики вопрос никак не решаем в рамках стандарта. Однако, если домен-получатель использует DNSSEC, а отправитель использует DNSSEC-совместимый резолвер, то и такой проблемы не будет — не важно, с DANE или с MTA-STS.
Т.е. без использования dnssec нет гарантии работоспособности mta-sts. А при использовании dnssec данные из него будут достоверными и можно в нем всю информацию хранить. И мы приходим к изначальному вопросу — так зачем в этой схеме лишний веб-сервер? =)
Затем, что без него можно подделать все ответы, а с ним можно подделать только отрицание наличия политики и только тогда, когда у отправителя нет никакой политики в кэше. Это позволяет трактовать отсутствие подлинной политики после «первого» получения как проблему. Схема с одной DNS-записью этого не позволяет, так как не различает подлинность какого бы то ни было ответа.
P.S. Всё сказанное относится к ситуации, в которой отсутствует DNSSEC, для которой стандарт и разработан.
P.S. Всё сказанное относится к ситуации, в которой отсутствует DNSSEC, для которой стандарт и разработан.
Можно еще подменить веб-сервер. И ваш сервер по окончании кэша втянет в себя некую новую политику =). Все та же TXT-запись на DNS-сервере, которому доверять нельзя =).
Получается, что по факту доверять mta-sts нельзя, пока мы все не перелезли на dnssec. А если dnssec доверять можно, то зачем нам веб-сервер? =).
Хотя тут вопрос поинтереснее — зачем нам такой mta-sts и есть ли смысл ради него поднимать дополнительный потенциально уязвимый сервис? Даже два. Некая служба на питоне (можно конечно проверить код, но кто ж это делает в реальности? =) ) и веб-сервер.
Получается, что по факту доверять mta-sts нельзя, пока мы все не перелезли на dnssec. А если dnssec доверять можно, то зачем нам веб-сервер? =).
Хотя тут вопрос поинтереснее — зачем нам такой mta-sts и есть ли смысл ради него поднимать дополнительный потенциально уязвимый сервис? Даже два. Некая служба на питоне (можно конечно проверить код, но кто ж это делает в реальности? =) ) и веб-сервер.
Можно еще подменить веб-сервер.
Вот с этого места поподробнее, пожалуйста.
Раз мы можем редактировать ответы DNS-сервера, то почему бы не подменить А-запись для mta-sts.example.com? Там будет файл с нашей политикой.
Подмена A-записи и любой другой перехват соединения не дают возможности обмануть HTTPS-клиента и выдать себя за другой HTTPS-сервер. Для этого необходимо обладать валидным сертификатом и приватным ключом от него. Советую ознакомиться с тем, как работает HTTPS и TLS.
Это вопрос из другой плоскости. Рассуждения из серии: стоит ли делать прививки, если есть вероятность, что шприц грязный. Каждый отвечает на этот вопрос по-своему, однако к стандарту в этом смысле претензий нет: он предписывает забирать данные по простому и широкораспространённому протоколу, который уже десятилетия имеет зрелые реализации.
Что же касается моего демона — по умолчанию он недоступен снаружи, так как занимает сокет на loopback-адресе 127.0.0.1. Присоединиться к этому порту снаружи не даст система — даже файрвол не нужен. Тот факт, что он написан на питоне в смысле безопасности даже плюс, так как это избавляет от массы проблем с нативными языками: переполнения буфера, ошибки при работе с указателями и так далее.
По поводу того, кто проверяет код. Например, я. На хабре я уже публиковал статью про анализ исходника, который вызвал у меня сомнения. Была и моя статья даже про анализ бинарного кода с целью снятия ограничений. Так что это не какой-то космос.
Хотя тут вопрос поинтереснее — зачем нам такой mta-sts и есть ли смысл ради него поднимать дополнительный потенциально уязвимый сервис? Даже два.
Это вопрос из другой плоскости. Рассуждения из серии: стоит ли делать прививки, если есть вероятность, что шприц грязный. Каждый отвечает на этот вопрос по-своему, однако к стандарту в этом смысле претензий нет: он предписывает забирать данные по простому и широкораспространённому протоколу, который уже десятилетия имеет зрелые реализации.
Что же касается моего демона — по умолчанию он недоступен снаружи, так как занимает сокет на loopback-адресе 127.0.0.1. Присоединиться к этому порту снаружи не даст система — даже файрвол не нужен. Тот факт, что он написан на питоне в смысле безопасности даже плюс, так как это избавляет от массы проблем с нативными языками: переполнения буфера, ошибки при работе с указателями и так далее.
По поводу того, кто проверяет код. Например, я. На хабре я уже публиковал статью про анализ исходника, который вызвал у меня сомнения. Была и моя статья даже про анализ бинарного кода с целью снятия ограничений. Так что это не какой-то космос.
Так мы же подменяем ответы DNS-сервера =). Letsencrypt запросто сгенерит нам новый валидный сертификат ).
Учите матчасть. Если вы вклинитесь в чьё-то интернет-подключение, то подмените DNS только для него, не для всего интернета.
Т.е. вы считаете что только такой вид атаки возможен и на основе этого считаете меня неграмотным? =). А как вам редактирование трафика DNS-сервера?
Если мы присаживаемся на канал вашего почтовика (но не dns-сервера), то можем отключить шифрование между вашим сервером и каким-то другим, для вашей исходящей почты. Они то будут знать через dns, что вы шифруете трафик и к вам будут ломиться на правильный порт.
Но ведь это не единственный возможный вариант. Я вижу еще к примеру такой:
Если мы присаживаемся на канал DNS-сервера (а именно это я и подразумеваю в случае тотального недоверия dns), то мы можем отключить входящее шифрование ото всех =). И, если ваш почтовик пользуется вашим же dns-сервером, то и исходящее тоже ).
В итоге, если мы не доверяем DNS, то целесообразность mta-sts для меня не ясна. А если доверяем DNS, то можно все запихнуть в TXT-запись =).
Если мы присаживаемся на канал вашего почтовика (но не dns-сервера), то можем отключить шифрование между вашим сервером и каким-то другим, для вашей исходящей почты. Они то будут знать через dns, что вы шифруете трафик и к вам будут ломиться на правильный порт.
Но ведь это не единственный возможный вариант. Я вижу еще к примеру такой:
Если мы присаживаемся на канал DNS-сервера (а именно это я и подразумеваю в случае тотального недоверия dns), то мы можем отключить входящее шифрование ото всех =). И, если ваш почтовик пользуется вашим же dns-сервером, то и исходящее тоже ).
В итоге, если мы не доверяем DNS, то целесообразность mta-sts для меня не ясна. А если доверяем DNS, то можно все запихнуть в TXT-запись =).
Т.е. вы считаете что только такой вид атаки возможен и на основе этого считаете меня неграмотным? =)
Сразу два приёма демагога в одном предложении: переход к выводам, основанный на ложной посылке.
Речь шла о перехвате трафика между почтовыми серверами. Вы заявили, что можно угнать HTTPS-трафик сервера политик на другой сервер. Подмена A-записи в этой коммуникации ничего не даёт. Возможность выпустить сертификат возникает только при угоне доменной зоны, в том числе через вмешательство в трафик авторитативного DNS-сервера. В этом случае речь о «подмене веб-сервера mta-sts.example.com» уже не идёт. Это просто не нужно, так как уже можно выпустить валидный сертификат сразу MX-сервера и MTA-STS тут ни при чём: перехват будет осуществим даже если бы все и всегда форсировали использование TLS для обмена.
В сухом остатке: ваша «подмена на веб-сервера» несостоятельна, она требует фактического обладания доменом, при котором можно диктовать практически всё.
А как вам редактирование трафика DNS-сервера?
И, если ваш почтовик пользуется вашим же dns-сервером, то и исходящее тоже
Вообще из этих всех рассуждений неясно, о каком именно DNS-сервере идёт речь. В контексте про выпуск серта речь может идти только про авторитативный. В контексте про сервер, которым пользуется другой сервер, речь скорее всего идёт про рекурсивный резолвер (например 8.8.8.8).
Первый случай расписан выше, второй случай по сути ничем не отличается от вклинивания в канал отправителя и возможности атакующего даже меньше.
В итоге, если мы не доверяем DNS, то целесообразность mta-sts для меня не ясна. А если доверяем DNS, то можно все запихнуть в TXT-запись =).
Это очередной демагогический приём, в котором суждение про потенциально возможный угон домена обобщается на вообще любой перехват DNS и исходя из этого устанавливается ложная эквивалентность между достоверностью данных, получаемыми прямо из DNS и через HTTPS.
Разница ясна — переписать DNS-ответы по пути может любой Вася, а чтобы вскрыть HTTPS надо установить контроль над доменом, выпустить серт (что само по себе палевно). И, как я говорил выше, при таком раскладе уже неважно всё остальное.
Получается что условный Вася может читать нашу входящую почту, а условный агент Смит всю =).
Стоит ли игра свеч? Чем эта суета лучше варианта, который использует гугл? Недавно обнаружил, что почта с гмыла не приходит. Оказалось что гугл сразу цепляется по ssl =).
Стоит ли игра свеч? Чем эта суета лучше варианта, который использует гугл? Недавно обнаружил, что почта с гмыла не приходит. Оказалось что гугл сразу цепляется по ssl =).
Недавно обнаружил, что почта с гмыла не приходит. Оказалось что гугл сразу цепляется по ssl =).
Я вчера-позавчера проверял то же самое — у меня получилось, что почта с гугла приходит даже когда сертификат не соответстует по хостнейму. При том, что у меня опубликована политика enforce (у гмайла политика testing).
У outlook.com есть TXT-запись, но не скачивается политика. Сертификаты на SMTP-серверах вообще стоят от балды.
Интересно, что это всё компании, принимавшие участие в создании стандарта.
Хорошая статья, автору респект, но было бы круто, если бы Вы переписали вашу программу с питона на golang, чтобы она была автономной и независимой.
Что люди только не придумают, лишь бы pgp не пользоваться…
PGP решает немного другую задачу иным способом и тоже не без недостатков. Навскидку проблемы такие:
Тот же S/MIME использовать куда более реально, чем PGP. Тем более что есть УЦ, бесплатно выдающие почтовые сертификаты.
E2E-шифрование это конечно очень круто, но если исключить из модели угроз компрометацию самих почтовых серверов, то всё существенно упрощается: достаточно транспортного шифрования между почтовыми серверами, и между серверами и пользователями. Это избавляет пользователей от тяжкого бремени возни с ключами и сертификатами, при этом от основных проблем защищает.
- Не защищает метаинформацию. Видно почтовые адреса, тему сообщения, всё остальное что в заголовках и размер. Это уже очень много.
- Все решения для обмена ключами или нераспространённые, или неуниверсальные, или и то и другое.
- Требуется десктопный почтовик с поддержкой PGP, в противном случае (какая-нибудь веб-почта) предоставляемые гарантии безопасности сильно ослабевают.
- По этим причинам почти неприменим в корпоративной среде.
Тот же S/MIME использовать куда более реально, чем PGP. Тем более что есть УЦ, бесплатно выдающие почтовые сертификаты.
E2E-шифрование это конечно очень круто, но если исключить из модели угроз компрометацию самих почтовых серверов, то всё существенно упрощается: достаточно транспортного шифрования между почтовыми серверами, и между серверами и пользователями. Это избавляет пользователей от тяжкого бремени возни с ключами и сертификатами, при этом от основных проблем защищает.
Прощай дебаг телнетом, ты был мне хорошим другом, но наши пути разошлись.
Я буду писать тебе письма.
Sign up to leave a comment.
MTA-STS для Postfix