Комментарии 31
Почитайте RFC 5737, 3849. Не очень удобно читать howto, когда ip-адреса имеют вид xx.xx.xx.xx
Зря вы добавили openvpn в статью. К почте он отношения не имеет. В итоге получалась какая-то каша из настройки маршрутизации, vpn-а и почты. Хотя бы пометьте какие настройки не нужны, если не нужен vpn.
Почему я решил включить openvpn? Потому что в РФ нет возможности получить IPv6 без проблем на конечную машину. А как тестировать IPv6 без openvpn в такой ситуации? Никак. Потому и включил его в статью.
Спасибо за ссылки на RFC.
Просто писать про vpn в статье про почту это жуткий оверкилл.
В РФ нативно даёт Эртелеком и МТС (на мобильной сети), т.е. получить нативный ipv6 не так уж и сложно.
Ну ладно, допустим у вашего isp его нет. Но есть же туннельные брокеры https://en.m.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers (для тестов это более чем достаточно)
Допустим, по какой-то причине и это не вариант. Тогда берёте самую дешёвую vps под это дело (рекомендую использовать lowendbox/lowendtalk для поиска) и тестирует с неё, а то у вас даже тест не совсем честный, по сути внутри хоста тестируете часть вещей.
Помимо всего, что уже написали, работать с Docker банально менее удобно. И непонятно зачем добавлять лишние сущности и уровни абстракции в данном конкретном случае. Кроме лишней возни это ничего не добавит.
Ну и бонусом идет, например, невозможность безопасной настройки LetsEncrypt в докере. Все решения, которые я видел, реализованы с открытием лазейки позволяющей выходить за пределы контейнера.
А это самое интересное. Это возможность отправлять письма для конкретного домена с конкретного IPv4/IPv6 адреса.
…
Если helo не соответствует домену почты, от имени кого отправили письмо — начисляются спам очки.
Сколько можно распространять по интернету эту глупость?
Кто-то один раз где-то это написал, и теперь каждый натыкающийся на эту "кладезь мудрости" старается внедрить её у себя и рассказать миру об этом достижении.
HELO не обязано соответствовать домену адреса отправителя, и никакие известные мне почтовые антиспамы за это штрафные баллы не начисляют.
Соответственно для каждого домена должен быть свой IP адрес.
Такого требования также нет.
spamassassin, который установлен у многих почтовых серверов, по умолчанию даёт 1.6 очков спама на неправильный HELO.
Так-то да, если вам не важно попадёт письмо в спам или нет — то на HELO можно не обращать внимание.
Также хотелось бы получить отзывы на тему идеи про почтовые сертификаты. Если идея понравится — постараюсь найти силы написать черновик для rfc.
Его уже написали, одобрили и чёрт знает сколько лет успешно используют: tools.ietf.org/html/rfc4880
Нужен какой-то новый стандарт, при помощи которого в один клик пользователи могли бы установить защищённое соединение. На уровне клиентов. И чтобы это было бы массово распространено среди всех существующих почтовых клиентов.
Это кроме параноиков или людей занимающихся не совсем законной деятельностью нафиг никому не надо. А кому надо тот и PGP освоит.
PGP за почти 3 десятка лет существования не получил распространения среди всех существующих почтовых клиентов ( хотя на мой взгляд в Evolution или Thunderbird пользоваться им достаточно легко ), а вы надеетесь вот так просто взять и договориться с Microsoft, Google, IBM, Apple и кучей компаний поменьше? Да вам сказки надо писать, а не RFC.
>…
> Веб сервер отдаёт публичный ключ. Браузер используя публичный ключ зашифровывает
> http-request и отправляет его.
8 лет оказалось недостаточно.
> Браузер используя публичный ключ зашифровывает http-request и отправляет его.
Это не так, читайте вики: TLS.
> если в стране пытаются ограничить доступ не ко всему сайту,
> а к конкретной странице — то для https сайтов это сделать невозможно.
Очень даже возможно. Для этого государству надо либо вступить в сговор с CA (wiki: StartCom), либо самому стать CA ( habr.com/ru/post/272207 ), либо заюзать что-то типа Carnivore или NarusInsight (но это не точно, агентство которого нет всё отрицает а вики врет). Хотя, если вы король какой-нибудь банановой республики или царек в Рога и Копыта Интернешнл, то вы можете так не заморачиваться а просто связаться с Symantec Solutions и они вам помогут с перехватом HTTPS трафика всех этих ваших холопов.
> браузер у себя локально формирует такую-же пару приватный-публичный ключ
> для каждого https сайта
Не фомирует браузер никакую такую пару ключей.
> И вместе с запросом публичного ключа сайта отправляет свой локальный публичный ключ.
wiki: TLS. Ну или вы неправильно поняли аутентификацию по сертификатам, которая к тому же на публичных сайтах всё равно не применяется.
> http-response шифрует этим вот публичным ключём конкретного клиента.
wiki: TLS, сеансовый ключ там используется на самом деле а не публичный.
Вместо ожидаемого упоминания Диффи-Хеллмана написана какая-то ерунда.
> Само создание такого безопасного канала связи происходит со скоростью ping*2
Два пинга будет только если не учитывать TCP handshake (+1 пинг), не смотреть в CRL (много пингов), не дергать никого по OSCP (много-много пингов). Ну то есть если тупо не проверять совсем ничего и всегда слепо доверять всем без разбору — тогда да, парой-тройкой пингов можно обойтись. Хотя OCSP stapling устраняет эти вот многочисленные лишние пинги. Но его используют только 30% хостов примерно, а у вас он так и вообще не упомянут.
> Для борьбы с такими злоумышленниками придумали публичную БД
> с публичными ключами для каждого https сайта.
Вы, наверное, CA имели в виду. Там у них нет никакой публичной базы публичных ключей. Если CRL — публичные списки отозванных сертификатов — то есть таких, которые раньше можно было использовать а теперь нельзя. Есть OSCP, но это запрос-ответ а не скачивание базы чего-либо.
> Ещё добавлю про ssh соединения. Там никаких публичных ключей нет.
Да ну?
> При первом соединении ssh-клиент должен предупредить, что тут у нас новый публичный ключ.
Вы же только что написали, что никаких публичных ключей нет.
> Через пару часов мы получаем от этой сторонней компании наш «публичный» ключ и ещё набор нескольких публичных ключей.
Сертификат вы оттуда получаете подписанный а вовсе не ключ. Это разные вещи.
> chained — обозначение, что тут цепочка публичных ключей
Цепочка сертификатов. Не бывает никаких цепочек ключей в природе.
оказалось что всё еще на порядок сложнее и как правильно настроить это добро даже и приблизительно не понятно теперь, как же правильно то сделать?
Ваша статья требует полной переработки, с учетом вышеизложенных в комментариях замечаний. Несмотря на наличие этих замечаний, никаких изменений в содержимое статьи Вами не внесено, и она продолжает нести в массы дезинформацию и неверные тезисы.
Я бы попросил Вас скрыть её в черновики до момента переработки содержимого.
Вы уже получили много отзывов и Вам есть над чем подумать.
Если уж включать spam паранойю, то я бы добавил еще:
- поддержку DMARC и ARC
- дополнительные и/или свои блеклисты (это отсылка к строке
reject_rbl_client sbl.spamhaus.org,) - например
fail2banс реакцией на логи postfix о несовпадении hostname<->rDNS, невалидные сертификаты, оборванные входящие TLS/SSL сессии
Ну и плюсую за OpenPGP aka RFC4880
Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind