30 марта 2023 года Mozilla закрыла баг 135636 и исправила ошибку по автоматическому включению/отключению шифрования почтовых сообщений в зависимости от текущей конфигурации отправителя и получателя (режимы OpenPGP и S/MIME). В этом не было бы ничего странного, если бы не одна деталь: тикет открыт 21 год назад. В связи с этим возникает вопрос: почему закрытие такого простого бага заняло больше двух десятилетий?
История бага
5 апреля 2002 года пользователь Маркус Герстель (Markus Gerstel) обратил внимание на некоторое неудобство настроек шифрования в менеджере аккаунтов (Account Manager) почтового клиента MailNews в Netscape 4. Там было два режима: 1) никогда не шифровать сообщения или 2) требуется шифрование (отправка незашифрованного письма невозможна).
Режим с включённым шифрованием:
Режим с выключенным шифрованием:
Это на самом деле неудобно, потому что нужно было отключать настройку шифрования каждый раз, когда вы хотите отправить письмо пользователю, не имеющему сертификата или публичных ключей. Или наоборот, каждый раз включать её, когда хотите отправить зашифрованное письмо. Автор выразил пожелание реализовать третью альтернативную опцию «Шифровать, когда это возможно», не требующую от пользователя включать/отключать шифрование вручную.
Таким образом, шифрование будет включаться автоматически при составлении письмо для адресата, который предоставил открытые ключи. Действительно, очень удобно. Есть ключи или сертификат — шифруем. Нет ключей — не шифруем.
Разработчики согласились, что такую опцию нужно реализовать, но сама реализация заняла ровно 21 год. Почему?
Сначала один из мейнтейнеров Чарльз Розендаль (Charles Rosendahl) посчитал, что данный баг предполагает регрессию, то есть требует исправления другой связанной функции. Хотя другие с ним не согласились, но это привело к задержке примерно на семь лет.
Затем вопрос с регрессией сняли, но сама тема потеряла актуальность, потому что в целом шифрование почты с помощью OpenPGP перестало восприниматься как нечто необходимое и обязательное. Частично это произошло из-за сложностей интерфейса и потому что ни один почтовый клиент не обеспечил первоклассную удобную реализацию шифрования.
Два года назад Mozilla заново подняла эту дискуссию, она переросла в споры о дизайне, и только в 2023 году наконец-то опция была реализована.
Шифрование почты должно стать стандартом
История с багом в почтовом клиенте Mozilla наводит на подозрение, что разработчикам как будто кто-то мешает реализовать нормальное шифрование электронной почты. С технической точки зрения совершенно понятно, как должна работать стойкая криптография и PGP, какие шифры использовать. Но вот с точки зрения интерфейсов как будто кто-то посторонний постоянно ставил палки в колёса и мешал развернуть эту функциональность на широкую аудиторию.
Довольно распространено мнение, что шифрование электронной почты было и остаётся неудобной процедурой. Всё можно было сделать гораздо понятнее для простых пользователей. Тем более для важной функции. Это просто удивительно, что настолько важная технология до сих пор не стала мейнстримом, и многие люди до сих отправляют конфиденциальные письма, не используя стойкую криптографию.
Почему ни один почтовый клиент за многие годы не сделал удобную реализацию PGP или S/MIME — это открытый вопрос. Такое ощущение, что им как будто кто-то специально мешал это сделать. В самом деле, если посмотреть на десятилетия развития PGP и шифрования почты, то мы видим множество неудачных реализаций, отсутствие должной разработки, ужасный UI, которым невозможно пользоваться, всевозможные задержки внедрения, распространение различных труднореализуемых стандартов.
В то же время было реализовано шифрование в вебе (TLS), есть прогресс для мгновенных сообщений. А вот что происходит с электронной почтой — вызывает недоумение, словно кто-то реально мешает со стороны.
Разработчики популярных ОС могли бы организовать распространение сертификатов S/MIME, реализовать хранилища сертификатов для удобства шифрования почты. Но не сделали этого. Конечно, управление персональными сертификатами пользователями в большом масштабе сложнее, чем управлением сертификатами веб-сайтов, но это решаемая задача.
В идеале, на почтовых серверах весь архив должен храниться в зашифрованном виде, и если провайдер/хостер попытается прочитать текст письма, то увидит что-то вроде такого:
-----BEGIN PGP MESSAGE----- hF4DiRYQNnty8w4SAQdAdiM2arHOheTBYTJriZZQOarZJy39Hs2Hl2tbAM/n5yMw 3DrQEjbJtP2LAm1oxaKPI3cyL05OFMU4p5ZKzbNLChEgNG7dxrUZJ9/0aS1P/8hl 0lkBHVB0DPdgxtLk7tl23iozcnoP4Heua1Lvqf831Cy51409FHk4UX/hUPwg2E/O mRczP2UVrbBB90CA0L0wRFfXZpPTtq0UusAtPZ4evtzEgcH4pDK5LV7hog== =vlQ3 -----END PGP MESSAGE-----
Наверное, это тоже одна из причин, почему крупные почтовые провайдеры не стремятся реализовать стойкую криптографию для всех по умолчанию. Ведь тогда они лишаются возможности внедрять контекстную рекламу и дополнять профили пользователей.
Хотя это немного похоже на параноидальную теорию заговора, но нельзя отрицать того факта, что внешние силы тоже противодействуют внедрению стойкой криптографии. По мнению отдельных спецслужб, простым людям нельзя давать в руки этот инструмент, потому что тогда его начнут использовать преступники. Даже сегодня в наши дни наличие криптографических мессенджеров типа Signal на телефоне человека может стать поводом для подозрений. Конечно же, ситуацию нужно исправлять. Многие специалисты по безопасности говорят, что шифрование электронной почты должно стать стандартом, ведь тайна почтовой переписки защищена Конституцией и является одним из основных прав человека.
Подробнее о защите электронной почты для организаций на сайте GlobalSign
