Vlákno názorů k článku
Od 1. září se zkracuje platnost HTTPS certifikátů na jeden rok od Bluehawk - Mě tedy přijde celé to atomatizované obnovování divné....

Mě tedy přijde celé to atomatizované obnovování divné. Jde o to, aby byla data po ceste šifrovaná a nebo aby měl uživatel jakous takous jistotu, že data jsou šifrovaná a ještě mohl alespoň kvalifikovaně odhadnout s kým se baví?

Protože to první řeší kdejaký selfsign a to druhé v současné době v podstatě nic. Zkracování doby platnosti vede k jediné věci - vydávané certifikáty jsou tak slabé, jak jen to jde. Stejně tak klíče se generují (obvykle) relativně slabé.

Kdyby se chtělo, šlo by to vydávat bezpečně i na delší dobu přičemž "ušetřené" peníze by se daly vrazit do lepší validace.

Automatizace nemá nic společného s validací, vzájemně se to nevylučuje. Může klidně existovat autorita, která bude automatizovaně vydávat certifikáty až na základě platby a detailního ověření žadatele. Protokol ACME s tím počítá, kterákoliv komerční autorita ho může nasadit.

Automatizace je dobrá v tom, že se nemusíte o certifikáty starat a nedojde pak k tomu, že vám někde nějaký vyprší a přestane vám fungovat služba.

Nijak nezpochyňuji přínos automatizace jako takové, pouze nemám dobrý pocit ze situace, kdy automatizovaně nasazujeme certifikáty, generujeme klíče, čím dál tím méně o tom víme (neb to funguje "samo") a necháváme se ukolébávat pocitem bezpečí.
Jak říká jeden můj kolega, bezpečnost je drahá. My, ok ACME, směřuje k úspoře nákladů, k automatizované bezpečnosti - což podle mého názoru skončí dřívě či později těžkou kocovinou.

Takže varianta, že si to Venca napsal do kalendáře a jednou za rok to nakliká a vymění, je lepší a bezpečnější? Praxe ukazuje, že rozhodně nikoliv. Spousta služeb a webů právě na tohle nakonec narazí.

No, jsme myslím u jádra. Zabezpečení by se imo mělo rozumět. Podle mého názoru je lepší, když služba selže než když má tak zásadní věc jako zabezpečení udělánou tak, že to vlastně pořádně nikdo neví jak.
Ono to šifruje a neřve to, tak je to v pohodě...

Ne, opravdu si nemyslím, že by Venca měl jen tak něco naklikat, Venca by o tom měl něco vědět, protože se o svoji službu stará.

@Petr Krčmář

Praxe ukazuje leda tak houby. Nejcitlivější data přenášíme e-mailem, na kterém šifrování funguje oportunisticky. Největší slabinu jsme zdaleka neřešili, zato jsme se umanuli na řešení střípku bezpečnosti, který je "vidět" skrze ikonku zámečku v prohlížeči.

Naprosto "odborně" jsme se oddali tomu, že "co je vidět, to se počítá". Jako vedlejší efekt jsme naprosto devalvovali smysl vydávání certifikátů - tedy, že něco ověřuje. Nyní říkáme, že jsou "domain-validated" a zcela alibisticky neřešíme, že samotné přístupy ke správě domény jsou bídně zabezpečené - obvykle stačí kliknout na "zapomenuté heslo", které přijde e-mailem (který šifrovaně nejde).

Pravda, docílili jsme toho, že velké firmy doručí obsah uživateli, aniž by bylo možno nahlédnout byť jen do hlaviček. To jako "bonus" sebralo možnosti filtrovat obsah - což zejména firmy potřebují, i kvůli bezpečnosti.

Přínos k bezpečnosti je tedy víc než diskutabilní. Jediný zřejmý přínos je pro poskytovatele obsahu.

Bezpečnost je drahá, ale to, že něco uděláte drahé, neznamená, že to bude bezpečné. Všechno na světě neustále zlevňuje, a je to především tím, že se to automatizuje. Není důvod, aby to u bezpečnosti bylo jinak. Lidské kapacity se pak mohou věnovat důležitějším věcem, než je obnova certifikátu. A když už existuje takový nesmysl, jako jsou DV certifikáty, ať nás alespoň zatěžuje co nejméně.

@Filip Jirsák

Smutné na tom je, že systém DV certifikátů a vůbec, volbu šifrování HTTP obsahu mohli řešit poskytovatelé obsahu sami, podle vlastního uvážení. Existují mnohem závažnější bezpečnostní témata, která by potřebovala pošťouchnout silou těch velkých - např. jsem zmiňoval šifrování elektronické pošty, kterou chodí daleko závažnější informace k chránění, nebo třeba i prosazování DANE. Jenže ono se spíš asi hodilo šlápnout do této oblasti. Není těžké si spočítat, že to milionům malých způsobuje často zbytečné problémy, zatímco velcí realizují úspory z rozsahu.

Není samozřejmě dokonalá pravda, že vše se srovná tím, že vše zlevňuje. Výpočetní technika sice pracuje efektivněji a hardware je čím dál levnější (jak relativně k výkonu, tak i absolutně). Přesto celkově roste spotřeba jak surovin na výrobu zařízení, tak i na výrobu energie, která výrobky hýbe.

Je poměrně únavné sledovat ten boj "za bezpečnost a soukromí", když jedno opatření vyvolá miliardu malých problémů (zdánlivě neviditelných), i to, že se vybírají témata, která se hlavně hodí do obchodních plánů těch, kteří je silou vynucují.

Osobně bych raději méně šifroval (a dle vlastního uvážení), než se účastnil tohoto trendu.

Jde o to, aby byla data po ceste šifrovaná a nebo aby měl uživatel jakous takous jistotu, že data jsou šifrovaná a ještě mohl alespoň kvalifikovaně odhadnout s kým se baví?
To první bez druhého nemá smysl. K čemu vám bude šifrování dat, když je bude dešifrovat útočník?

Zkracování doby platnosti vede k jediné věci - vydávané certifikáty jsou tak slabé, jak jen to jde. Stejně tak klíče se generují (obvykle) relativně slabé.
Čemu říkáte „slabý certifikát“, když nejde o velikost klíče? Vy jste při automatizaci vydávání certifikátů začal používat slabší klíče? Proč? Proč si myslíte, že se tak zachoval i někdo jiný? Já jsem při automatizaci klíče nezkracoval, ani mne to nenapadlo.

Kdyby se chtělo, šlo by to vydávat bezpečně i na delší dobu přičemž "ušetřené" peníze by se daly vrazit do lepší validace.
Myslím, že prodloužení doby platnosti certifikátů z 90 dní by to celé naopak prodražilo. Protože byste se už dostal do intervalu, kdy se něco může rozbít, aniž by se na to včas přišlo.

Lepší validace se s automatizací nijak nevylučuje. A hlavně lepší validace DV certifikátů nic neřeší – DV certifikáty jsou nesmysl samy o sobě a bylo by potřeba je nahradit DANE. To bohužel prohlížeče nepodporují, takže nezbývá, než používat DV certifikáty – ale nic moc lepšího, než je ACME dns01 pro validaci DV certifikátů nevymyslíte. Takže jediné možné zlepšení by byla možnost zakázat ostatní metody validace certifikátů (HTTP, SNI, e-mail u jiných CA).

Neřešme konkrétní instanci, LE. Řešme princip. Automatizace je v mnoha případech nezpochybnitelně dobrá věc. Já mám problém s tím, že někdo třetí automatizovaně rozhoduje jaké šifrování, jaká délka klíče je "pro nás" dobrá. Stejně tak mám problém s fortelností validací (typicky nešífrovaným emailem, nepodepsanou doménou). Ano, zpřístupňuje to https v zásadě všem, nepochybně. Ale je to správná cesta?

Jestli se certifikát má obnovovat po 90 dnech, dříve nebo později je podle mého nepodstatná technikálie. S dnešní technikou dovedeme velmi slučně odhadnout, jak dlouho muže trvat útok na klíč se známými parametry a tedy dovedeme stanovit dobu platnosti při vhodně zvolených parametrech velmi bezpečně. V případě principielní změny situace máme crl.

V současnosti mám prostě pocit, že data se nějak šifrují, běžný BFU po cestě se do nich nedostane, ale to je tak všechno.

Já mám problém s tím, že někdo třetí automatizovaně rozhoduje jaké šifrování, jaká délka klíče je "pro nás" dobrá.
Proč to tedy někomu třetímu dobrovolně odevzdáváte? Tohle přece vůbec nijak nesouvisí ani s automatizací, ani s LE, ale jenom s tím, co vy sám děláte.

Stejně tak mám problém s fortelností validací (typicky nešífrovaným emailem, nepodepsanou doménou).
Zrovna LE validaci e-mailem nepodporuje, to je krok vpřed. Existuje CAA DNS záznam, kterým povolíte, které autority mohou vydávat certifikáty pro vaši doménu. Dejte si tam jenom ty autority, které podle vás validují dostatečně.

Ano, zpřístupňuje to https v zásadě všem, nepochybně. Ale je to správná cesta?
Nepochybně je to správná cesta. Nejsnazší útok na HTTPS (sebelépe zabezpečené) je downgrade na HTTP. Tenhle útok bude možný do té doby, dokud prohlížeče budou podporovat HTTP. Takže je potřeba, aby všichni přešli na HTTPS. Že zůstane pár ňoumů, kteří budou mít sice HTTPS, ale děravé? To bude jejich problém. Ale těm, kteří chtějí mít HTTPS zabezpečené pořádně, to nic neudělá – na rozdíl od prohlížečů podporujících HTTP.

S dnešní technikou dovedeme velmi slučně odhadnout, jak dlouho muže trvat útok na klíč se známými parametry a tedy dovedeme stanovit dobu platnosti při vhodně zvolených parametrech velmi bezpečně. V případě principielní změny situace máme crl.
To ovšem pořád vycházíte z předpokladu, že jediný důvod pro omezení doby platnosti certifikátu je možnost prolomení klíče. Jenže tohle nikdy žádný reálný důvod nebyl. A omezení platnosti certifikátu na 90 dní u LE má podle mne jeden hlavní cíl – tlak na automatizaci.

V současnosti mám prostě pocit, že data se nějak šifrují, běžný BFU po cestě se do nich nedostane, ale to je tak všechno.
I kdyby to bylo opravdu všechno, je to pořád obrovský pokrok oproti situaci, kdy se citlivé údaje jako hesla nebo čísla platebních karet posílají nešifrovaně a může si je každý přečíst.

Kdyby se chtělo, šlo by to vydávat bezpečně i na delší dobu přičemž "ušetřené" peníze by se daly vrazit do lepší validace.
No nevím. V létě nastal problém u nějaké podřízené autority Digicertu, takže revokovali hromadu EV certifikátů. No a shodou okolností přes tuto autoritu vydává certifikáty CESNET, kde navíc v létě došlo k nějakému zpoždění komunikace - výsledek: ti, co si na servery dali "lepší" (EV) certifikáty, měli pár dní na výměnu - a vystavení EV trvá delší dobu. Ti s DV problém neměli (a kdyby, tak DV dostanou obratem).
Myslím, že pro běžné použití DV naprosto stačí, když nejste banka nebo tak něco.
A už vůbec délka platnosti nesouvisí s kvalitou (délkou klíče), naopak Let's Encrypt vás donutí v případě potřebhy přejít mnohem rychleji na bezpečnější klíče nebo cokoliv je potřeba. A díky automatizaci řešíte jen případné chyby (na řešení máte měsíc, když se obnova certifikátu zkouší poprvé měsíc před koncem platnosti).

1. 9. 2020, 08:25 editováno autorem komentáře