The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Подробности атаки на шифрование PGP и S/MIME в почтовых клиентах

14.05.2018 21:21

Исследователи раскрыли (PDF) детали уязвимости в системах шифрования электронной почты, не дожидаясь намеченного времени публикации. В целом, предположения разработчиков GnuPG оказались верными, а предупреждение о критичности слишком преувеличенными. Предложено два варианта MITM-атаки на почтовые клиенты с поддержкой HTML, которые автоматически загружают данные из внешних ресурсов (например, картинки и CSS).

Первый вариант атаки производится через модификацию транзитного сообщения, в которое подставляется обращение к внешниму ресурсу при помощи тегов "img" или "style", подставляемых в незашифрованные части HTML-писем (MIME-заголовки). Обращающийся к внешнему хосту атакующего тег открывается до начала шифрованного MIME-блока, а закрывается после него (см. пример ниже).

Почтовый клиент с проблемным MIME-парсером при открытии письма дешифрует шифротекст, а затем разбирая HTML отправляет уже расшифрованный текст в составе подставленного атакующими тега. Проблема проявляется только в почтовых клиентах, которые объединяют содержимое всех MIME-частей multipart-сообщения, смешивая шифрованные и незашифрованные части. Например, такое поведение свойственно Apple Mail, iOS Mail и Thunderbird.

Второй вариант атаки отталкивается от уязвимостей в спецификациях S/MIME (CVE-2017-17689) и OpenPGP (CVE-2017-17688). В случае S/MIME атакующий может организовать дешифровку нескольких email, отправив специально изменённое email-сообщение жертве. Для PGP без поддержки MDC атаку совершить сложнее и успешной оказываются только треть попыток, так как перед шифрованием в PGP открытый текст сжимается. Как и в первом варианте в сообщение вставляется HTML-тег, обращающийся к подконтрольному атакующему хосту.

Атака базируется на подмене блоков шифротекста, манипулируя изначально известными блоками данных при использовании режимов CBC и CFB. Зная открытый текст, в режиме CBC атакующий может выборочно изменить блоки. В большинстве случаев при использовании S/MIME в составе исходного текста присутствует строка "Content-type: multipart/signed", т.е. атакующий уже знает содержимое как минимум одного полного блока. Следом атакующий может сформировать блок, содержащий только нули. Пара из изначально известного блока и нулевого блока обозначается как CBC-гаджет.

В ходе атаки CBC-гаджет используется для включения в состав зашифрованного текста данных атакующего. В отличие от первого варианта таки, CBC-гаджет позволяет встроить img-тег атакующего непосредственно в состав зашифрованного текста и создать единую зашифрованную MIME-часть, содержимое которой отправляется на внешний хост при разборе HTML после открытия письма пользователем. Для режима CFB, который применяется в OpenPGP, метод атаки аналогичен режиму CBC.

