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
Nastavení začínající na smtp_
se týká SMTP klienta, tedy odchozího směru pošty. Nastavení SMTP serveru by začínalo na smtpd_
.
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.8
Tí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é.
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.
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.
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.
"Proti tomu u OV (Organization Validation) a EV (Extended Validation) probíhá podrobné ověřování žadatele.
...
DV certifikáty se dnes dávají zdarma, OV nepřináší nic zásadního, ale EV má podle komerčních autorit výhodu ve větší důvěryhodnosti takto označených webů"
Pokud tomu tedy rozumím správně, tak OV mají stejnou úroveň validace jako EV (tady mám ale trochu rozpor s tím, že "OV nepřináší nic zásadního") a to, za co se u EV platilo, bylo jen to zobrazení názvu v prohlížečích, protože ověření bylo stejné. Pak ale moc to rušení podpory EV nechápu. Klidně to mohli nechat, pokud si někdo chce platit za to, aby se uživatelům zobrazoval jeho název. Je to jeho věc. Není to podle mě nic proti ničemu. Banky na to peníze mají.
Pokud je ale nějaký problém v té validaci (pokud to má to vyjadřovat ono "nepřináší nic zásadního"), tak naopak měli zrušit i OV.
Asi jsem moc paranoický, ale já za tom spíše vidím snahu oddělat komerční CA ve prospěch LE, kterou Mozilla i Chrome podporují. A za pár let začneme prskat, že LE má monopol a LE pak bude za $ (ani ty firmy, které ji podporují, nejsou charita).
Asi jsem moc paranoický, ale já za tom spíše vidím snahu oddělat komerční CA ve prospěch LE, kterou Mozilla i Chrome podporují. A za pár let začneme prskat, že LE má monopol a LE pak bude za $ (ani ty firmy, které ji podporují, nejsou charita).
Já se k Vašemu pocitu připojuji, taky se mi zdá, že cílem je devalvovat ověření certifikátem až na samotné dno. Důvodů může být mnoho, mimo komerčních aktivit do toho mohou vstupovat širší zájmy USA, které v podnikání velkých korporací (Google, Cisco, ...) mají dost významné slovo.
Pokud tomu tedy rozumím správně, tak OV mají stejnou úroveň validace jako EV
Je to jinak. DV ověřuje jen držení domény (nebo webového serveru v dané doméně, e-mailové schránky apod.), OV ověřuje, že máte právo mluvit za danou organizaci (na základě zaslaných dokumentů), EV ověřuje tu organizaci důkladněji (např. i telefonátem). Tedy OV i EV ověřují to samé (příslušnost k organizaci), ale EV by mělo být důkladnější ověření.
to, za co se u EV platilo, bylo jen to zobrazení názvu v prohlížečích, protože ověření bylo stejné
Ověření bylo jiné, ale reálně se platilo za to zobrazení v prohlížeči, to bylo to jediné, co uživatel mohl rozpoznat.
Klidně to mohli nechat, pokud si někdo chce platit za to, aby se uživatelům zobrazoval jeho název.
Problém je v tom, že EV vydávají certifikační autority, ale o zobrazení v prohlížeči rozhodují autoři prohlížečů. To, co se dnes mění, je zobrazení v prohlížeči. EV certifikáty tedy zatím budou dál existovat – akorát už nebudou dávat žádný smysl, protože jediné reálné rozlišení bylo právě v těch prohlížečích.
Asi jsem moc paranoický, ale já za tom spíše vidím snahu oddělat komerční CA ve prospěch LE, kterou Mozilla i Chrome podporují.
To si nemyslím. Ten argument, že to drtivá většina uživatelů nerozlišuje, mi připadá validní. Akorát si nemyslím, že by to měl být důvod ke zrušení – těch pár lidí, kteří si název v adresním prohlížeči kontrolují, o tuhle možnost přijde, a přínos té změny není žádný.
Osobně bych EV zrušil, ale jméno v prohlížeči by se mělo zobrazovat u OV certifikátů. Proto se přece serverový certifikát vydává, aby někdo důvěryhodný spojil jméno s doménou. DV certifikáty jsou nesmysl, stejnou službu udělá veřejný klíč v DNS a odpadne tím jeden prvek (CA), na který je možné zaútočit.
Problém je, že spousta CA rezignovala na to, aby svou práci dělaly pořádně. DV certifikáty validovaly čím dál méně, až to dospělo do stavu, že to v pohodě zvládne automat a vznikl LE. Validaci pro OV certifikáty také flákaly, tak zavedly EV jako certifikáty, kde validaci provedou fakt správně. Bylo by fajn, kdyby se to dostalo zpět do rozumného stavu, kdy budou certifikační autority vydávat jen OV certifikáty a budou je validovat pořádně.
"DV certifikáty validovaly čím dál méně..."
No a jak víc byste chtěl validovat DV certifikát?
Byly doby, kdy dotazem na whois se o doméně dalo zjistit kde co, včetně telefonu a mailu technického kontaktu, pak by se možná dalo validovat něco dalšího, ale dnes je je to silně ořezané a nemáte proti čemu validovat.
Dříve i validaci domén dělal člověk. Předpokládal jsem, že u toho přemýšlí a nedovolí např. validaci domény seznam.cz pomocí e-mailu, když zjistí, že Seznam na té doméně provozuje poštovní schránky pro veřejnost a potřebnou schránku si tam mohl založit kdokoli.
Ale jinak já bych validovat DV certifikát neměl, jak jsem psal, považuju to za nesmysl. O údajích v DNS rozhoduje registrátor příslušné domény, nedává smysl, aby nějaká CA dávala palec na to, že to u registrátora ověřila, když to může udělat každý sám. Navíc když se to bude ověřovat přímo z DNS, budou údaje vždy aktuální (podle možností DNS). Dnes je klidně možné nechat si vystavit DV certifikát den před expirací domény a pak můžete mít přes dva roky certifikát k doméně, která vám nepatří.
Takže za sebe bych byl rád, abychom se DV certifikátů co nejdřív zbavili – ale zatím to bohužel nevypadá, že by to šlo tímto směrem.
Takže za sebe bych byl rád, abychom se DV certifikátů co nejdřív zbavili – ale zatím to bohužel nevypadá, že by to šlo tímto směrem.
Já s tím naprosto souhlasím. Jen bych k tomu dodal, že v EU máme docela dobře vyřešené digitální podpisy a ověření, na rozdíl od mnohých jiných částí světa včetně USA je u nás jednoduché, kvalitní a právně hodnotné. Občanky s čipem to přinesou ještě o kus blíž i běžnému občanovi.
Podle mě přesně naopak. Současná situace s el. podpisy je tristní a zatím skoro nepoužitelná, protože osobu, která dokument podepsala, prakticky nelze nijak identifikovat/ztotožnit. EU tomu s eIDAS ještě nasadila korunu tím, že povolila mít v certifikáty pouze pseudonymy.
Mohu sice říct, že tento dokument podepsala osoba, která má tento veřejný klíč a certifikát SN XY, ale kdo ta osoba je, to se nedozvím. Tohle je pro eGov jedna z velkých brzd.
Ale snad se blýská na lepší časy. Snažíme se protlačit, aby byly informace o certifikátu občana uloženy v ROB nebo v PO a ten je přes eGSB dokázal poskytnout AIS.
Certifikát vydaný španělskou CA by se mohl do ROB dostat třeba na CzechPOINTu.
O omezení na AIS jsem nic nepsal. Já jen psal, že AIS by údaje měly získávat přes eGSB (nebo ISZR), což je pro AIS primární rozhraní. Jestli budou poskytovány i jiným rozhraním, to je jiná otázka.
PS: Zdůrazňuji všude ono "by", může dopadnout všelijak...
Chápu to jako „rychlý“ hotfix. Ale radši bych systémové řešení, které nebude vyžadovat další osobní návštěvu úřadu, bude fungovat pro všechny spoléhající subjekty (a ideálně bude platit v celé EU, ale společná identifikace osob v celé EU je na hodně dlouhou trať, když i v ČR se v této oblasti akorát ruší to, co fungovalo).
Politická a ekonomická záležitost. HTTPS certifikát je sice vidět čím dál méně, ale je vidět. Zákazníci za něj platí, ať už za certifikát, tak za služby spojené se zavedením, údržbou (práce admina apod.).
Proti tomu DNSsec a DANE jsou neviditelné. Stejně jako je zcela neviditelná obrovská díra v SMTP a opurtunistickém SMTPS šifrování. MTA-STS je už dnes možnost, ale kdo ji ve skutečnosti využívá? Skoro nikdo, protože to nikdo neocení. Zámeček v prohlížeči je "hmatatelný" (velké uvozovky!).
DNSsec + DANE také není všespásné, nejslabším a zároveň o to mocnějším místem se stane přístup do správy DNS. Viděl jste někdy v praxi, jak si zákazníci přístupy do DNS chrání? V malých firmách mají hesla všichni od "místního-IT-šťourala" až po účetní (aby si tam mohla stahovat faktury za údržbu domény a hosting).
3. 9. 2019, 08:07 editováno autorem komentáře
Pokud někdo může pozměnit obsah vašeho DNS, tak si snadno nechá vydat DV certifikát, třeba od LE. O takových útocích jsem už i četl.
Když se DANE standardizovalo, "prohlížeče" o to neměly zájem a zatím se nezdá že by nastal posun. Mně DANE dává smysl pro DV certifikáty, kde jde pouze o ověření vlastnictví doménového jména. Ale já osobně jsem z principu zaujatý...
Chudáci ti lidé, co za ten EV cerfifikát zaplatili a teď jim jejich draze zaplacená "bezpečnost" přijde vniveč... mně osobně to třeba u bank přišlo jako dobrý nápad, protože bylo na první pohled vidět, zdali mi někdo "nekecá" - třeba antivir - do SSL/TLS provozu - a teď to na první pohled vidět už nebude....
Ale je to opravdu nefér vůči těm, co to zaplatili a teď jim to bude ukazovat to samé, co certifikát zadara od LE.
No, zámeček a cokoli neznamená, že browser neposkytuje antiviru klíče bokem. Celé EV je zbytečné už dávno.
No to je celé pěkné, ale jak teď ověřit, že když v hypotetickem případě jdu (poprvé) na stránky bankax.cz a přesměruje mě to na nejlepsiucetnasvete.cz kde pak kliknu na odkaz založit účet a to mě hodí na bankax-cz.cloud.com, že jsem pořád tam kde chci být a ne někde u útočníka? S EV jsem se koukl a viděl že pořád cert patří bankax, ale teď mě někdo poraďte kde bude ta informace dál (za předpokladu, že EV skončí)
Jak uz tu bylo napsano mnohokrat. EV zatim nekonci, POKUD BY se prestal v budoucnu vydavat, zustane tu jeste OV, coz je prakticky to same.
A to ze jsi na spravnem miste ti prozradi certifikat, akorat to neni pekne v URL radku ukazane(coz se mi osobne take nelibi). Kdyz si alespon v Chrome/Chromium kliknes na ten zamecek v URL radku, je tam polozka Certifikat. Kdyz na ni kliknes zobrazi se ti informace o certifikatu a to hlavne komu by vydan -> Organizace (O) coz je informace co se do ted vypisovala do URL radku.
Příklad se založením účtu v bance je špatný, protože v takové bance, kde je zakládání účtu roztroušeno po různých doménách druhé úrovně svědčí o neprofesionalitě banky. Když už bych se rozhodoval, tak si ten certifikát rozkliknu a přečtu si komu patří doména.
Lepší příklad je spíš při placení v eshopu. Jdu do eshopu, kde mě při výběru "bezhotovostní platba platební kartou" přesměrují na web třetí strany. A tady už je to skutečně masakr.
případ č.1
při platbě mě přesměrují mě na web gopay.com, nebo paypal.com, atp.. adresa je vidět v horní liště prohlížeče a lze rozkliknout certifikát do detailu.
pokud doménu poskytovatele platební brány znám a používám a je bez problému, zaplatím.
Když neznám, například je to nějaká platební brána z jiného kontinentu, například z Číny (nemám nic proti Číně), tak si to jdu koupit radši jinde.
případ č.2
při platbě se zobrazí web platební brány v iframe, nebo v podobné šílenosti, že adresa platební společnosti není vidět. tady se už vůbec neobtěžuju detektivní prací jakou je například přepínání prohlížeče do vývojářského režimu a studování http hlaviček a rovnou jdu do jiného eshopu.
Závěr:
EV chybět nebude. Název společnost u EV neznamená nutně správnou identifikaci z pohledu uživatele. Firma se může jmenovat ČSOB a mít certifikát EV... a nějaký jouda z Číny si zaregistruje CSOB u certifikacni autority v Číně taky jako EV. Laik si nevšimne, kdo to podepisoval a nemusí si všimnout ani chybějící diakritiky.
U té banky je ovšem problém i když je vše na jedné doméně. Založíte si účet v Komerční bance – a na webu pak jdete na mojebanka.cz. Je to web Komerční banky nebo není? Dneska to přesměrovává na login.kb.cz, ale nevím, zda to na doméně kb.cz dál vydrží – dříve to tak rozhodně nebylo.
A tohle je přesně ten případ, kdy jméno v URL má dobrý smysl – protože já primárně komunikuju s institucí z „kamenného“ světa, a potřebuji si ověřit, že komunikuju opravdu s ní. U internetových firem, které známe podle domény, je to něco jiného, tam je primárním identifikátorem ta doména (a často ani nevím, jak se jmenuje firma, která je za tím). Ale navštívit web instituce, kterou jinak primárně znám ze světa mimo internet, je časté a mělo by to být bezpečné.
nějaký jouda z Číny si zaregistruje CSOB u certifikacni autority v Číně taky jako EV
To je ale obecný problém certifikačních autorit, mělo by jich být méně a důvěryhodnější. Bylo by fajn, kdyby se podařilo dotáhnout dál certifikáty eIDAS – u certifikátů vydaných dle eIDAS zobrazovat v adresní řádku vlaječku EU a u OV certifikátů (případně EV) tam zobrazovat jméno.
No, tak ty banky budou "muset" používat rozumnou doménu, to je až tolik snad bolet nebude. No, marketingové žvásty apod. by asi mohly pořád nechat na jiných.
> nějaký jouda z Číny si zaregistruje CSOB u certifikacni autority v Číně taky jako EV
Jestli tomu dobře rozumím, jiný jouda si založí společnost "CSOB" v Číně a pak mu EV validace pochopitelně projde. A rozdílu si ani před změnou v adresním řádku nebude jednoduché všimnout.
No, tak ty banky budou "muset" používat rozumnou doménu, to je až tolik snad bolet nebude.
Super, takže CZ.NIC konečně zavede IDN do TLD .cz, aby KB mohla začít používat rozumnou doménu komerční-banka.cz? Cokoli jiného je pořád jen doména, která je více či méně podobná oficiálnímu názvu banky.
No, marketingové žvásty apod. by asi mohly pořád nechat na jiných.
To považuju za nebezpečné. Pokud bude mít uživatel u stránky s marketingovými kecy pocit, že je na stránce banky, nebude už znovu kontrolovat adresu třeba bankovnictví, pokud klikne na nějaký odkaz na té stránce. Když považuje stránku za důvěryhodnou, bude věřit i odkazům. Pokud uživatel vůbec něco zkontroluje, bude to jen první stránka, na kterou se dostane.
Jestli tomu dobře rozumím, jiný jouda si založí společnost "CSOB" v Číně a pak mu EV validace pochopitelně projde. A rozdílu si ani před změnou v adresním řádku nebude jednoduché všimnout.
Toho, že „CSOB [CN]“ není „ČSOB, a. s. [CZ]“, by si uživatel měl všimnout. Když už neví, že oficiální název (který musí být na certifikátu) je „Československá obchodní banka, a. s.“, ta zkratka státu a chybějící „a. s.“ by mělo trknout každého.
Vážně si myslíte, že existuje někdo, kdo ví, že si v prohlížeči má zkontrolovat jméno z EV certifikátu vypsané v adresním řádku, a zároveň nebude vědět, co znamená ta zkratka [CZ] nebo [CN] za jménem? I kdyby někdo takový byl, můžeme ho připočítat k těm, kterým je EV certifikát k ničemu – pořád ale ještě zbývají ti, kteří si ten název zkontrolují a kterým teď prohlížeče zobrazením jména z certifikátu pomáhají.