Názory k článku Maximální délka platnosti HTTPS certifikátů bude zkrácena na 1 rok

Znamená to tedy, že dvouleté certifikáty vydané do 1. 9. bude Safari uznávat celé dva roky?

To by mne taky zajímalo. ;)

Podle toho co oznamili budou, kdyz se rusily 3 lete, tak take ty uz vystavene zustaly platne po cele 3 roky.

Vsechny pripady, kdy se nasilne rusily certifikaty pred koncem jejich platnosti, byly spojene se ztratou duvery bud k CA jako takove nebo k nekterym jejim korenovym/mezi­lehlym certifikatum.

Je to velmi pravděpodobné, protože se tímhle způsobem dělají všechny změny v pravidlech. Od určitého data platí nová pravidla, certifikáty vydané před tímto datem podléhají starší verzi pravidel. Takhle to bylo s SHA-1, Certificate Transparency, předchozím zkracování maximální platnosti a podobně.

Minimalne Digicert na to uz reagoval a zavadi predplatne, takze kdyz si nekdo objedna dvoulety certifikat, realne to bude znamenat, ze si bude moct v prubehu dvou let vystavit libovolne mnozstvi certifikatu s kratsi platnosti. Ty prubezne certifikaty se budou vystavovat bud klasicky na webu a nebo i pres ACME protokol.

Safari navic bude verit "starym" dvouletym certifikatum, takze pocitam ze pred pocatkem platnosti opatreni si hodne lidi nakoupi dvoulete, aby meli chvili klid.

Autor píše, že díky tomu, že nefunguje dobře zneplatnění certifikátu, má smysl zkrátit jeho maximální platnost.
Ale kde je ta ideální délka platnosti? Den, hodina, dvě sekundy?
Nezdá se mi, že by zkrácení platnosti nefunkční revokaci nějak řešilo.

Přesně. I půl roku je z hlediska internetových podvodů neskutečně dlouhá doba. Zkracování platnosti nic neřeší.

Tady bojuje několik směrů.

Jedni (a k nim patřím já) by rádi viděli, aby certifikát opravdu něco "certifikoval". Aby byla aspoň ověřena identita držitele. V tu chvíli by nebylo potřeba zkracovat platnost certifkátů, nesázely by se tak ukvapeně atd.

Druzí dávají větší přednost šifrování přenosu i za cenu menšího ověření. To je směr, který obsluhuje nejvíc Let's Encrypt. Vedlejším efektem je množství vystavených certifikátů, praktická nevyužitelnost CT, nespolehlivost revokací - které když se začnou vyžadovat, úplně to pohřbí myšlenku "HTTPS pro každého".

No a pak tu jsou technici, kteří by třeba mohli využívat HPKP. To naráží v praxi na zavedení docela přísných procesů. Když ztratíte klíč (nebo ho musíte zahodit kvůli kompromitaci), a nemáte záložní, celá služba přestane fungovat. Opět to jde proti myšlence "HTTPS pro každého".

Osobně si myslím, že technologie mají dávat rámec a možnosti, ale jejich využití by mělo být dáno zájmem stran. Znám weby, kde je šum a fuk, jestli se vůbec šifruje (potenciál škod je mizivý), nebo, když už se šifruje, tak nevadí certifikát třeba i na tři roky (a málo práce s ním).

Současný stav, kdy "rada moudrých velkých firem" píská pravidla je trochu znepokojivý a přispívá jen ke globalizaci v této oblasti. Od toho je už jen krůček ke zneužití.

Dovolím si na začátek ocitovat:
Zkracovat maximální délku platnosti certifikátů je obecně dobrý nápad z několika důvodů: tím hlavním je asi to, že některé prohlížeče platnost certifikátů vlastně nekontrolují.
Protože třeba takový nginx v klidu pošle odpověď bez OCSP statusu, pokud ji ještě nestáhl.

Měl jsem na tohle téma s Michalem menší výměnu názorů na Twitteru. Z mého pohledu zkrácení (skoro) nic neřeší. Resp. neřeší hlavní problém, který Michal popisuje - revokace. To by se musely certifikáty vydávat s platností na na hodiny/dny.

Já zkracování platnosti na rok nechci, nic mi to nepřinese, naopak. Jak píše Michal, tak mnozí výrobci prohlížečů nebo i serverů kašlou na pořádnou implementaci práci s certifikáty, včetně CRL, OCSP apod. Ale namísto aby se na ně tlačilo, ať to dělají pořádně, tak se zkrátí platnost a budou mít o důvod víc na to kašlat. A jak jsem pochopil, je to jednostranné rozhodnutí Apple proti dohodě z září 2019.

Kdyby Apple (Google, Microsoft) raději zařízl mizerné prohlížeče, které kašlou na kontrolu certifikátů, udělal by z mého pohledu pro bezpečnost podstatně víc.

PS: Za chvíli zkrátíme platnost na týdny (což stejně opět nic nevyřeší) a následuje přerod Let's Encrypt do placené autority :-).

PS: Za chvíli zkrátíme platnost na týdny (což stejně opět nic nevyřeší) a následuje přerod Let's Encrypt do placené autority :-).

Těch rizik je ve skutečnosti víc. Překlopit LE do placené autority by bylo opravdu prvoplánové. Jenže v druhém plánu ještě musíte uvažovat i o dalších zájmech. Velké společnosti mají poměrně vyřešenou práci se SSL, ačkoliv jak jste sám psal, tak zdaleka nedělají všechny kroky, které se nabízejí. Malí hráči dopředu nevědí, co napadne Google či Apple, takže se nemohou dobře (levně) připravit. Spotřebitelé se nutně z části přizpůsobí, ale z části už "zjistí", že je pro ně výhodnější přejít k velkým do cloudu a tyto necitlivě vytvořené problémy neřešit. Další část pravdy je i v tom, že absolutní šifrování dává velkým hráčům obrovskou vyjednávací sílu s vládami zemí (které zase mají oprávněný (zákonný) zájem nahlížet do dat).

Třeba autorům prohlížečů dojde, že bude lepší implementovat DANE než řešit správnou implementaci CRL a OCSP. Pokud vím, argumentem proti DANE je zpomalení při ověřování certifikátu – ale proti OCSP by DANE mohlo být rychlejší. (O CRL ani nepíšu, to má v prohlížečích smysl jen jako databáze beznadějných případů, které už jsou revokované dny a týdny.)

Rozdíl je v tom, že DANE musí chtít nastavit a udržovat ten, kdo řeší DNS. Dost často má do DNS přístup užší okruh osob, než ke správě serverů a certifikátů. OSCP má v praxi nižší práh dostupnosti než DANE. Ano, můžete namítnout, že DNS se dá delegovat - ale i to je administrativa a práce navíc. V praxi bojujete s tím, že i velké korporace mají projektové domény registrované a spravované kde kým, bojujete vůbec o to, aby někdo nastavil A/AAAA, když chcete nastavit DKIM a SPF, bojujete o to, aby nějaký nevzdělaný poloadmin vůbec věděl, co má udělat. DANE je v takových situacích nepředstavitelné. Investor pak položí jedinou otázku: bude to fungovat i bez toho, aniž bych to musel řešit a platit? A jste v koncích. OSCP si proti tomu zavede jen ten, kdo se stará o jednu jedinou malou část. Proto je v praxi OSCP lepší volba, než nedosažitelné DANE.

Autoři prohlížečů nemají skutečný zájem na bezpečnosti. Bezpečnost je pro ně dobrá jen pokud jim přináší konkurenční výhodu. Buďto je to téma, na které spotřebitelé slyší, nebo je to nástroj, jak pozlobit konkurenci. Žádný autor prohlížeče nezavede nic, co by ho mohlo poškodit u spotřebitelů. Zkrácení doby platnosti certifikátů je pro ně bezpečné: vyskočí hláška, že web nemá správně certifikát.

