Vlákno názorů k článku Konec EV certifikátů: prohlížeče je přestanou zvýrazňovat od Miroslav Šilhavý - Jediné, čeho jsme dosáhli je, že obsah nelze...
-
Jediné, čeho jsme dosáhli je, že obsah nelze odposlechnout tak říkajíc na nasliněný prst. Zůstává paradox, na který zatím nikdo nedává řešení. Šifrujeme spoustu obsahu, který není citlivý. Ve vnitřních sítích je čím dál tím víc problémů něco provozovat, protože prohlížeče řvou vzteky. Ale to nejcitlivější - elektronická pošta - je stále nešifrovaná. Díky tomu můžeme číst ty nejcitlivější informace dál. Odposlech pošty je klíčem k získání DV certifikátu, ať už pomocí ověření mailem, tak např. skrze přístupu ke správě DNS (často na webu, password recovery je po mailu!, na nejslabším protokolu co snad je).
Výsledek?
Před léty: postavím se do cesty (MITM), vystavím web, uzmu provoz, realizuju podvod.
Dnes: postavím se do cesty (MITM), vyžádám si certifikát (MITM na e-mail), vystavím web, uzmu provoz, realizuju podvod.
Dnes alternativně: odposlechnu poštu (MITM), získám heslo ke správě DNS, vyžádám certifikát, vystavím web, uzmu provoz, realizuju podvod.Celý popsaný výsledek považuji za nešťastný. Šifrujeme za každou cenu, ale samotné ověření má hodnotu staré bačkory. Zkrátka, stojí to globálně šílené (tera?) watthodiny energie a jsme ve zhruba stejném bezpečí, jako jsme byli před léty.
Podle mě se to celé mělo ubírat naopak směrem k důkladnějšímu ověření osoby (firmy) žádající o certifikát.
-
Pokud stojít v pozici MITM (což je předpoklad všech těchto útoků), pak stačí zasáhnout do komunikace pošty mezi servery a ty se podle standardu přepnou na nešifrovanou komunikaci. TLS je v případě SMTP čistě opurtunistické.
Navíc neexistuje způsob jak ověřit správnost certifikátu na SMTP serveru. Takže udělat MITM na SMTPS není nic těžkého.
3. 9. 2019, 07:44 editováno autorem komentáře
-
Ondřej CaletkaZlatý podporovatelNastavení začínající na
smtp_se týká SMTP klienta, tedy odchozího směru pošty. Nastavení SMTP serveru by začínalo nasmtpd_.Popsaný problém šifrovaného předávání pošty bez rizika downgrade útoku a přitom slučitelně se zbytkem světa řeší elegantně DANE, mnohem méně elegantně pak MTA-STS, který ale zase prosazuje Google.
-
Ona je otázka, na jaké jméno má být ten certifikát vystavený. Na všechny domény, pro které server přijímá poštu? Nebo na doménové jméno MX serveru? V takovém případě to ale stejně postrádá smysl, pokud nepoužívám DNSSEC, protože kdokoliv může odesílateli podvrhnout jiný MX server. Pak je už jednodušší a efektivnější místo důvěryhodného certifikátu potvrdit platnost klíče pomocí TLSA záznamu nebo novějšího MTA-STS.
-
Ono by stačilo, kdyby EHLO vypisovalo jeden záznam, který se bude shodovat s A a PTR, a zároveň bude odpovídat MX domény. Certifikát pak může být (měl by být) na tu adresu, která je uvedena v PTR. To je jediný smysluplný řetězec ověření.
Ověření by pak mělo být na straně klienta - což nikdo nemá zapnuté, protože by se nikam nedomailoval, mnohdy ani ne na podporu :).
-
Tohle rozhodně není dostačující pro to, abych ověřil autenticitu MX serveru. To jen ukazuje, že někdo (legitimní správce nebo útočník) má správně nastavený server na příjem pošty. V tom schématu chybí vazba adresátova doména – mail server. Bez DNSSEC se takhle nezajistí, že klienti nebudou posílat poštu jinam.
-
mojdedomena.cz MX neci.mailserver.cz
=>
neci.mailserver.cz A 123.45.67.8
=>
8.67.45.123.in-addr.arpa.cz PTR isp.name.cz
=>
isp.name.cz A 123.45.67.8Tímto řetězcem mám ověřeno, že pošta má chodit na isp.name.cz.
Pokud certifikát má CN=isp.name.cz, a mailserver hlásí EHLO isp.name.cz, pak je to definitivní řetězec.Pochopitelně neřeší to zranitelnosti DNS jako takového, ale odpovídá to na otázku, na jaké CN by měl být vystavený certifikát.
-
Pokud v prvním kroku klientovi řeknu, že MX je mail.zladomena.cz, tak tam pošle poštu, ať jsou pak PTR nebo certifikáty jakékoliv. Prostě chybí pevnější vazba na MX a tu umí dát jen DNSSEC.
Toto _by_musel_ řešit SMTP klient. V praxi se to neděje, ale pokud by někdo chtěl, tak by to bylo možné a ten řetězec je nepřetržený. Ale to je stejně dobrovolné, stejně jako používat DNSSEC - tedy obojí je dost bezzubé.
-
Filip JirsákStříbrný podporovatelProč by se u e-mailu mělo postupovat úplně jinak, než u webu? Jméno SMTP serveru, se kterým chci komunikovat, je uvedené na pravé straně v MX záznamu, na to má být vystavený certifikát. Nikdy by mne nenapadlo dávat tam něco jiného. Navíc reverzní DNS záznamy jsou nepovinné a provozovatel poštovního serveru je ani nemusí mít pod kontrolou.
-
Proč by se u e-mailu mělo postupovat úplně jinak, než u webu? Jméno SMTP serveru, se kterým chci komunikovat, je uvedené na pravé straně v MX záznamu, na to má být vystavený certifikát. Nikdy by mne nenapadlo dávat tam něco jiného. Navíc reverzní DNS záznamy jsou nepovinné a provozovatel poštovního serveru je ani nemusí mít pod kontrolou.
Protože mailserver naslouchá na jedné IP adrese a obsluhuje mnohdy mnoho domén. MX sice nesmí být na CNAME, ale běžně si lidé definují vlastní A. Proto je potřeba udělat tu smyčku přes PTR a zpět.
PTR je víceméně považován za povinný, RFC 2505 nadefinovala doporučení opatření proti spamu, spousta mailserverů bez existujícího a odpovídajícího PTR poštu nepřijmou.
-
Filip JirsákStříbrný podporovatel
Protože mailserver naslouchá na jedné IP adrese a obsluhuje mnohdy mnoho domén.
Zatímco webserver naslouchá na jedné IP adrese a obsluhuje mnohdy mnoho domén. Já v tom rozdíl nevidím, vy ano?MX sice nesmí být na CNAME, ale běžně si lidé definují vlastní A. Proto je potřeba udělat tu smyčku přes PTR a zpět.
Já k tomu žádný důvod nevidím. MX vede na jméno, SMTP klient tedy jen zkontroluje, zda to jméno je mezi SAN atributy certifikátu.PTR je víceméně považován za povinný
To je bohužel problém, že spousta správců na RFC kašle a rozhodnou se, že podle RFC sice klient na PTR nesmí spoléhat, ale oni na něj spoléhat budou.spousta mailserverů bez existujícího a odpovídajícího PTR poštu nepřijmo
To se ovšem týká SMTP klienta, tady řešíme server.
