Comments 93
Почитайте про DKIM, SPF (и так далее) — возможности этой 100 лет, нормальные сервисы такие письма как минимум пометят как подозрительные, gmail вообще плашку рисует яркую.
Неделя безопасности на Хабрахабре! Неделя 1997 года, конечно
Если это все так давно известно, почему тогда это никак не решается? Со стороны обычного пользователя все эти «предупреждающие» значки не вызывают никакого желания что-то заподозрить, ведь значков итак очень много и все они что-то значат, но никто на них не обращает внимания. Адрес отправителя остается без каких-либо пометок. В мобильных приложениях это заметно еще меньше.
В России благодаря (не уверен, ковычках или нет) mail.ru это в общем-то решено. Без кучи подтверждений достоверности письмо просто не доходит, отсекается спам-фильтром. В целом по миру правила более лояльные, у Яндекса в том числе, и неподписанные письма доходят до ящиков (хотя бы до папки спама) и учитываются в т.ч. рейтинги IP сервера и так далее. В общем, с подключением. Если интересно — рекомендую попробовать поднять свой mail-server и попользоваться им, очень быстро станут понятны основные принципы работы спам-фильтрации.
Всё давно решено. Есть DKIM, SPF, а также DMARC, в котором можно прописать запрет писем с некорректным DKIM/SPF.
У гугла [в DMARC прописано](https://mxtoolbox.com/SuperTool.aspx?action=txt%3a_dmarc.gmail.com&run=toolpage) отправлять плохие письма в спам — что, собственно, и произошло. Всё в полном порядке.
Просто взять и запретить всё (или обвешать плашками) нельзя потому, что далеко не все админы почтовых серверов заботятся настроить DKIM/SPF/DMARC и в итоге отправляют некорректные письма со своих почтовых серверов — если просто взять и запретить их, будет плохо всем. Я так понимаю, вы тоже у себя не занимались их настройкой. Так что можете считать, что главная проблема безопасности в почте — это лично вы :)
У гугла [в DMARC прописано](https://mxtoolbox.com/SuperTool.aspx?action=txt%3a_dmarc.gmail.com&run=toolpage) отправлять плохие письма в спам — что, собственно, и произошло. Всё в полном порядке.
Просто взять и запретить всё (или обвешать плашками) нельзя потому, что далеко не все админы почтовых серверов заботятся настроить DKIM/SPF/DMARC и в итоге отправляют некорректные письма со своих почтовых серверов — если просто взять и запретить их, будет плохо всем. Я так понимаю, вы тоже у себя не занимались их настройкой. Так что можете считать, что главная проблема безопасности в почте — это лично вы :)
Именно по этой причине поднимают свои почтовые серверы, с настройкой антиспам систем, такие письма ни один нормально настроенный антиспам не пройдут.
Сервисы типа почта для домена рассчитаны на широкую публику, там все требования к письмам минимальны, чтобы не зарезать валидные письма.
А так, да, SPF и DKIM давно придуманы для решения как раз этой проблемы))
Сервисы типа почта для домена рассчитаны на широкую публику, там все требования к письмам минимальны, чтобы не зарезать валидные письма.
А так, да, SPF и DKIM давно придуманы для решения как раз этой проблемы))
Потому что стандарт, описывающий SMTP протокол — это позволял в свое время. А потом его так и не пересмотрели, и нагородили кучу костыликов типа SPF, DKIM, DMARC.
Слава богу сейчас публичные почтовые системы начали реагировать на эти костылики.
Слава богу сейчас публичные почтовые системы начали реагировать на эти костылики.
Заголовки сообщения электронной почты могут содержать произвольные данные.
Это известно любом минимально квалифицированному ИТ специалисту.
Для борьбы с этим явлением есть множество механизмов включая dkim,spf.
Полагаю большинство крупных публичных серверов внесет данный почтовый сервер в блэклист если с него будет какая либо заметная почтовая активность.
То, что письмо попало в спам совершенно не удивительно, и скорее всего оно попадет туда же на всех приличных почтовых сервисах если вообще дойдет. Огромное кол--во корпоративных серверов откажутся получить данное сообщение.
Это известно любом минимально квалифицированному ИТ специалисту.
Для борьбы с этим явлением есть множество механизмов включая dkim,spf.
Полагаю большинство крупных публичных серверов внесет данный почтовый сервер в блэклист если с него будет какая либо заметная почтовая активность.
То, что письмо попало в спам совершенно не удивительно, и скорее всего оно попадет туда же на всех приличных почтовых сервисах если вообще дойдет. Огромное кол--во корпоративных серверов откажутся получить данное сообщение.
Не позорьтесь. Скройте в черновики. И PHP тут не причём. Руками в telnet можно так же почтовику письмо написать, и оно даже имеет шансы дойти, правда скорее всего в спам.
Кстати интересный вид продвижения — сообщить о давно известном косяке и вставить адрес своего сайта.
Кстати у вас тоже косяк
Слово в защиту автора.
Да, проблема известна более, чем давно. Ещё 20 лет назад через эту хрень я разыгрывал (по-доброму, клянусь) коллег. Известно давно, но от этого вот ну ни разу не легче.
Приятнее ли нам жить с треснутым унитазом от того, что он всегда был треснутым, и все об этом знают? Вот зашёл человек, попользовал неаккуратно, из-за двери слышим поток ээээ… удивления. И что? Будем на него шикать и обвинять в недостаточном знакомстве с матчастью? Мне кажется, вместо этого, может быть, лучше признать, что на дворе 2018-й год, а в унитазе по-прежнему не заделана трещина, а в электронке по-прежнему не заделана дыра с фальсификацией поля «от кого».
Требовать, чтобы все пользователи и админы каждый в одиночку справлялись с этой дрянью — это не системное решение. Вот, например, передо мной письмо от пользователя «scanner@<наш корпоративный домен>» с темой «Attached Image». Внутри вложение с вирусом. Я тёртый калач, я не попался. Но сколько невинных душ на такое ловится каждый день?
Да, проблема известна более, чем давно. Ещё 20 лет назад через эту хрень я разыгрывал (по-доброму, клянусь) коллег. Известно давно, но от этого вот ну ни разу не легче.
Приятнее ли нам жить с треснутым унитазом от того, что он всегда был треснутым, и все об этом знают? Вот зашёл человек, попользовал неаккуратно, из-за двери слышим поток ээээ… удивления. И что? Будем на него шикать и обвинять в недостаточном знакомстве с матчастью? Мне кажется, вместо этого, может быть, лучше признать, что на дворе 2018-й год, а в унитазе по-прежнему не заделана трещина, а в электронке по-прежнему не заделана дыра с фальсификацией поля «от кого».
Требовать, чтобы все пользователи и админы каждый в одиночку справлялись с этой дрянью — это не системное решение. Вот, например, передо мной письмо от пользователя «scanner@<наш корпоративный домен>» с темой «Attached Image». Внутри вложение с вирусом. Я тёртый калач, я не попался. Но сколько невинных душ на такое ловится каждый день?
в электронке по-прежнему не заделана дыра с фальсификацией поля «от кого»
Как минимум лет шесть как заделана. Осталось только заставить админов почтовых серверов (в том числе админа <вашего корпоративного домена>) не полениться настроить решение
Судя по тому, что после того, как я переслал это письмо нашему админу, инциденты не повторялись, он быстро это законопатил. У нас очень хороший админ. А идеальные админы, которые всё-всё-всё делают всегда сразу правильно, бывают только в волшебных сказках.
В любом случае, повторюсь, это не системное решение. Если каждый из миллионов админов по всему миру, включая сельские районы богоспасаемого Бангладеша, должны руками разной степени прямоты правильно прописать систему костылей в свои конфиги, всегда будет существенный процент тех, кто это не сделал.
В любом случае, повторюсь, это не системное решение. Если каждый из миллионов админов по всему миру, включая сельские районы богоспасаемого Бангладеша, должны руками разной степени прямоты правильно прописать систему костылей в свои конфиги, всегда будет существенный процент тех, кто это не сделал.
Это всё тянется из архитектурных косяков почты полувековой давности — тогда просто не задумывались о безопасности. И теперь у нас остаётся всего два варианта — или заставлять всех настраивать костыли DKIM/SPF/DMARC, или вовсе перестать использовать почту (например, изобретя какой-нибудь принципиально новый протокол). Или вы можете предложить какой-то третий вариант?
Согласен, но каким Вы видите решение???
Взять и с сегодняшнего дня не принимать почту если домен отправителя не соответствует адресу отправителя??? И вдруг половину сервисов перестает работать и большая часть клиентов не получит важных им сообщений???
Вы тертый калач и доменов у Вас и сервисов может быть не много, а тем у кого их полно как быть?
Я не против безопасности, сам с юЗверями работаю которые на вопрос — какой пароль, отвечают — 7 звездочек… Но если в плане перехода с http на https все сравнительно просто(поисковики и браузеры сделали этот шаг неминуемым), то как быть в плане почты???
Взять и с сегодняшнего дня не принимать почту если домен отправителя не соответствует адресу отправителя??? И вдруг половину сервисов перестает работать и большая часть клиентов не получит важных им сообщений???
Вы тертый калач и доменов у Вас и сервисов может быть не много, а тем у кого их полно как быть?
Я не против безопасности, сам с юЗверями работаю которые на вопрос — какой пароль, отвечают — 7 звездочек… Но если в плане перехода с http на https все сравнительно просто(поисковики и браузеры сделали этот шаг неминуемым), то как быть в плане почты???
Ваше сообщение в стиле «за все хорошее и против всего плохого».
А вы предложите решение то. И желательно, чтобы это решение не влекло за собой многомиллионные убытки на перепиливание почтовых протоколов.
А вы предложите решение то. И желательно, чтобы это решение не влекло за собой многомиллионные убытки на перепиливание почтовых протоколов.
Проблема не в «перепиливании почтовых протоколов». Проблема в том, что люди хотят, с одной стороны, возможности точно знать кто послал им это письмо, а с другой — возможности посылать письма так, чтобы условный «товарищ майор» их не мог за одно место схватить.
Тот факт, что, в общем-то, одновременно вы такого сделать не можете — им почему-то в голову не приходит.
Тот факт, что, в общем-то, одновременно вы такого сделать не можете — им почему-то в голову не приходит.
Из крайности в крайность. Достаточно подтвердить, что письмо отправил тот сервер, который имеет право отправлять письма с этого домена — именно этим и занимаются DKIM и SPF. А сам сервер может быть сколь угодно анонимным — пусть хоть в Tor сидит. (Остаётся возможная деанонимизация через whois, но это совсем другая история)
Рано или поздно, почтовые протоколы в любом случае придётся перепиливать. Или Вы считаете, что SMTP с нами навсегда? «Навсегда» — это слишком долго.
Вы предлагаете срочно заняться этим самым перепиливанием, лишь на основании того, что все рано или поздно устареет? Как по мне, сомнительная мотивация. В особенности, если учесть, что разработать новый протокол — не такая большая проблема, как повсеместно внедрить его. Какой будет мотивация у абстрактной компании А внедрить его? Потратить на это время, деньги и получить бонусом потенциальные проблемы взаимодействия с почтовыми серверами, не поддерживающими этот новый протокол?
Срочно — не надо. Торопиться надо не спеша. Просто задайте себе такой вопрос: «Если в 2100-м году не будет использоваться SMTP/POP3/IMAP, то что будет использоваться вместо? На что это может быть похоже?» Ростки будущего в виде многочисленных мессенджеров мы можем наблюдать уже сейчас. Молодое поколение, кстати, уже не очень любит е-мэйл. Им удобнее юзать воцап, телеграмчик, вконтактик и прочие фэйсбучки. Да, они проприетарные и централизованные, но лиха беда начало.
Когда появится достойная альтернатива, не надо будет тратить время и деньги на её внедрение. Нужно будет только сжать волю в кулак, наступить на горло собственной алчности и отдать технологию в public domain. А дальше народ потихоньку сам растащит.
Когда появится достойная альтернатива, не надо будет тратить время и деньги на её внедрение. Нужно будет только сжать волю в кулак, наступить на горло собственной алчности и отдать технологию в public domain. А дальше народ потихоньку сам растащит.
С XMPP это почему-то не прокатило
И с Google Wave.
Вообще, это нормальная штатная ситуация. Некоторые технологии захватывают мир даже, бывает, не смотря на очевидную ущербность, а некоторые по какой-то загадочной причине не прокатывают. У нас нет способа отличить будущего чемпиона от будущего неудачника. Притом это касается не только сетевых протоколов, но и вообще чего угодно в нашем прекрасном мире информационных технологий.
Вообще, это нормальная штатная ситуация. Некоторые технологии захватывают мир даже, бывает, не смотря на очевидную ущербность, а некоторые по какой-то загадочной причине не прокатывают. У нас нет способа отличить будущего чемпиона от будущего неудачника. Притом это касается не только сетевых протоколов, но и вообще чего угодно в нашем прекрасном мире информационных технологий.
Я то самое молодое поколение (23 года) и это не мешает мне активно использовать почту для работы.
В современном мире использовать почту для «живого общения» — ужасный мазохизм, как по мне. А вот для деловой переписки электронная почта — самое то. Фейсбук, телеграмм, вотсапп и пр. не позволяют так систематизировать информацию, там нет гибкой системы фильтров, папок. Оно там и не надо, скорее мешать будет.
Так что я очень сомневаюсь, что можно говорить о мессенджерах, как о конкурентах электронной почте.
В современном мире использовать почту для «живого общения» — ужасный мазохизм, как по мне. А вот для деловой переписки электронная почта — самое то. Фейсбук, телеграмм, вотсапп и пр. не позволяют так систематизировать информацию, там нет гибкой системы фильтров, папок. Оно там и не надо, скорее мешать будет.
Так что я очень сомневаюсь, что можно говорить о мессенджерах, как о конкурентах электронной почте.
По идее крупные игроки должны начать ставить SMTP2 в качестве второго доступного, чтобы желающие могли соадиниться по нему, а потом и компания A подтянется. Но нужно время и первые шаги.
Чем вам SMTP+SPF+DKIM не SMTP2?
Костыль на костыле, прям как современный XMPP
И как в таком случае должен выглядеть протокол без костылей?
Пусть об этом лучше расскажут те, кто работал с SMTP больше чем я, а я могу только про XMPP поныть (что, впрочем, я уже неоднократно делал на Хабре)
Так давайте вместе разработаем новый протокол без костылей! Начнем с общей архитектуры безопасности при s2s-соединениях.
Для начала надо придумать каким образом сервер принявший s2s-соединение может убедиться что подключившийся к нему сервер имеет право говорить от имени заявленного домена. У нас есть его IP-адрес с которого он подключился и есть домен. Кажется, самая лучшая идея — проверить их соответствие через DNS. Самый простой способ — использовать тот же самый алгоритм который используется для определения сервера-получателя — но это помешает разделить сервера для входящего и исходящего трафика. А такое разделение бывает объективно нужно. Поэтому для большей гибкости нужно создавать в DNS отдельную запись которая… упс, у нас получился SPF :-)
Для начала надо придумать каким образом сервер принявший s2s-соединение может убедиться что подключившийся к нему сервер имеет право говорить от имени заявленного домена. У нас есть его IP-адрес с которого он подключился и есть домен. Кажется, самая лучшая идея — проверить их соответствие через DNS. Самый простой способ — использовать тот же самый алгоритм который используется для определения сервера-получателя — но это помешает разделить сервера для входящего и исходящего трафика. А такое разделение бывает объективно нужно. Поэтому для большей гибкости нужно создавать в DNS отдельную запись которая… упс, у нас получился SPF :-)
Мне кажется, вместо этого, может быть, лучше признать, что на дворе 2018-й год, а в унитазе по-прежнему не заделана трещина, а в электронке по-прежнему не заделана дыра с фальсификацией поля «от кого».Понимаете какая беда. Цена отказа от этой дыры — отказ от анонимности. Если вы точно можете узнать кто послал письмо — то это, точно также, могут сделать и спецслужбы.
А отказаться от анонимности, вроде как, пользователи не готовы (если судить по сливу кармы любому, кто об этом заикается). Таким образом да, получается, что интернет-сообществу «приятнее жить с треснутым унитазом»…
Цена отказа от этой дыры — отказ от анонимности
Это не так. Анонимность отправителя никак не коррелирует с анонимностью сервера. Так как почтовых сервисов множество, а анонимно зарегистрироваться можно в большинстве из них, ничто не мешает сохранить анонимность и при этом отправлять письма куда угодно.
А существует ли гарантированная анонимность?
Мне вот придумалась другая аналогия: если поехать через перекресток на красный свет, то велика вероятность, что вам в бок кто-то приедет. Можно ли решить эту проблему глобально? Конечно — можно вместо перекрестков сделать многоуровневые развязки. Но, несмотря на очевидное решение, по прежнему каждый водитель «в одиночку справляется с этой дрянью».
Это ограничения протокола о которых нужно знать. Можно сделать новый протокол, но для его внедрения потребуются очень значительные ресурсы (как для строительства развязок на каждом перекрестке). Если таких ресурсов нет — значит учимся пользоваться светофорами.
Это ограничения протокола о которых нужно знать. Можно сделать новый протокол, но для его внедрения потребуются очень значительные ресурсы (как для строительства развязок на каждом перекрестке). Если таких ресурсов нет — значит учимся пользоваться светофорами.
Проблема подделки данных полей давно решена, но она практически никак не улучшает техническую часть безопасности. Вы можете получить вирус и от вполне авторизованного отправителя и с не поддельного домена.
Можно хоть завтра заблокировать все почтовики у которых нет корректного DKIM/SPF, только думается мне половина почтовых серверов при этом окажется за приделами периметра, а безопасности это ни на йоту не добавит.
Это плата за децентрализованную систему доставки без централизованного механизма аутентификации и проверки клиента.
Можно хоть завтра заблокировать все почтовики у которых нет корректного DKIM/SPF, только думается мне половина почтовых серверов при этом окажется за приделами периметра, а безопасности это ни на йоту не добавит.
Это плата за децентрализованную систему доставки без централизованного механизма аутентификации и проверки клиента.
Это плата за децентрализованную систему доставки без централизованного механизма аутентификации и проверки клиентаЭто только значит, что в дополнение к децентрализованной системы доставки нужна децентрализованная система аутентификации и проверки клиента. Только, ради всего святого, не пытайтесь меня убедить в том, что такое невозможно. Вот вам, друзья, нерешённая проблема, над которой есть смысл ломать голову. Попробуем порассуждать?
В PGP пытались наладить сеть доверия — как-то не особо взлетело. А в соседнем хабратопике мне ещё и рассказывали, что в сетях доверия всё равно злоумышленники заводились. А больше годных идей за двадцать лет вроде бы не появлялось
PGPшная сеть доверия изначально была кривой идеей. В силу недоопределёности понятия «доверие». Когда эта тема была в хайпе, я, помнится, так и не смог разобраться с тем, что там имеется в виду под глаголом «доверять», и в итоге пожал плечами и прошёл мимо. Ну, в самом деле, смотрите. Вот есть дядя Вася, которому я не колеблясь доверю починить подвеску в автомобильке, но и в страшном сне не доверю ребёнка. А есть тётя Маша, которой ребёнка доверю, а подвеску — ни за что. Беспредметное доверие — это какой-то ацкий нонсенс. Хуже, чем понятие «друг» в соцсетях.
А больше годных идей за двадцать лет вроде бы не появлялосьВ принципе, тема децентрализованных сетей, функционирующих в условиях тотального взаимного недоверия всех участников, развивается не сказать что бы давно. Блокчейн — это лишь первое приближение. Слегка помыслив, можно попытаться эту же задачу решить гораздо более интересным и дешёвым способом. Можно об этом поговорить, если хотите.
в итоге пожал плечами и прошёл мимо
Я тоже)
Блокчейн
Я не специалист, но слышал про некую атаку 51%
Можно об этом поговорить, если хотите.
Возможно, это хорошая идея, но не в этом топике (а то ещё в черновик улетит) и, наверно, не со мной, ибо я не специалист, а так, диванный аналитик)
С блокчейном другая проблема — использование не бесплатно. Многие ли готовы платить дополнительные деньги за почтовый сервер/адрес?
Совершенно верно. Сильно не бесплатно. Потому что сделано через задницу. Но если снизить себестоимость хотя бы в сотню тысяч раз, это уже будут не те деньги, о которых вообще будет смысл говорить.
От стоимости транзакции зависит и стоимость атаки. Так что цена должна быть не слишком низкой.
Тут просматривается аналогия с https, который существует давно, но повсеместное внедрение началось недавно, хотя стоимость сертификата всегда была довольно низка. Сам факт платить за нечто, необязательное для работы, вызывает негативную реакцию. И дело не только в цене)
Тут просматривается аналогия с https, который существует давно, но повсеместное внедрение началось недавно, хотя стоимость сертификата всегда была довольно низка. Сам факт платить за нечто, необязательное для работы, вызывает негативную реакцию. И дело не только в цене)
От стоимости транзакции зависит и стоимость атаки.В существующей архитектуре — да. В этом и ошибка.
Как мне кажется, принципиально другую архитектуру создать сложно, если вообще возможно. В «мире анонимов, не доверяющих друг другу» стоимость атаки (DOS в том числе) всегда будет сильно зависеть от стоимости операции в системе. Буду рад, если я заблуждаюсь.
Попытаюсь порадовать.
В текущей архитектуре считается, что нужно децентрализовать операции ведения реестра (добавление и хранение данных). При такой постановке задачи действительно неизбежна искусственно созданная конкуренция за право добавления данных. В результате себестоимость добавления уходит в космос, и плюс к тому имеем многократное (очень-очень многократное) дублирование хранения данных. Безусловно, есть некоторый весьма узкий класс задач, для которых важна децентрализованность именно ведения, но для всех остальных (и, в частности, для аутентификации) важна децентрализация не ведения, а контроля целостности.
Представьте себе централизованно ведущийся реестр, работающий (так декларируется) в режиме «только добавление». Естественно, при таком раскладе владелец ресурса может сделать с данными всё, что ему угодно (это ведь просто последовательность байт, хранящаяся в его серверной стойке), но реализована маленькая дополнительная фича: любой желающий в любой точке мира может проконтролировать отсутствие правок задним числом. Злоумышленник может успешно атаковать сам реестр, но для того, чтобы всунуть туда задним числом дезу, ему также придётся также атаковать весь остальной мир, включая компы рядовых пользователей, валяющиеся в карманах флешки, и даже пылящиеся в шкафах бумажные распечатки всяких разнообразных справок, квитанций и чеков. Хакнуть отдельно взятый сервер — вполне осуществимо, но хакнуть весь остальной мир, включая оффлайновые данные — абсолютно непроходимый уровень.
В такой схеме себестоимость ведения реестра — копеечная, а надёжность контроля подлинности — космическая.
В текущей архитектуре считается, что нужно децентрализовать операции ведения реестра (добавление и хранение данных). При такой постановке задачи действительно неизбежна искусственно созданная конкуренция за право добавления данных. В результате себестоимость добавления уходит в космос, и плюс к тому имеем многократное (очень-очень многократное) дублирование хранения данных. Безусловно, есть некоторый весьма узкий класс задач, для которых важна децентрализованность именно ведения, но для всех остальных (и, в частности, для аутентификации) важна децентрализация не ведения, а контроля целостности.
Представьте себе централизованно ведущийся реестр, работающий (так декларируется) в режиме «только добавление». Естественно, при таком раскладе владелец ресурса может сделать с данными всё, что ему угодно (это ведь просто последовательность байт, хранящаяся в его серверной стойке), но реализована маленькая дополнительная фича: любой желающий в любой точке мира может проконтролировать отсутствие правок задним числом. Злоумышленник может успешно атаковать сам реестр, но для того, чтобы всунуть туда задним числом дезу, ему также придётся также атаковать весь остальной мир, включая компы рядовых пользователей, валяющиеся в карманах флешки, и даже пылящиеся в шкафах бумажные распечатки всяких разнообразных справок, квитанций и чеков. Хакнуть отдельно взятый сервер — вполне осуществимо, но хакнуть весь остальной мир, включая оффлайновые данные — абсолютно непроходимый уровень.
В такой схеме себестоимость ведения реестра — копеечная, а надёжность контроля подлинности — космическая.
Децентрализованная система аутентификации и так есть, любой сервер сам регулирует аутентификацию своего smtp клиента.
Вы пытаетесь решить проблему которая давно решена. Только вот любое решение сужает возможно пересылки. При это не закрывая возможность получить зловреда или фишинговую атаку с вполне технически валидного адреса.
Вы пытаетесь решить проблему которая давно решена. Только вот любое решение сужает возможно пересылки. При это не закрывая возможность получить зловреда или фишинговую атаку с вполне технически валидного адреса.
Децентрализованная система аутентификации и так есть, любой сервер сам регулирует аутентификацию своего smtp клиента.Смотрите. Допустим, у нас есть два сервера — S1 и S2, и два клиента C1@S1 и C2@S2. Товарищ C1@S1 посылает письмо своему другу C2@S2. Для этого C1 аутентифицируется на S1 и посылает ему письмо. Дальше S1 передаёт письмо S2. Дальше C2 вынимает его из почтового ящика.
Факт аутентификации C1 на S1 может быть известен S1, но участникам S2 и C2 приходится верить серверу S1 на слово. Оснований верить S1 на слово нет ни у кого никаких кроме, конечно старого доброго «иначе совсем страшно жить».
Вы не там проблему ищете. Основания верить S1 на слово конечно же есть: ему доверяет C1. А если не доверяет — то сообщения, вообще-то, можно и подписывать…
Кому легче от того, что рассылающий письма фишер доверяет тому фишинговому серверу, который сам только что собственноручно поднял? :))
Вопрос именно про C2 и S2. Именно они — потенциальные жертвы обмана. И именно они в данной ситуации оставлены беззащитными.
Вопрос именно про C2 и S2. Именно они — потенциальные жертвы обмана. И именно они в данной ситуации оставлены беззащитными.
Ну так адрес S1-то — вещь проверяемая! (Для S2)
Да, S2 может проверить, что S1 является тем, за кого себя выдаёт, но не может проверить, что S1 правильно и надёжно аутентифицировал пользователя C1. Это их внутреннее между C1 и S1 дело.
А зачем это проверять? Повторюсь, C1 доверяет S1 и выбранному способу аутентификации.
С1 — фишер, пранкер, спамер, морально разложившийся человек. Или вообще вирус. Нас вообще никоим образом не интересует, кому и чему он там доверяет.
С2 — невинная жертва, и наша задача её спасти.
Если С2 может проверить подлинность С1 (факт правильности аутентификации вируса С1 сервером S1), то это было бы лучше всего, но на крайняк сгодится возможность проверки подлинности сервером S2. Ни того, ни другого в существующей схеме нет.
С2 — невинная жертва, и наша задача её спасти.
Если С2 может проверить подлинность С1 (факт правильности аутентификации вируса С1 сервером S1), то это было бы лучше всего, но на крайняк сгодится возможность проверки подлинности сервером S2. Ни того, ни другого в существующей схеме нет.
А как вы иначе себе представляете децентрализованную систему аутентификации?
Децентрализованная она по определению без цента.
Тут уже s2 должен сделать выбор, доверяет он s1 или нет, если не доверяет то может с него почту не получать.
Любая распределенная аутентификация работает на доверии. Например вы берете у Васи паспорт, в нем написано, что он Вася, но единственное основание этому доверять в том, что вы доверяете тому кто этот паспорт выдал, если вы ему не доверяете, вы можете строить свою систему аутентификации Вась.
Вы можете поверх электронной почты накрутить электронную подпись и отбрасывать письма без нее, но боюсь пользователи не очень обрадуются такой степени безопасности.
Децентрализованная она по определению без цента.
Тут уже s2 должен сделать выбор, доверяет он s1 или нет, если не доверяет то может с него почту не получать.
Любая распределенная аутентификация работает на доверии. Например вы берете у Васи паспорт, в нем написано, что он Вася, но единственное основание этому доверять в том, что вы доверяете тому кто этот паспорт выдал, если вы ему не доверяете, вы можете строить свою систему аутентификации Вась.
Вы можете поверх электронной почты накрутить электронную подпись и отбрасывать письма без нее, но боюсь пользователи не очень обрадуются такой степени безопасности.
Любая распределенная аутентификация работает на доверии.Ну то есть по принципу клуба джентльменов, ага? Глобальная открытая система. Где каждый верит друг другу на слово. Шикарно. «Тут ко мне карта и попёрла».
По-хорошему, любая открытая децентрализованная система должна работать на тотальном недоверии. Ну то есть доверять-то можно, но только ровно в том объёме, в каком можем проверить.
Например вы берете у Васи паспорт, в нем написано, что он Вася, но единственное основание этому доверять в том, что вы доверяете тому кто этот паспорт выдалЕсли я умею отличать настоящие паспорта от подделки, а ещё лучше имею возможность пробить Васин паспорт по базе паспортного стола, то степень доверия к этому паспорту примерно равна степени доверия к предположению, что паспортный стол не выдаёт документы всяким жуликам. Это предположение, кстати, тоже не мешало бы иметь возможность проверить.
Выдаёт, но существенно меньше (мизерный объём). Профит от доверия сильно превышает риски.
С денежными знаками та же фигня — там соотношение езщё выше.
С денежными знаками та же фигня — там соотношение езщё выше.
Ну то есть по принципу клуба джентльменов, ага? Глобальная открытая система. Где каждый верит друг другу на слово. Шикарно. «Тут ко мне карта и попёрла».
По-хорошему, любая открытая децентрализованная система должна работать на тотальном недоверии. Ну то есть доверять-то можно, но только ровно в том объёме, в каком можем проверить.
Смеритесь, вы не можете проверить практически ничего. У вас нет механизмов проверить даже легитимность выдачи паспорта, а вы хотите проверять электронную почту.
Вы трактуете доверие в «бытовом», межличностном, смысле. Это не совсем корректно в данном случае.
Как пример https, это можно сказать, механизм доверия, вы доверяете центру сертификации, выдавшему сертификат конкретному сайту. Но это не значит, что надо доверять всей информации размещенной на сайте, это вы решаете на основании личного опыта и степени доверия к организации разместившей данную информацию.
С почтой, с помощью механизмов DKIM/SPF, можно в некоторой степени( никогда нельзя исключать возможность взлома ) быть уверенным, что письмо пришло именно с указанного в поле отправитель домена.
Но это совершенно не значит, что вам следует доверять все информации содержащейся в письме.
Вопрос же доверия к работе самих доменов( что они не пренебрегают базовыми требованиями к безопасности в соответствии с количеством их почтового трафика ) решается ит сообществом, так удалось вывести практически все public relay( сервера осуществляющие пересылку почты от не аутентифицированных отправителей ), просто поток почты с данных серверов перестал доходить до получателей.
Вы со свой стороны можете заблокировать все, что не содержит корректной
DKIM/SPF записи, или даже всю почту не подписанную эцп, но вам следует корректно оценить риски и ущерб от такого решения.
Большинство публичных сервисов в данном случае соблюдает баланс, почта с серверов не имеющих корректных SPF записей чаще всего попадает в спам, но все равно доходит.
СмеритесьВ гробу будем смиряться.
Это ведь в некотором смысле вопрос власти. Вопрос о том, реально ли мы сами себе хозяева. А также хозяева того, что считаем своим. Реально ли мы рулим своими делами, или у нас в руках только муляжи рулей. Когда в каком-то аспекте «нет механизмов», тогда муляжи.
Все вокруг пытаются нас убедить, что как можно больше своих дел мы должны делегировать (доверить) в крепкие руки специально обученных профессионалов. Типа так оно надёжнее и эффективнее. Частично с этим можно согласиться (нет смысла самим выращивать всю свою еду и шить всю свою одежду), но есть вещи, по которым очень важно оставить немножко рычажочков в своих руках. В частности, ни в коем случае нельзя отдавать насовсем способность самостоятельно выносить собственное суждение относительно того, где правда, а где ложь.
Доверие к центрам сертификации — вообще анекдотический кейс. Я понимаю, что индустрия пока не придумала альтернативного решения (мёртвенькую PGPшную сеть доверия в расчёт не берём), но это не отменяет того факта, что то, что придумано — это просто запредельно плохое решение. Открываем список корневых доверенных центров сертификации и шевелим остатками волос на голове: кто все эти люди? С кем из них я пил на брудершафт? На каком основании мой комп безоговорочно доверяет исходящей от них инфе? Кто вообще в моём компе хозяин?
Пока альтернативного решения нет — ОК, воспринимаем как данность. Но давайте не будем объявлять эту девиацию нормой и смиряться.
Ситуация с центрами сертификации она повсеместна в сфере человеческих отношений.
Деньги, это просто бумажки( а чаще всего даже нули и единицы ), их цена обеспечена доверием к эмитенту.
Договора, те же деньги, их цена обеспечена доверим к судебной защите.
Любые личные документы, то же случай, доверие в эмитенту.
Вы не можете доверять даже себе, у вас вполне может быть расстройство личности и по ночам вы пишите фанфики по Сейлор Мун.
Собственные ощущения и память, в них множество искажений, ими вполне успешно можно манипулировать.
Вопрос только в рисках и выгодах. Доверять как правило выгоднее и вполне компенсирует риски.
Доверие в данном случае это не бытовой термин, это критерий оценки рисков.
Деньги, это просто бумажки( а чаще всего даже нули и единицы ), их цена обеспечена доверием к эмитенту.
Договора, те же деньги, их цена обеспечена доверим к судебной защите.
Любые личные документы, то же случай, доверие в эмитенту.
Вы не можете доверять даже себе, у вас вполне может быть расстройство личности и по ночам вы пишите фанфики по Сейлор Мун.
Собственные ощущения и память, в них множество искажений, ими вполне успешно можно манипулировать.
Вопрос только в рисках и выгодах. Доверять как правило выгоднее и вполне компенсирует риски.
Доверие в данном случае это не бытовой термин, это критерий оценки рисков.
Ситуация с центрами сертификации она повсеместна в сфере человеческих отношенийНас в этом старательно пытаются убедить.
Деньги, это просто бумажки( а чаще всего даже нули и единицы ), их цена обеспечена доверием к эмитенту.Деньги — чрезвычайно концептуально сложный предмет. Если совсем коротко, то доверие к эмитенту — дело десятое. Вплоть до того, что бывает так, что государство уже отдало богу душу, но его деньги пока за неимением лучшего пока что в ходу. Ценность денег обеспечена скорее такой тонкой и загадочной штукой, как общественный консенсус относительно этой самой стоимости денег.
Договоры тоже не так уж плотно завязаны на судебную систему. Есть ещё много факторов.
Из того, что наш грешный мир не совсем идеален, вовсе не следует, что нужно включать на полную катушку выученную беспомощность, выкидывать белый флаг и идти сдаваться на милость победителей. Да, есть определённые недоработки, но в целом всё не так суицидально, ежели в корень посмотреть. Человек (любой!!! почти без исключений!!!) — самое хитрое, коварное и изворотливое существо в разведанной части Вселенной, как бы нас всякие свиньи ни пытались убедить в обратном. Для каждой новой манипулятивной технологии мы рано или поздно вырабатываем противоядие. Если не сдаёмся.
Вы вольно трактуете термин «выученная беспомощность».
Методов решения «проблемы» с подделкой адреса электронной почты множество. Просто текущая ситуация является наиболее приемлемой для всех участников процесса.
Это как объявить ложку «выученной беспомощностью», да можно суп потреблять и через трубочку и пить из стакана, и даже слизывать с палочек, но большая часть мира в большинстве ситуаций выбирает ложку.
Тоже самое с почтой, любое «решение» приведет к проблемам с доставкой, поскольку вы сможете доставлять только тем, кто это решению имплементировал у себя.
При этом, чтобы с высокой степенью гарантировать идентификацию личности отправителя, нужно будет отказаться от групповых ящиков и потребуется внешний аутентифицирующий агент. Кстати примерно это витает в головах у лиц продвигающих идею «гос» электронной почты.
Идея сама по себе не плоха, но вот только это не электронная почта. Можете друг другу писать сообщения через ЭДО, можете через гос.услуги( теоретически, а через ЭДО практически ), в принципе даже мессенджеры скоро с современными законами могут сгодиться, поскольку привязаны к сотовому.
Методов решения «проблемы» с подделкой адреса электронной почты множество. Просто текущая ситуация является наиболее приемлемой для всех участников процесса.
Это как объявить ложку «выученной беспомощностью», да можно суп потреблять и через трубочку и пить из стакана, и даже слизывать с палочек, но большая часть мира в большинстве ситуаций выбирает ложку.
Тоже самое с почтой, любое «решение» приведет к проблемам с доставкой, поскольку вы сможете доставлять только тем, кто это решению имплементировал у себя.
При этом, чтобы с высокой степенью гарантировать идентификацию личности отправителя, нужно будет отказаться от групповых ящиков и потребуется внешний аутентифицирующий агент. Кстати примерно это витает в головах у лиц продвигающих идею «гос» электронной почты.
Идея сама по себе не плоха, но вот только это не электронная почта. Можете друг другу писать сообщения через ЭДО, можете через гос.услуги( теоретически, а через ЭДО практически ), в принципе даже мессенджеры скоро с современными законами могут сгодиться, поскольку привязаны к сотовому.
Вы вольно трактуете термин «выученная беспомощность»Научите, как трактовать правильно.
Просто текущая ситуация является наиболее приемлемой для всех участников процессаНе критерий. Было время, когда употребление друг друга в пищу было наиболее приемлемым решением для всех участников процесса, но потом удалось от этого уйти.
любое «решение» приведет к проблемам с доставкой, поскольку вы сможете доставлять только тем, кто это решению имплементировал у себяКонечно. Локально мы имеем классическую электронку, на которую завязано чуть больше, чем дофига. Но если заглянуть чуть дальше, можно увидеть, что имеем экосистему, в которой решения появляются, вызревают, переживают свой расцвет, а потом потихоньку уходят с арены.
Вообще, было бы интересно порассуждать над причиной феноменальной живучести е-мэйла. Это ведь реально динозавр, ведущий свою историю откуда-то из эпохи арпанета. Что в нём такого уникального, чего не было у многочисленных появляющихся и уходящих в небытие «убийц е-мэйла»? Не спешите с ответом. Правильного ответа не было даже у инженеров Гугла, круто обломавшихся с Google Wave.
Продвижение очередного клона смартпрогресса :)
Именно для этого 27 (1991) лет назад придумали PGP. Ещё до всяких SPF, DKIM итд.
А за такое «продвижение» — заслуженно слитый аккаунт.
А за такое «продвижение» — заслуженно слитый аккаунт.
UFO just landed and posted this here
А причем тут дети? Человек просто не потрудился загуглить, вот и весь корень его проблем.
Хабр — такой хабр.
Неайтишную статью, где человек делает тоже самое, только про тротуары — плюсуют, а ИТшную — минусуют. При этом в обеих статьях люди неосведомленные, что так уже сто лет в обед все работает, просто не удосужились загуглить спецификации.
Неайтишную статью, где человек делает тоже самое, только про тротуары — плюсуют, а ИТшную — минусуют. При этом в обеих статьях люди неосведомленные, что так уже сто лет в обед все работает, просто не удосужились загуглить спецификации.
Это не баг. Это фича.
Просто следует понимать, что указанный адрес отправителя не обязательно соответствует реальности. Абсолютно так же, как и в старых добрых письмах в конверте, которые бросали в почтовые ящики для отправки.
А для идентификации отправителя существует такая штука, как подпись. И вариантов подписи, почти гарантирующих отправителя (подпись тоже завсегда можно подделать, только намного труднее), как собак нерезаных.
Как-будто вернулся в конец 90-х и прочёл статью из свежего, пахнущего типографской краской «Хакера». С заголовком «Ё-мыло: скрываем почту с помощью PHP»
Что Вы говорите… То-то настроить отправку уведомлений с моего сервера на мой же ящик так, чтобы он хотя бы в "спам" попал — нужны танцы под луной и кровь девственницы…
А тут Вы мне глаза открыли, мы все уже 20 лет в опасности...
Sign up to leave a comment.
Отправка e-mail с любого адреса