Некоторые факты:

  • Уязвимость связана с типовыми недоработками в отдельных почтовых клиентах. Проведение первого варианта атаки без участия пользователя возможно только в Apple Mail и iOS Mail, уязвимости подвержены также PostBox, MailMate и Thunderbird, но в них для атаки требуется совершение пользователем определённых действий. Второй вариант атаки с PGP эффективен в Outlook 2007 с GPG4Win, Thunderbird с Enigmail, Apple Mail c GPGTools, Roundcube и ещё в 6 менее известных клиентах. Второй вариант атаки с S/MIME охватывает почти все протестированные клиенты, за исключением Mutt и Claws Mail;
  • Для успешной атаки требуется контроль за трафиком или архивом сообщений жертвы (MITM, взлом почтового сервера или захват учётной записи). При наличии доступа к учётной записи, атакующий может расшифровать ранее полученные пользователем зашифрованные сообщения, путём их модификации и повторной отправки пользователю с применением одной из вышеизложенных атак.
  • Реализации OpenPGP с MDC (GnuPG) проблеме не подвержены, если почтовый клиент учитывает код проверки MDC. В S/MIME (RFC 5751) поддержка аутентифицированного шифрования не предоставляется, что требует внесения изменений в спецификацию S/MIME для устранения уязвимости. В OpenPGP (RFC 4880) спецификация предоставляет возможность аутентифицированного шифрования (MDC), которое позволяет выявить подмену CFB-блоков (поддержка MDC реализована в GnuPG в 2001 году, но при выводе через pipe для определения подмены требуется анализ кода возврата, что многие почтовые клиенты не делают).
  • Наиболее эффективными методами защиты являются отключение поддержки HTML в почтовом клиенте и организация расшифровки не силами почтового клиента, а путём ручного копирования шифротекста в отдельное приложение.


  1. Главная ссылка к новости (https://efail.de/...)
  2. OpenNews: Критическая уязвимость в системах шифрования email на основе PGP/GPG и S/MIME
  3. OpenNews: Выявлен дубликат короткого идентификатора PGP-ключа Линуса Торвальдса
  4. OpenNews: Критическая уязвимость в генераторе случайных чисел GnuPG и Libgcrypt
  5. OpenNews: В Libgcrypt/GnuPG выявлена уязвимость, позволяющая воссоздать RSA-ключи
  6. OpenNews: В рамках проекта NeoPG развивается форк GnuPG 2
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: pgp, gnupg, smime, crypt, mail
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (65) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.2, Аноним (-), 22:09, 14/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +28 +/
    Ублюдку, который придумал слать html в письмах, надо вбить количество в ж.
    Как и разработчикам почтовых клиентов, которые включают html по умолчанию.
     
     
  • 2.3, th3m3 (ok), 22:22, 14/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    +1. В письмах должен быть только текст, вложения и ссылки. Остальное всё ненужно и ведёт к проблемам с безопасностью.
     
     
  • 3.4, Crazy Alex (ok), 22:36, 14/05/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну да. Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.

    Вот чего там НЕ должно быть - это возможности что-то ремотно дотягивать. И даже не из соображений безопасности, а потому что письмо должно ровно также отображаться через десять лет как и в момент получения.

     
     
  • 4.6, КО (?), 23:13, 14/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Вот чего там НЕ должно быть - это возможности что-то ремотно дотягивать

    В той же птичке галочка по умолчанию отключена, для возможности запросов в Инет. Другое дело насколько точно они ей следуют.

     
     
  • 5.7, Crazy Alex (ok), 23:29, 14/05/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Если есть галочка это заканчивается только тем, что пока её не нажмёшь - ни черта не понятно в письме. Сам формат не должен подобное позволять.
     
     
  • 6.52, КО (?), 14:35, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, мне обычно все понятно, ибо ссылки на аттач работают, стили и отступы работают.
    Если ссылка внешняя - тот кто послал ССЗБ.
     
  • 6.53, КО (?), 14:38, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > - ни черта не понятно в письме. Сам формат не должен
    > подобное позволять.

    Ну и в качестве бонуса можно разрешать в конкретном письме или из доверенных источников.
    Кто это делает в шифрованном письме от нипоймикого - ССЗБ.

     
     
  • 7.69, КО (?), 17:36, 18/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Хорошо подумав понял, что был не прав по поводу второй уязвимости.
    Фиг с ним с img, можно же подсунуть div с невидимостью (исходного сообщения) и свое в догонку.
    А это уже реальная компрометация алгоритма.
     
     
  • 8.70, КО (?), 17:37, 18/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но к HTML это опять же отношения не имеет, можно сделать на любой разметке - ори... текст свёрнут, показать
     
  • 4.8, Аноним (-), 23:33, 14/05/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Markdown было бы достаточно.
     
     
  • 5.11, Аноним (-), 00:06, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    AsciiDoc хватит всем!
     
     
  • 6.48, Andrey Mitrofanov (?), 11:41, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > AsciiDoc хватит всем!

    Стабильного кнутовского ТеХ-а -- всем.  В печёнки.  Ибо не.

     
  • 5.12, Crazy Alex (ok), 00:15, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В принципе да, если тащить инлайновые картинки в виде multipart. Лично я бы предпочёл что-то более жёстко задающее оформление и multipart не требующее (например, подмножество PDF), но тут есть где копья ломать.
     
     
  • 6.25, KonstantinB (ok), 07:16, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ой, только не PDF. PostScript - это ж хоть и специфичный, но полноценный, Тьюринг-полный язык программирования.
     
     
  • 7.38, Бетховен (?), 09:53, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Даёшь майнеры в письмах!
     
  • 7.39, Crazy Alex (ok), 10:19, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    pdf и ps - разные вещи, в этом плане можно не беспокоиться
     
  • 6.43, rshadow (ok), 11:03, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Инлайновые картинки кстати очень хорошая вещь. В вебе не используются по простой причине - тогда не работает кеширование. Но для писем же это не помеха.
     
  • 4.29, anonblmous (?), 08:13, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.

    Для кучеряво оформленных документов есть специальная фича - вложения.

     
  • 4.68, freehck (ok), 11:32, 17/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну да. Чтобы ни таблицу не вставить, ни картинку, ни вменяемо оформленный текст.

    PDF в аттаче отправляйте. :)

     
  • 3.15, konst55512 (?), 01:38, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А ведь это ПРАВДА!
    Для пущей безопасности я бы еще из списка http-ссылки поудалял.
    И делов-то - убедить тупых юзверей не пользоваться всякой фигней.
     
     
  • 4.30, anonblmous (?), 08:14, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > И делов-то - убедить тупых юзверей не пользоваться всякой фигней.

    Вот это как раз дело совершенно невозможное. Они непрошибаемы (разве что ломом в висок).

     
  • 4.46, rshadow (ok), 11:12, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А ведь это ПРАВДА!
    > Для пущей безопасности я бы еще из списка http-ссылки поудалял.
    > И делов-то - убедить тупых юзверей не пользоваться всякой фигней.

    Ссылки то как раз дело хорошее. При нажатии главное чтоб диалог подтвержения был для открытия в браузере.

     
  • 2.17, Некто (??), 01:54, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ублюдку, который придумал слать html в письмах, надо вбить количество в ж.
    > Как и разработчикам почтовых клиентов, которые включают html по умолчанию.

    Полностью согласен! Вероятно идея HTML в электронной почте является самой разрушительной за всю историю ИТ. Глобальные убытки не поддаются измерению. Только маркетологи и спамеры балдеют.

     
     
  • 3.21, angra (ok), 04:27, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    И что в ней такого разрушительного и убыточного на фоне тех же аттачей?
     
     
  • 4.63, Аноним (-), 00:25, 16/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > И что в ней такого разрушительного и убыточного на фоне тех же аттачей?

    Аттач еще открыть надо. А HTML - все делает сам. Начиная от выполнения хакерского activeX в древнем аутлук экспрессе в эпоху win9x. Дальше этот почетный тренд продолжился.

     
  • 2.22, Аноним (-), 05:52, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я больше скажу: yблюдкy который вообще придумал EML надо большой и длинный вставить в задницу и заставить писать парсер для этого самого eml.
     
  • 2.35, Аноним (-), 08:40, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты даже не представляешь, как удобно брать мышкой выделенный текст из ворда и перетягивать в окно гмейла - он весь с форматированием остается, все красиво и удобно.
     
     
  • 3.47, АНГЫВНАГЫНВАШЩ (?), 11:15, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    открытки рассылаешь что ли?
     
     
  • 4.49, Аноним (-), 11:47, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Обычные ИПшные вещи - например, кусок документа скопировать и выслать.
     
     
  • 5.51, Аноним (-), 14:26, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И нафига при этом вместе с текстом тащить в письмо отступы, интервалы, кегли и прочие архитектурные излишества?
     
     
  • 6.54, КО (?), 14:41, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну бывает хочется коментарии италиком, литералы одним цветом, ключевые слова другим...
    Или например выделить главную мысль, вставить табличку и т.п. и т.д.
    А вот, не работающая подгрузка логотипов с сайта компании это как раз то, что я не хочу видеть и мне это не показывают. :)
     

  • 1.9, Michael Shigorin (ok), 23:46, 14/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Второй вариант атаки с S/MIME охватывает почти все
    > протестированные клиенты, за исключением Mutt и Claws Mail;

    :)

     
     
  • 2.23, PereresusNeVlezaetBuggy (ok), 06:37, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> Второй вариант атаки с S/MIME охватывает почти все
    >> протестированные клиенты, за исключением Mutt и Claws Mail;
    > :)

    Я вот, кстати, даже удивился: в кои веки Claws, который мне Опеннет из соображений политкорректности не даёт назвать предметом домашнего обихода с дырками, не оказался уязвим.

     
     
  • 3.24, Ю.Т. (?), 07:01, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, не доделано просто, не успели присоединиться ))
     
  • 2.45, Аноним (-), 11:11, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Claws как был лучшим из гуевых, так и остался, лол.

    Кстати, Sylpheed подвержен уязвимости или нет?

     

  • 1.13, Sw00p aka Jerom (?), 00:50, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сделать MITM и пихнуть img тег!

    DKIM? О_о - не не слышал:)

     
     
  • 2.14, Некто (??), 01:36, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Сделать MITM и пихнуть img тег!
    >DKIM? О_о - не не слышал:)

    То что DKIM подписывает исключительно заголовки (и то не все, обычно: h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To;) не слышал?

     
     
  • 3.20, angra (ok), 04:24, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    DKIM может подписать всё, что ему скажешь, в том числе и тело сообщения. Разумеется, это только в том случае, если DKIM формирует твой MUA или MTA, а не какой-нибудь google, msn, mail.ru итп.
     
     
  • 4.56, Sw00p aka Jerom (?), 16:28, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут нужно отметить одно, МИТМ происходит на стороне получателя, и если отправитель подписал DKIM-мом, собственно получатель обязан по современным меркам проверить подпись, в таком случае внедрить тег и провести атаку - не получится, но тут есть НО (большое).

    Если мы говорим, МИТМ на стороне получателя, то подразумеваем, что атакующий котроллирует весь трафик (теоретически), так вот ниже опишу юзкейсы.

    1) Атакующий тупо вырезает из заголовком подпись, сработает атака?

    ДА - минус DKIM-а в том, что получатель понятия не имеет о том, что, должно ли быть подписано сообщение или нет (Если только не описано какими-либо другими правилами, к примеру DMARC). Вырезав подпись - теряем DKIM селектор, и не знаем куда за днс записью обратиться, чтобы взять ключ.

    2) Атакующий не вырезает, а подменяет подпись на свою, чтобы не вызывать подозрений, и тем самым подделывает ключ в ответе от днс сервера.

    Учитывая, то, что получатель идёт по селектору за ключём через днс запрос, то атакующий легко подменяет и ключ (публичный ключь) только в том случае, если днс ответы сами не подписаны механизмом к примеру DNS-SEC.

    Вывод: механизм DKIM - полная лажа. Даже в связке DMARC+DKIM (DMARC dkim=s, письма с этого домена обязательно должны быть подписаны), но без DNS-SEC - полная лажа. Ситуацию с TLS(STARTTLS) не рассматриваю, потому-что изначально оговорено, что атакующий контроллирует трафик, даже TLS.


     
  • 3.57, Sw00p aka Jerom (?), 16:30, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > То что DKIM подписывает исключительно заголовки (и то не все, обычно: h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:To;)
    > не слышал?

    нее, не читал!!!

    https://www.ietf.org/rfc/rfc6376.txt

     
  • 2.64, КО (?), 08:46, 16/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >DKIM? О_о - не не слышал:)

    И при чем тут это?
    Письмо отправляет атакующий от себя. Зачем ему этот Ваш DKIM? Он не пытается выдать себя за адресата. Он пишет письмо содержащее инструкции почтовому клиенту расшифровать то что он просит и отправить туда куда он просит. Если в клиенте настроено расшифровывать и отправлять на автомате, то - вуаля.

     
     
  • 3.67, Sw00p aka Jerom (?), 14:19, 16/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Расшифровать может как и клиент (получатель) так и его pgp шлюз, и тоже самое с DKIM-мом, как сам клиент проверяет DKIM, так же и его шлюз (почтовый). Тут главное выделять где именно происходит МИТМ. Приведу примеры:


    Пояснения по сокращениям.
    R - получатель
    S - отправитель

    SMTP_R - SMTP сервер получателя
    SMTP_S - SMTP сервер отправителя

    Вот обычная схема
    [R] <-- [SMTP_R] <--INTERNET-- [SMTP_S] <-- [S]

    Отсюда видно, что MiTM (теоретически) можно произвести в трёх местах. В нашем случае (перехват расшифрованного письма) MiTM должен быть между [R] <-- [SMTP_R], потомучто именно либо в конечной точке [R] происходит расшифровка, либо на [SMTP_R] в случае корпоративного PGP шлюза, и схема примет вид:


    [R] <--[MiTM]--- [SMTP_R] <--INTERNET-- [SMTP_S] <-- [S]

    Беспомощность DKIM-а описал выше.

     

  • 1.16, Некто (??), 01:40, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Меня реально в этой уязвимости удивляет почему шифрование PGP и S/MIME используется без предварительного крипто подписывания сообщения? Ведь в этом случае сторонние вставки в текст становятся невозможными.
     
     
  • 2.18, Аноним (-), 02:20, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это или от безалаберности или "By design", а то чет в последнее время палятся слишком уж очевидные
    уязвимости=)))
     
  • 2.19, Аноним (-), 03:46, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Криптоподпись подтверждает отправителя, это не всем нужно и не всегда.
     
     
  • 3.27, anomymous (?), 07:54, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Шифрование с использованием открытого публичного ключа как бы уже подтверждает отправителя.
     
     
  • 4.28, Аноним (-), 08:09, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подробностей?
     
     
  • 5.34, anomymous (?), 08:38, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Можно подробностей?

    Можно. Ключ для расшифровки вы как будете выбирать на клиенте?

     
     
  • 6.37, Xasd5 (?), 09:48, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    для -- ДЕшифровки я попробовал бы свой ключ (а не ключ отправителя.. которого, секундочку, у меня даже нет!).

    однако кто отправил (и не подменили ли письмо при отправке?, и не переслали ли занова вообще полностью всё письмо?) -- это ни как не прояснит

     
  • 4.41, Аноним (-), 10:59, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ты ошибся, брат. Бывает
     
  • 2.26, anomymous (?), 07:53, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, мне тоже удивительно, почему в сообщении с шифрованием, к тому же использующим PKI, нет подписи целостности контента. То ли это сознательно оставленная дыра, то ли одно из двух.
     
  • 2.32, КО (?), 08:30, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Меня реально в этой уязвимости удивляет почему шифрование PGP и S/MIME используется без предварительного крипто подписывания сообщения?

    В данном случае это не важно. Ибо письмо посылает атакующий. Просто вставляет ту часть, которую хочет, чтобы расшифровал атакуемый. Городить же на клиенте правила, если письмо от Боба то расшифровывать ключом - Б, а если от Алисы - А, этот функционал (создание правил) не каждая домохозяйка осилит. А кто осилит, тому автоматическая расшифровка не нужна.

     
     
  • 3.33, anomymous (?), 08:37, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Опять же - mixed content разрешен почему-то. Чётких boundary сделать для криптоконтента не потрудились.
    Я этим счастьем как-то сразу решил не пользоваться, для крипты есть криптованные аттачменты.
     
  • 3.62, Аноним (-), 22:21, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты фигню несёшь. Кого атакующий, посылающий письмо, атаковать будет? Себя? Ведь он максимум сможет получить сообщение, которое отправил.

    Тут проблема в том, что кто-то из толпы может модифицировать чужие сообщения.

     
  • 2.61, Nicknnn (ok), 21:42, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > предварительного

    Это что подпись для исходного письма? лол

    > невозможными

    Возможным, так как подписывается не всё письмо, а только часть, выделенная разделителями. Тэг можно поставить над этим разделителем и зашифрованная часть по прежнему будет считаться проверенной. Ну и  можно просто вырезать подпись из письма.

     

  • 1.36, ryoken (ok), 09:26, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Всегда говорил, что за HTML в почте надо вешать на первом фонаре.
     
  • 1.40, Аноним (-), 10:30, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Исследователи раскрыли (PDF) детали уязвимости в системах шифрования электронной почты, не дожидаясь намеченного времени публикации.

    лол
    Эх, как не терпелось-то, а! Ведь и название придумали, и сайт запилили на красивом домене (идеально было бы efail.io, ну да ладно). Ну и что, что "предупреждение о критичности оказались слишком преувеличенными". Сайт! Логотип! Название!

     
     
  • 2.42, Аноним (-), 11:01, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Видные британские дизайнеры, верстальщики и один маркетолог объявили о нахождении уязвимости"
     

  • 1.50, анон (?), 13:40, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    то есть я, злоумышленник, могу послать письмо, включить в него шифрованный контент, получить часть письма неким параметром в обращении хттп-гетом за какой-то картинкой?
     
     
  • 2.55, КО (?), 14:44, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если у получателя стоит галочка отправлять геты на сторону. Если не стоит, то нет.
     

  • 1.58, Kuromi (ok), 16:38, 15/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Печально то, что Thunderbird оказался уязвим. Печально, но не удивительно, если сами разработчики Тундры давно уже критически недоукомплектованы и ни на что кроме как латания дыр вызванных вырезанием старого кода из Firefox у них времени не хвататет.
     
     
  • 2.60, Аноним (-), 18:54, 15/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    на офсайте написано free, easy, great features и всё совпадает. rare cases нарушения вашей приватности в формулу не входит.
     
  • 2.65, КО (?), 08:49, 16/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Печально то, что Thunderbird оказался уязвим.

    Если ССЗБ снимет галочку - получать контент из интернета для всех писем, сайтов и отправителей без разбору.

     
     
  • 3.66, КО (?), 08:51, 16/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. поставит.
     

  • 1.71, Аноним (-), 20:38, 19/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    гг если дырка в обращении к внешним ресурсам через html, то надо запретить html. Господа предлагающие это - конкретные идиоты.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру