Ja áno od toho istého autora vo verzi 1, táto verzia2 mohla byť ešte lepšia
https://www.youtube.com/watch?v=rwbs-PN0Vpw&feature=youtu.be
akurát nesúhlasím s:
> Pokud se netrefí, práce se zahodí. "Není to na škodu,
>protože nás to nic nestojí. Vždycky se to predikcí může jen zlepšit."
Ono nás to stojí spotrebovanú elektrickú energiu navyše, v prípade, že sa prediktor netrafí.
Uz RFC2142 dlouhe roky definuje nejake elementarni kontakty. Jenomze se na na to RFC vseobecne kasle a moc se o nem nemluvi. Navrh k security.txt jde sice trosku dal - nicmene porad plati, ze nejjednodussi forma usnadneni kontaktu pro hlaseni chyb je existence emailu/aliasu security@ na dane domene (a ostatne i ten draft to zminuje, ze mailbox security@ by mel existovat).
Jestli ono to nebude tim, ze kdybys opravdu mel vsechny ty vyjmenovany maily zprovozneny, tak ti tak zhruba zestonasobis mnoztvi spamu ktery ti bude chodit. A pak si to vynasob trebas poctem domen ktery spravujes, a vyhodnot si , v kolik miliardtinach promile ti tam prijde smysluplna informace.
Problematiku spamu to ten draft neresi a nevyresi. Spammeri si ten security.txt muzou stahnout a z nej vypreparovat kontaktni emaily zrovnatak. To se u jinych forem zverejnovanych emailovych kontaktu davno deje.
A i kdyz ulozeni emailu neni dle toho draftu mandatorni (jde se odkazat na nejaky webovy formular ci telefon), je otazkou zda to bude fungovat a splni to ten slibovany cil - zvlast ty formulare, kde si je kazdy muze udelat po svem v konecnem dusledku muzou od nejakeho reportingu spise odrazovat (jejich autori umi byt kreativni). A zacilit spam i na webovy formular ci telefonni cislo dnes take az takovy problem neni.
Článek pěknej a je v něm i dost inspirace, ale odkaz na Have I been Pwned špatně. Má být https://haveibeenpwned.com/ .
nekolik dotazu k odstavci "Tomáš Hála SMTP...."
* ... v případě poštovního řetězce se už uživatel nemá možnost se nic takového dozvědě
na gmailu kdysi zavedli/chteli zavest "not encrypted warnings" (https://www.theregister.co.uk/2015/11/16/google_wants_to_add_not_encrypted_warnings_to_gmail/) - jak je na to gmail nyni, hlasi ty warningy? (nemam gmail, tak nevim)
* Pro kontrolu TLSA stačí jen DNSSEC validující resolver
opravud je potreba pro kontrolu TLSA zaznamu DNSSEC, nejde to i bez nej (pominu-li oslabeni bezpecnosti)? zbezne jsem kouknul na par RFC (7671, 6698) k TLSA a o vyzadujicim DNSSECu jsem se nedocetl (mozna jsem prehledl)
Dix
No, v RFC6698 se v kapitole 1.3 dočtete třeba tohle:
This document defines a secure method to associate the certificate that is obtained from the TLS server with a domain name using DNS; the DNS information needs to be protected by DNSSEC.
Odvolávek na DNSSEC je tam víc, stejně jako v RFC7671.
Je to tak. Pokud zveřejníte TLSA záznam, tak bez jeho ověření skrze DNSSEC bude ignorován. Musí to tak být. Jinak by ověření certifikátu bylo podvrhnutelné stejnými způsoby, jakými můžete podvrhnout např. samotné MX záznamy a tedy by to nedávalo prakticky žádnou přidanou hodnotu oproti stavu bez TLSA.
A proc neignorujes to IPcko? Jakejkoli zaznam v DNS bez DNSEC je o milion radu duveryhodnejsi informace, nez jakekoli libovolnou CA podepsanej cert. Uz minimalne proto, ze zaznam v DNS si muze kdokoli kdykoli mnoha ruznymi zpusoby overit, ale to, ze nejaka CA podepise milion certifikatu pro domeny, u kterych jejich spravci/drzitele vubec netusej ze by nejakej cert chteli, nemas absolutne zadnou moznost zjistit.
Nedava, ale tenhle problem neresi ani RFC 8461 alias MTA-STS (ktere je chte-nechte na DNS zavisle zrovnatak... jako vsecko) - ktery paradoxne protlacuji nejvic prave ti, kterym se do zavadeni DNSSEC moc nechce.
Nejsem obhájce MTA-STS, ale není pravda, že ten problém neřeší. Pokud mi někdo komunikaci naruší, tak všichni, kdo mají z dřívější komunikace záznam v cache, jsou chránění a email u nich zůstane ve frontě, dokud nebude cesta na MX zase nenarušená. Stejně jako s HSTS. Reálný efekt to tedy má (resp. bude mít, až to někdo implementuje). Jiná otázka je, jak je takové řešení vhodné z pohledu komplexity a systematičnosti. Bez ohledu na MTA-STS je implementace DNSSEC dobrý nápad i z mnoha jiných důvodů. DANE je jen jeden z nich.
To ale predpoklada, ze uz jsem s dotycnym cilem nekdy komunikoval (abych mel neco v cache). Pokud jde o prvni kontakt, pak uz tu i ta cache muze byt podvrzena a o naruseni komunikace se clovek tim padem nedozvi. Ve vysledku to vyrabi falesny pocit bezpeci. Jenze uz v navrhu jsou vratka lehce pootevrena a v nekterych situacich utoku nezabrani. To mi prijde na standard tvoreny v 21.stoleti jako dost velky fail.
MTA-STS zapojuje nesmyslne dalsi protokol (krome DNS, bez ktereho se beztak neobejdu jeste HTTPS). Duvody RFC uvadi a jednim ze stezejnich je prave nevole k implementaci DNSSECu a vymysleni workaroundu, kdy se clovek skrabe levou rukou za pravym uchem...
Srovnavani s HSTS ma jednu vadu - jako "uzivatel" muzu sve zarizeni primet k tomu, aby komunikovalo primarne zabezpecenym kanalem (tim, ze mu reknu, ze chci pouzit https). Jenze to SMTP pro MTAtoMTA komunikaci nemuzu, ani kdyz se na hlavu postavim - zadny standard mi to fakticky ani neumoznuje. Pouze muzu doufat, ze mi to STARTTLS nikdo po ceste na tcp/25 "nesezere".
Danny, po technicke strance mas samozrejme pravdu a opakuji, ze nejsem obhajce MTA-STS, ale porad nesouhlasim s tim, ze to ten problem neresi. Resi ho. A pokud je o problematiku prvniho kontaktu, je tu stejne reseni jako u HSTS, tedy MTA-STS preload list ;-)
https://starttls-everywhere.org/policy-list/
A tady vysvetleni k motivaci:
https://www.eff.org/deeplinks/2018/06/announcing-starttls-everywhere-securing-hop-hop-email-delivery
Jsou taci, co proste DNSSEC zavadet nechteji a je pravda, ze za poslednich nekolik let se jeho adopce moc nezvysila. Ani me to netesi, ale jsou to fakta.
s radosti jsem si vyslechl prednasku pani Koskove Triskove. Mam dve poznamky:
... nekde v polovine prednasky rika 'na to uz jsem stara'
s tim naprosto nesouhlasim, pani inzenyrka vypada podle mne bezva
Vyrazovy styl mne dost prekvapil. Priklad:
... dnes vam chci ukazat 4 embedded systemy ...ták
...jako prvni se podivame na free RTOS a na AMZON free rtos ... ták
... jake jsou vyhody rtos systemu ... zde je prehled ... ták
Je to bezne na Liberecku, ze se za kazdou druhou vetou rekne 'tak' ?