OCSP si nezavádí provozovatel webu, je to čistě věc mezi prohlížečem a certifikační autoritou. Provozovatel webu by mohl zavádět maximálně OCSP stapling.

Možná je na čase, aby DNS přestali spravovat polovzdělaní adminové. Ostatně nedostatky ve správě DNS argumentujete často, a bez fungujícího a bezpečného DNS nedávají DV certifikáty smysl.

Sorry jako ale DANE je mrtve, protoze ho prohlizece nikdy podporovat nebudou. Imho by sice davalo smysl kdyby byl certifikat vice svazany s url adresou napr pres DNS ale neverim ze se to nekdy stane.

Proč ho nikdy podporovat nebudou? Nemyslím si, že by odpor prohlížečů k DANE byl principiální. Webové technologie se mění. Objevují se problémy s OCSP, to by DANE umožnilo obejít. Prohlížeče začínají podporovat DoH, nebyl by problém ho rozšířit tak, aby bylo možné vyžádat si A/AAAA záznam rovnou s příslušným TLSA záznamem.

Co interni CA?

Jinak tohle je pekny problem, menit rucne crt je otravna prace (csr+overeni+vymena na serveru). Pokud nekdo rekne neco o LE, fajn, to je sice reseni, ale neresi servery nepristupne z internetu napr. za proxy, navic neresi funkcnost s automatizaci konfiguraci.

vlastní CA i dnes prohlížeče akceptují a neřeší u nich délku certifikátu, máme takhle testovací na 20 let. Předpokládám, že to zůstane.

LE a ACME není jediná cesta, existuje celá řada nástrojů pro vydávání a podepisování certifikátů (mrkni třeba na certnanny) vč. jejich distribuce, to mimochodem umí i LE a vydáváme s nim certifikáty na servery, které nejsou na internetu (je možné třeba pro ně někam tu konfiguraci generovat, připravil yum balíček nebo připravit soubory, které ručně admin nahraje).

Díky za certnanny :)

Vlastne CA prehliadace akceptuju, ale riesia u nich dlzku platnosti certifikatu rovnako, ako u verejnych.

Mame 10-rocne certifikaty v Intel AMT: Firefox ho oznaci za neplatny, ale po upozorneni sa da pokracovat. Chrome ho oznaci tiez za neplatny, preklikat sa neda a treba poznat tajny hmat, ako ho presvedcit, aby pokracoval ("thisisunsafe").

Vymena cerifikatov v AMT je dobra pakaren; nie je to ziadne "spustime acme.sh a on sa postara". Preto mame certifikaty dlhsie, ako je ocakavana zivotnost zariadenia.

Svůj domácí server, který není přístupný z netu, plánuju řešit přes API Active24 a txt záznamy. Přijde mi to docela v pohodě řešení. V nějakém větším nasazení by asi nebyl problém mít service která ty certifikáty stahuje a distribuuje nějakým zabezpečeným kanálem.

Ono to jako problem nevypada. Ale ve chvili, kdy to nekdo zkusi implementovat, narazi na vsemozne pozadavky - ruzny typy crt, nektere sluzby nepodporuji reload, robustnost, pristup do vlastniho dns, atd...

Kdybych mel infrastrukturu na puppet atd, tak je to jednodussi. Ale infra mam na ansible, coz dela zmenu crt slozitejsi.

Navic predstava, ze kazdy rok budeme uhanet zakaznika, co si crt porizuje sam, je taky nehezka.

Puvodne tohle resilo nastavene dns na jeden server, ktery certifikaty posbiral a pak prerozdelil. dneska to inteligentne resime, pres DNS challenge.

Absurdni. Na certifikaty overovane letsencrypt bych se UPLNE vykaslal. Proste client-server per spojeni vygeneruje, vymeni si a pouzije random klic a domluvi algoritmy.

To je in-transit security.

Na nejakou ochranu a potvrzeni identity (autentizace na web, citliva data) pak certifikaty, ale validovane.

Validace, ze mel nekdo pristup na server dostatecny k vygenerovani certifikatu, je uplne pro kocku. To neni vhodne ani pro in-transit sifrovani