Mozilla také zkrátí platnost HTTPS certifikátů na jeden rok

Dodejme, že certifikační autorita Let's Encrypt vydává certifikáty na 90 dnů a díky automatizovanému procesu to pro správce nepředstavuje žádný problém.

Podle mě je toto dost diskutabilní. Za prvé, rizika nevymizela. Z menší části se snížila, z větší části se ale jen přesunula jinam. Jako praktické problémy vidím:

1. ACME klienti (i internetové kuchařky) často nastavují well-known adresář jako sdílený pro celý server - tedy křížem pro domény. Na serverech, kde se potkávají weby více zákazníků, to otevírá reálnou možnost získat certifikát za jiný web hostovaný na stejném stroji.
2. Neexistují žádné standardy, ani doporučení, ani tlak na to, aby poskytovatelé DNS služeb (např. registrátoři) měli dostatečně zabezpečený přístup do DNS. Správa DNS je dnes obvykle chráněna jen jménem a heslem, bez 2FA. Reset zapomenutého hesla probíhá e-mailem, který lze odchytit nešifrovaný.
3. DV ověření je poměrně k ničemu. V případě problému nevede spolehlivě k identifikaci osoby. Certifikát tedy slouží pouze pro zajištění šifrování, nikoliv v tomu, aby něco ověřoval (= certifikoval).

Celá snaha kolem certifikátů s krátkou platností a totální příklon k DV ověření podle mě nijak reálně bezpečnost nezvýšil. Kdo chce, může si vše nastavit bezpečně. Kdo nechce (neumí), je ve stejném srabu, jako předtím. Co se zvýšilo je náročnost procesů, náklady (byť po haléřích, ale miliardykrát) rostou.

Co naprosto chybí, je kontrola správců, jaké certifikáty mohou vzniknout. Částečně se tomu dá zabránit pomocí CAA záznamů. Jenže, CAA záznam musí být nastaven, výchozí politika je permisivní. Chybí záznam (třeba chybou) - certifikát vznikne. Ve chvíli, kdy je CAA nastaven, certifikační autorita vydá DV certifikát každému, kdo provozuje web po doménou; ve větších firmách by bylo žádoucí mít mechanismy pro řízení vydávání certifikátů (např. rozlišovat hlavní správce vs. externí dodavatelé, provozující menší aplikace na téže doméně).

Summa summarum, je to mnoho povyku a mnoho práce, ale výsledek neodpovídá. Šifrujeme, abychom šifrovali. Měli bychom šifrovat, abychom chránili. To se jaksi vytratilo.

To šifrování je k ochraně poslední míle, aby do provozu nemohli lézt různi vykukové (ISP, WiFi script-kidies). Kdyby se chtělo, mohlo se implementovat DANE a certifikáty nechat jen pro ty kteří opravdu chtějí být certifikováni. A proč se nechtělo? No to se zeptejte "důveryhodných" certifikačních autorit a tvůrců browserů.

DANE naráží na nepodporu DNSSEC. V Česku jsme na tom sice velmi dobře, ale pořád zdaleka ne všechny resolvery validují a ne všichni mají podepsanou zónu. Zbytek světa je na tom s DNSSEC spíš bídně, ve spoustě sítí se k podpisům vůbec přes místní resolver nedostanete. V takové situaci není možné zásadní bezpečnostní prvek o DNSSEC opřít.

Nezpochybňuji nutnost použití DNSSEC, ale prohlížeč by mohl klidně dělat validaci sám. Třeba DoH naimplementovali velmi rychle, že ano. A i bez DNSSEC, by mohl DANE použít kdo by chtěl a zkontroloval si klíče jinak, stejně jako například u SSH.

Ano, DANE je možné volitelně ověřit, ale to lze i teď. Třeba na LinuxDays.cz je v zóně správný záznam a lze ho správným nástrojem ověřit.

S DANE je to pravda, víc věcí by se rozsypalo, než by se ochránilo.
Mě zaráží (nebo vlastně nezaráží, mám na to názor), že tyto aktivity ženou dopředu hlavně vendoři browserů, ale zároveň v něm ponechávají "díry jako vrata". Trochu mi to brnká na nervy, pořád se nemůžu zbavit pocitu, že hlavním cílem bylo přinést náklady malým provozovatelům a poskytovatelům, kteří nemají takové možnosti realizovat úspory z rozsahu. Druhé, co mě napadá je i to, že je samozřejmě daleko jednodušší si nejprve (aspoň částečně) připravit svoje služby a teprve následně zavést a prosadit změny, na které jsou už v tu dobu připravení. V globálním měřítku se takový postup projeví nějakým tím procentíčkem výhody proti nepřipraveným konkurentům (nebo jim to odčerpá peníze, aby se rychle dopřipravili).

Ad 1. – Generičtí ACME klienti jsou určeni pro použití na vlastní serveru, ne pro sdílený hosting. Pokud bude mít sdílený hosting nastavený taková oprávnění, že klienti budou používat ACME klienty dle vlastního výběru, budou mít oprávnění přenačíst konfiguraci serveru kvůli přenačtení certifikátu, budou mít úplně jiné problémy, než že mohou vystavit certifikáty pro jinou doménu.

Ad 2. a 3. – To vůbec nesouvisí s platností certifikátů ani s LE, to je prostě obecná nevýhoda DV certifikátů.

Krátká platnost certifikátů s DV certifikáty nijak nesouvisí, stejný smysl dává i u OV a EV certifikátů.

Kontrola ze strany správců je věcí organizace. Pokud jako své statutární zástupce určí organizace 50 lidí, bude těch 50 lidí moci získat EV certifikát – a také mnohem horší věci. A je to chyba té organizace. Pokud dá ta organizace 50 lidem právo spravovat DNS, bude těch 50 lidí mít možnost získat DV certifikáty, případně tu možnost delegovat dalším lidem. Opět, je to chyba té organizace. Ano, může dojít k chybě, že CAA záznam nebude nastaven. Stejně tak může dojít k chybě, že nebude nastaven A záznam – což bude mnohem větší problém. A mechanismy kontroly A a AAAA záznamů se dají použít i na kontrolu CAA záznamů. Stejně tak politiky.

Takže organizace, která to chce mít zabezpečené, má tu možnost. Pokud to někdo zabezpečit nechce, žádným způsobem ho k tomu nedonutíte. Šifrujeme, abychom chránili. Pokud se někdo spokojí s malou ochranou, má jí. Pokud někdo chce větší ochranu, nic mu nebrání v tom, aby ji měl.

Teď je otázka, k čemu tedy vlastně slouží CA/B fórum. Koordinace postupů certifikačních autorit a prohlížečů to zjevně není, když se o zkrácení platnosti certifikátů neprve hlasuje a když hlasování nedopadne podle představ některých členů, ti se klidně utrhnou a změnu prosadí z vlastní iniciativy.

Tohle moc nevypadá jako fórum hledající konsenzus mezi zájmy prohlížečů a certifikačních autorit, tohle vypadá spíš jako nástěnka, na kterou výrobci prohlížečů svévolně umisťují své nápady a certifikační autority nemají žádnou šanci odporovat.

Jako každý podobný panel. Slouží k tomu, aby firmy hledaly aspoň nějaký společný zájem / průnik zájmů. Díky tomu může být aspoň část vývoje koordinovaná mezi vendory. Nevylučuje se to s tím, že si každý zároveň s tím může "razit svou", i tak to částečně pomáhá.

Blbé na tom je, že při hledání toho konsensu se často zvolí bezzubý kompromis. (Následně pak si pak začne razit své vlastní představy - jako v tomto případě).

O tom, co je dobré pro uživatele, nebo pro bezpečnost, jde až v druhé řadě. Vychází se z toho, že pokud nově vzniklé produkty (na nových standardech) budou úspěšné, tak to indikuje, že je to dobré i pro uživatele. Nezávislí (bezpečnostní) odborníci by patrně volili jiná řešení.

Je to trochu přihlouplé a od veřejnosti si to zaslouží spíš zdrženlivý přístup, než nekritickou pochvalu.

Na druhou stranu, všechny CA, kterým Mozilla důvěřuje, jim potvrdily, že platnost vydávaných certifikátů zkrátí: https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 Takže jakási dohoda s CA tam je, i když šla mimo CA/V fórum a asi byla dost vynucená postupem Applu.

CA nemají jinou možnost. Pokud prohlížeč vyhlásí neplatnost nehledě na datum platnosti v certifikátu, byla by pro CA obchodní sebevražda, kdyby dál vystavovali certifikáty s delší platností.

To není tak úplně pravda. Certifikáty se používají i na jiných místech než na webu, třeba pro API komunikaci interních systémů. Ano, je k tomu možné použít interní CA, ale až dosud bylo pro spoustu institucí jednodušší používat na všechno jednu CA. V takovém případě by jistě spousta správců ocenila vydání certifikátu na dva roky i s tím, že by autorita držitele varovala, že takový certifikát nebude důvěryhodný pro některé webové prohlížeče.

@Ondřej Caletka

To je pravda. Nevěřím ale, že na těchto případech mají CA založený základ svých příjmů.

To, ze funguje LE 90 dni je jedna vec. To, ze certifikaty se musi do infrastruktury nasadit a reloadovat/res­tartovat sluzby, to je vec druha !!

To takhle se bude chovat i k certifikátům od interních CA, kde to je celé provozované interně v izolovaných sítích, kde se běžně dávají certifikáty s platností 2-5 let? Tak to bude nádhera a další opruz...

Proč tak dlouhá platnost? Co kdyby se výrobci prohlížečů domluvili a zkrátili platnost certifikátů na 30 dní. Nebo možná ještě lépe v zájmu bezpečnosti na celých 30 minut.

Mimochodem, když jde o bezpečnost - možná vývoj nesleduju zas tak důkladně, ale zaťím jsem, neviděl prohlížeč, který by po zadání url bez protokolu nejprve zkusil https a teprve když by nedostal odpověď, šel by na http. Zatím se to řeší přes servery, kdy na něm musí běžet nebezpečné http jenom kvůli tomu, aby se vygeneroval přesměrování na https. Přímo na http by prohlížeč šel pouze při výslovné zadání protokolu http. Odpadl by pak celý opruz s hsts a celý svět by byl vesele bezpečnější.

Jediné, co je nedostatek https, že už neplatí, že se internet nechá prohlížet čímkoli (jakýmkoliv prohlížečem).

Existují i návrhy na takto dramatické zkrácení platnosti certifikátů, zatím jsme u jednoho roku a velmi pravděpodobně budeme zkracovat dál. Uvidíme, kam až dojdeme.

Prohlížeče zatím jako výchozí používají HTTP na portu 80, ale v dlouhodobém plánu je tu logiku otočit a mít jako výchozí HTTPS na portu 443.

Už teď je možné si to u svého webu obrátit pomocí hlavičky HSTS, která prohlížeči řekne, že na daném webu se používá jen HTTPS.

Nebo https://addons.mozilla.org/cs/firefox/addon/https-everywhere/.

To rieši problém pre Vás, ale nie pre návštevníkov Vašich stránok.

"checkovat CRL/OSCP paralelně s načítáním stránek"
toto je sice technicky proveditelne ale nebezpecne