Názory k článku
NÚKIB: klíčové informační systémy musejí zabezpečit e-mail pomocí DNSSEC, TLS a DANE

...a dopadne to jak s IPv6.

Ne nutne... NUKIB precijen nejake paky ze zakona ma...

Nevěřím tomu, nejen dle přispěvatelů zde v diskusi není správa certifikátů na e-mailových serverech (_!_) . Proti tomu je nasazení IPv6 na web úplnou trivialitou.

Neni to jen formalita? Snad se nepletu, ale predpokladam, ze "kriticke organizace" to maji jiz davno a udrzuji sve systemy na maximalni aktualne dostupnou bezpecnosti praxi.

Kritické organizace to asi již mají, ale na jaře 2021 spadlo pod kybernetický zákon dalších cca 45 organizací a ty teď zjišťují, že nemají pro naplnění zákona ajťáky, finance ani zkušenosti. Většina ntěch emocnic má nyní vypsán nábor na Manažera Kyb.Bz jenže... co chcete když nabízí 50.000Kč hrubého?

No, na jedné straně chtějí DANE, ale nevoní jim self-signed cert. Tohle moc smysl nedává.

Trošku to bohužel devalvuje ten bod 1.3.:

1.3. Certifikáty všech SMTP serverů uvedených v MX záznamech jsou validní, vystaveny uznávanou certifikační autoritou a s doménovým názvem odpovídající názvu MX záznamu daného serveru.

Tohle je úplně zbytečný požadavek, protože shoda MX jména se jménem certifikátu se při doručování nikdy nevyhodnocuje. Zároveň to ale znamená víc práce pro adminy, kteří musí zařídit, aby se certifikát pravidelně obnovoval a pokud se během obnovy mění jeho veřejný klíč, aby došlo i k aktualizaci příslušných TLSA záznamů. Ty je navíc nutné aktualizovat v předstihu - tedy vystavit nové - provést změnu - smazat staré.

Je zde velké riziko, že se některý z těchto kroků nepovede, výsledkem čehož bude rozpor mezi TLSA záznamy a certifikáty serverů, což povede k nedoručitelnosti pošty pro danou doménu.

Přitom použití self-signed certifikátu, jehož otisk je v TLSA záznamu přináší přesně stejnou úroveň bezpečnosti a je pro adminy bez starostí.

Podle mne je důvod, aby bylo bezpečné obojí. Tj. aby certifikát správně ověřil ten, kdo ověřuje DANE, ale neřeší certifikační autority; a aby certifikát správně ověřil i ten, kdo důvěřuje uznávaným certifikačním autoritám, ale neověřuje DANE. Proto je potřeba, aby měl server v pořádku obojí – a toho se prakticky dosáhne jenom tím, že to bude dostatečné množství důležitých klientů ověřovat.

No je to zase všechno přesložitěné. Že by NÚKIB třeba dal k dispozici nějaký videonávod nebo prostě něco srozumitelného, jak to zařídit aby to šlapalo jak s Exchange tak nějakým populárním *NIXovým emailovým serverem třeba Postfixem, to holt ne.Tady zase budou lidi za tabulkový plat zkoumat, jak to teda jako udělat správně, aby to jako prošlo nebo se budou vypisovat drahé zakázky, aby jim nějaký expert poradil, jak na to.

Mezitím tu máme různé velmi populární registrátory domén, kteří DNSSec zapnou jen v prémiové variantě za dodatečnou úplatu. Ehm, GoDaddy. Jako dá se to převádět někam jinam, ale kam? Kde je to dobré? Kde mají rozumné API pro automatizaci? Kde může člověk platit nějak rozumně? Bude to mít dobrý výkon celosvětově?

Papír snese prostě hodně...

12. 10. 2021, 01:29 editováno autorem komentáře

aby se certifikát pravidelně obnovoval a pokud se během obnovy mění jeho veřejný klíč, aby došlo i k aktualizaci příslušných TLSA záznamů. Ty je navíc nutné aktualizovat v předstihu - tedy vystavit nové - provést změnu - smazat staré.
To sice ano, ale můžete použít
_25._tcp.host in tlsa 3 1 1
Pak se kontroluje obsah certifikátu, který se nemusí měnit - pokud při obnovení zachováte CSR.
Dá se to pěkně automatizovat (tedy před nasazením obnoveného certifikátu i kontrolovat). Nic extra složitého:

printf '_25._tcp.%s IN TLSA 3 1 1 %s\n' $srv \
    $(openssl x509 -in $pem -noout -pubkey |
        openssl pkey -pubin -outform DER |
        openssl dgst -sha256 -hex|cut -f2 -d" ")

pokud se během obnovy mění jeho veřejný klíč
pokud při obnovení zachováte CSR
Vždyť to Ondřej napsal, že jde o případ, kdy se veřejný klíč mění. Přičemž některé automaty na vystavování certifikátů nedávají na výběr a vždy vytváří novou klíčovou dvojici.

Přičemž některé automaty na vystavování certifikátů nedávají na výběr a vždy vytváří novou klíčovou dvojici.

Vždycky se dá zvolit složité řešení: tedy použít automat (nebo ho tak mít nakonfigurovaný), že se pořád generují nové csr a private key, pak každé 2 měsíce (Let's Encrypt) modifikovat TLSA v DNS...
No a anebo si automat nakonfigurovat (a když to neumí, tak přejít na jiný), aby mi csr nechal na pokoji. Pro certbot stačí --reuse-key
Zásada KISS.

No, a celé vlákno začalo správnou připomínkou, že složitá řešení mají tendenci se častěji rozbíjet – protože každý z těch více kroků může selhat.

Víte, co zásada KISS znamená? Rozhodně to není doporučení používat složitá řešení, právě naopak.

To jsem teda upřímně zvědav, jak tohle dopadne.

Povinné použití TLS a validace certifikátů u odchozí pošty, to bude masakr. Ale pokud to projde, dostane se ČR na špičku v používání TLS na e-mailových serverech. Aspoň se budeme moci chlubit i něčím jiným než DNSSEC.

Ne ze bych to nejak dlouho studoval, ale myslim, ze kontrolu certifikatu protistran nevynucuji (nastesti :) ). Jen DANE, pokud existuje TLSA zaznam.

Validovat certifikáty dle opatření není třeba (jen dle DANE), SMTP server ale musí mít validní certifikát.

12. 10. 2021, 12:26 editováno autorem komentáře

Bude povinné ověřit certifikát proti DANE, zároveň servery klíčových informačních systémů budou muset mít platné certifikáty – takže nejjednodušší konfigurace bude zapnout plnohodnotnou validaci.