💾 Archived View for domik.dubro.ru › articles › madm-stargrave.gmi captured on 2024-05-10 at 10:54:02. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2024-03-21)

-=-=-=-=-=-=-

Конструктивная критика madm

От шифропанка Сергея Матвеева

Дата: 26 Feb 2024

Приветствую!

Боюсь, что мне не очень нравится вся эта идея. Введение про почтовые

системы -- отличнейшее, с пояснениями и историями как и что плохого

происходит со всей этой экосистемой!

А вот конкретика шифрования писем не выглядит адекватной. Насколько

понял, то письма шифруются асимметрично на ключевой паре лежащей прямо

тут же на диске почтового сервера, где приватный ключ зашифрован на хэше

от пароля пользователя. И упоминается что даже админ не сможет

посмотреть содержимое писем. Собственно, что ему мешает перехватывать

отправляемые пароли/хэши пользователя во время его сеанса? Или что ему

мешает изменить софт и раскрывать дешифрованные приватные ключи? Если

злоумышленником является админ, то оно не обезопасит от него.

Если же хочется просто сделать так, чтобы на диске не оставалось

plaintext-а от писем -- то можно же просто использовать полнодисковое

шифрование (FDE), прозрачное для прикладного ПО.

Насколько понимаю, mail-crypt-plugin нацелен на то, чтобы на диске не

оставалось plaintext. Возможно диском является iSCSI подключённое

устройство даже. В этом случае, дешифрование/шифрование производится на

не подконтрольном злоумышленнику устройстве (у злоумышленника есть

только доступ к диску, к iSCSI хранилищу допустим).

    In case of unauthorized access to the storage backend, the messages
    will, without access to the decryption keys, be unreadable to the
    offending party.

Но почти наверняка можно обойтись полнодисковым шифрованием. Если это

собственный "подкроватный" сервер, то тем более смысла в асимметричной

криптографии нет -- достаточно FDE.

Конкретики как они делают шифрование у них нет в документации (надо код

смотреть), но смущает вот эта фраза:

    Encryption of the messages is performed using the symmetric Advanced
    Encryption Standard (AES) algorithm in Galois/Counter Mode (GCM)
    with 256 bit keys. Integrity of the data is ensured using
    Authenticated Encryption with Associated Data (AEAD) with SHA256
    hashing.

С одной стороны они говорят, что используют AES в GCM режиме, даже

повторно упоминают что используется AEAD режим, но при этом также

говорят и про SHA256. Если у них используется AEAD для шифрования, то

зачем ещё какой-то SHA256? Это очень очень странно звучит. Могу

предположить что, возможно, они проверяют целостность (именно её, а не

аутентичность) данных до того как они попытаются дешифровать и

произвести какие-либо действия с приватным ключом. Тогда SHA256 был бы

резон, хотя и надуманный, как по мне. Просто странно всё тут написано,

но конкретику лень смотреть.

Есть упоминание Protonmail в положительном ключе. У меня резкое

негодование по этому поводу. Насколько слышал, для бесплатных учётных

записей они не предоставляют SMTP/POP3/IMAP4 -- используйте webmail.

Который весь полностью сделан на JavaScript. Сервис не имеет права

говорит о какой-либо безопасности, если он заставляет запускать

произвольный код на компьютере клиента. Кроме того, все ключи шифрования

расположены на их же серверах -- кто-либо как-либо разве сможет

проверить и убедиться что они не сливаются, не копируются в открытом

виде куда-либо? Protonmail это чистой воды шарлатанство, snake-oil

cryptography -- всё зиждиться исключительно на доверии и только доверии

к их серверам, к их владельцам, ничем по сути не отличаясь от webmail-а

любого Gmail, Yandex, whatever (ну кроме того, что эти открыто

заявляются что сканируют нашу почту).

https://eprint.iacr.org/2018/1121

Если же заплатить им, то будет SMTP/POP3/IMAP4. Из этого убирается

JavaScript, но всё равно шифрование/дешифрование производятся на их же

сервере, о котором мы ничего не знаем и не можем узнать. Безопасность

Protonmail-а точно такая же как и любого другого почтового сервера,

просто они официально не заявляли что сканируют/сливают нашу почту, но

вся наша безопасность полностью в их руках.

