Vlákno názorů k článku MTA-STS: bezpečné doručování pošty s platnými TLS certifikáty od Rhinox - Jak sem byl spocatku nadsenej, tak ke konci...
-
Rhinox (neregistrovaný)
Jak sem byl spocatku nadsenej, tak ke konci prislo vystrizliveni. Spoustet https-servr kvuli kazde domene pro kterou sbiram postu je mirne receno neprakticke.
Proc tech par zaznamu z mta-sts.txt radsi nedat rovnou do dns? Kazdou (mail) domenu nekde obhospodaruje nakej dn-server (kam stejne jiz musim pridat zaznam pro mta-sts.domena.tld), jenze ne pro kazdou mail-domenu musi nutne jiz bezet web-servr...
-
Petr M (neregistrovaný)
Aha, takže pokud jde o bezpečnost, tak se budeme řídit tím šlompem, co na to nejvíc se*e? No to je hezký...
DNSSEC je základ. A doména snad má správce.V případě DNSSEC by mělo být postupováno takhle:
1) Důrazný upozornění správce domény, že DNSSEC bude povinný a bez toho se jejich zákazníkům plno věcí rozbije.
2) Pokud se to do měsíce nezmění, pustit info novinářům v dané zemi, že se "rozbije internet" vlivem jejich registrátora.
3) Za měsíc po tom DNSSEC prostě v infrastruktuře vynutit. V ten okamžik rázem to DNSSEC bude. -
DannyStříbrný podporovatelProblemem a "dirou" v MTA-STS je stale ta zavislost na DNS. I dotaz na samotnou existenci politiky muze byt pozmenen ci zcela potlacen. Stejne jako muze byt potlacene STARTTLS u SMTP relace (coz mimochodem delaji i nektere firewally, aby mohly provadet dalsi inspekci) - i kvuli cemuz se MTA-STS vymysli. Ze je samotna politika transportovana na HTTPS je irelevantni. V extremnim pripade by slo ziskat i DV certifikat pro zmineny policy server, ktery je vzdu ve tvaru mta-sts.[domena] (samozrejme, ze to je slozitejsi a narocnejsi, ale nikoliv nemozne a nepredstavitelne). Bezpecnost je o nejakem retezu a pokud je slaby jeho prvni clanek (a tim DNS bez DNSSEC bezpochyb je), tak bytelny zbytek okolo to uz nezachrani.
Podstata problemu se vubec neresi a to bych videl jako zakladni selhani - i tech "velkych", co MTA-STS standard predlozili a kterym se do DNSSEC nechce (Google, Microsoft...). Oportunisticke sifrovani na komunikaci mezi MTA stale preziva a vymysli se vselimozne obezlicky kolem. Nabizi se otazka, proc se oportunistickeho sifrovani proste nesnazi zbavit. I u DNS jsme se uz dockali standardu, ktery na jinem portu ma TLS mandatorni, HTTP(s) tu mame uz sakra dlouho, Telnet nam taky vystridalo SSH... ale u SMTP v pripade MTA-to-MTA komunikace porad nic. Samozrejme, ze ta zmena nebude hned - ale nekdy se zacit prece musi. Proc delat veci jednoduse - kdyz to jde slozite.
-
DannyStříbrný podporovatel
Napadnutelne to je samozrejme i pozdeji. Do DNS staci indikovat zmenu politiky a do cesty vhodne nastrcit webovy server dle scenare viz vyse - ktery podvrhne i zbytek, tedy i celou jinou politiku. Jisteze to je uz hodne komplikovane a narocne na realizaci, ale nikoliv uplne nemozne. Proste takova bezpecnost "napul".
-
DannyStříbrný podporovatel
Moznosti je.... DV certifikat nebo treba natlak govermentu na nejakou CA - bez ohledu na CT (ktere pomuze spise s post-mortem analyzou)... aneb jedna vec je ta data nekde verejne "mit", druha realne - a v realnem case - kontrolovat, ze nejaka CA "nahodou" vystavi certifikat, co by nemela... takove incidenty tu uz ostatne i byly, to nejsou zadne teorie :-)
Samozrejme, pokud mam implementovane DANE (na domene s DNSSEC) a otisk aktualne pouziteho certifikatu v TLSA zaznamu, tak si rovnou muzu overit, ze komunikuji se spravnym serverem a ne nejakym podstrcenym nekym na puli cesty. V realu je cely DNSSEC "chain-of-trust" vic pod drobnohledem a obecne hlidatelne jednoduseji, nez chovani jednotlivych certifikacnich autorit - kde problematicnost kontroly praxe opakovane dokazala.
ČLÁNKY DO MAILU