Если мы считаем, что сервер является недоверенным, его админы

потенциальные злоумышленники, то нужно end-to-end шифрование, никак

иначе. То бишь, в мире электронной почты это PGP. Точнее сейчас это

OpenPGP и/или LibrePGP. А это всё выполняется в MUA пользователя, не

требуя никакой поддержки или дополнительных телодвижений от сервера.

Можно написать правила в MTA/MDA, которые бы запрещали прохождение не

PGP-зашифрованной почты, если хочется. В противном же случае я не вижу

смысла в шифровании на стороне сервера, если это только не

полнодисковое, исключительно чтобы на хранилище не оставалось

plaintext-а, да и делается очень легко и мало ест ресурсов.

И отдельной темой является, собственно, сама архитектура подобного

почтового решения. В начале статьи говорилось о том, что когда-то были

почтовые серверы повсюду, то там, то тут. Unix-ы до сих пор из коробки

зачастую устанавливают какой-нибудь MTA. Это всё так. А затем корпорации

перетащили всех к себе.

Проблема была не с корпорациями, а с тем, что изначально почтой

пользовались пользователи Unix систем. А это, как правило, shared машины

с удалённым доступом. Затем появились ПК, модемы, всё это стало доступно

для простых смертных и они тоже захотели свою почту иметь. Но запустить

у себя Unix систему или иметь более-менее постоянный online доступ к

Интернету они не могли. Поэтому пришлось создавать промежуточные серверы

доставки, с которых по POP3/IMAP4/whatever протоколам забиралась почта.

Это костыль связанный с тем, что у людей не было постоянно подключённых

машин к Интернету.

Сейчас же, постоянный online, грубо говоря, у каждого. У нас больше нет

модемов поверх телефонных линий, где мы платим за время подключения. У

каждого из нас мощнейшие компьютеры, где запустить Unix-систему можно

без проблем. До появления i386 процессора -- Unix, грубо говоря, просто

нельзя было увидеть не на дорогущем железе с RISC процессорами.

Соответственно, зачем POP3/IMAP4? У меня свой почтовый сервер с 2009-го

года, но я никогда не поднимал на нём всё это. Есть stargrave.org домен.

Если хочется на него отправить почту, то MX записи укажут куда

постучаться. Там только MTA (Postfix). Он принимает почту, сохраняет на

диск. Так как это мой "подкроватный" сервер, а мне хочется почту видеть

на своём рабочем компьютере (ноутбуке прежде), то... нужно просто

сделать так, чтобы MTA сервера связался с MTA моего ноутбука и передал

ему временно хранящуюся почту. Для этого не нужны POP3/IMAP4/whatever.

Если же предположить, что у меня всё же несколько устройств (ноутбуков)

и все они хотят видеть один и тот же общий почтовый ящик? Ну хорошо,

почта на принявшем почту для stargrave.org сервере уже хранится на диске

в mbox/maildir формате. Нашему MUA на ноутбуке нужно просто достучаться

до этих файлов. NFS есть с 1980-х годов :-). Можно просто по NFS ходить

до почтового сервера и смотреть там сложенную почту. IMAP4 для этого не

нужен, всё делается сильно проще. Нет шифрования в обычном NFS? Пустить

его поверх IPsec или завернуть трафик в VPN до сервера! Не просто так

именно MTA поставляются из коробки в операционных системах, но никогда

не POP3/IMAP4-like вещи. Это мир DOS/Macintosh систем, это костыли этого

мира не-Unix систем.

Есть заранее известная проблема с тем, чтобы почта долго хранилась на

промежуточном MTA -- после нескольких дней она будет удаляться.

Timeout-ы можно настроить конечно же, но или использовать промежуточные

store-and-forward решения. Я когда-то использовать UUCP-over-SSH для

того, чтобы забираться копившуюся на почтовом сервере почту на свой

ноутбук. Потом написал NNCP проект, который легко интегрируется с

Postfix и, как пишет другой человек, с Exim:

http://www.nncpgo.org/Postfix.html

http://www.nncpgo.org/Exim.html

Если NFS+VPN+MTA+MDA не выходит использовать, то значит это навязанные

ограничения (или недостаток функциональности) навязанной корпорациями :-)

--

Sergey Matveev

http://www.stargrave.org/

OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A

⬅ Назад