Názory k článku AlwaysOnSSL: bezplatná autorita s certifikáty na jeden rok
-
Netušil jsem, že autorita je zahrnuta mezi důvěryhodné, resp. může se zařadit do řetězce důvěryhodných, aniž by měla implementovanou revokační proceduru. Je to další krok k devalvaci TLS (SSL) certifikátů a jejich systému vůbec. Až se skoro zamýšlím, jestli se to celé nesnaží někdo poslat do kytek záměrně. Aneb: když nedokážeme lousknout komunikaci těch, kteří se opravdu zabezpečili, uděláme v tom takový babylon, aby se v budoucnu nedomluvil nikdo s nikým a na ničem.
-
Podle článku revokaci vyřešenou má, jen není automatická.
A snaha poslat do kytek – to zní dost konspiračně. I kdyby revokace zcela chyběla nebo byla reálně sabotována, je to sice problém, ale týká se především těch, kteří se rozhodli u této CA si pořídit certifikát. Není to ohrožení potenciálně jakékoli TLS komunikace, kde se věří této autoritě.
-
Filip JirsákStříbrný podporovatelRevokace je v systému certifikačních autorit klíčovým prvkem, a musí být rychlá a snadná. Pokud to tak není, bude docházet k tomu, že někdo revokaci neprovede, protože si řekne, že mu to za ty komplikace nestojí – a bude spoléhat na to, že sice existuje riziko, že někdo certifikát zneužije, ale dotyčný to riziko považuje za nízké. To ale nabourává důvěru v celý systém certifikačních autorit.
Netýká se to jenom těch, kteří se rozhodli u této CA pořídit certifikát. Právě naopak, když se někomu podaří získat certifikát podvodem, bude pro oprávněného vlastníka domény problém, jak takový certifikát revokovat.
-
Nemíchejme u revokace dvě různé věci:
a. Legitimní držitel certifikátu se rozhodne jej revokovat. Revokace skrze manuální zásah podpory sice není fajn, ale nejsou tu colateral damages. Je čistě věc admina serveru, zda se rozhodne takové riziko podstoupit.
b. Certifikační autorita vydala certifikát do špatných rukou. Má vůbec nějaká CA automatizované řešení takovéto situace? Teoreticky by šlo udělat DV revokaci (tedy prokážu vlastnictví domény, podobně jako kdybych chtěl získat certifikát), ale má to tak nějaká CA reálně implementované? -
Filip JirsákStříbrný podporovatel
To nejsou dvě různé věci, ale celá škála možností. Žádné nebezpečí neplyne ze situace, kdy se mi zničí např. čipová karta s jedinou kopií privátního klíče. Pokud příslušný certifikát nerevokuju, neplyne z toho prakticky žádné riziko – na druhou stranu, proč nechávat platný certifikát, který se už nikdy nemá použít. Komplikace s revokací v tomto případě budou znamenat, že certifikát nechám aktivní, ale není to žádné bezpečnostní riziko.
Další na škále jsou případy, kdy kompromitaci nelze zcela vyloučit, ale je považována za nepravděpodobnou. Například odchází zaměstnanec, který měl k privátnímu klíči přístup; nebo se ukáže, že se s privátním klíčem nezacházelo vždy dostatečně bezpečně, a teoreticky někdy mohl uniknout; nebo z rizikovějších věcí třeba Heartbleed. V těchto případech už komplikace při revokaci mohou vést k tomu, že certifikát nakonec ponechám v platnosti – a to už je oslabení bezpečnosti. Ostatně pro příklad nemusíme chodit daleko, koncem února se řešil případ DigiCert vs. Trustico, kde šlo přesně o tohle – a nakonec si DigiCert nechal poslat privátní klíče e-mailem, čímž to posunuli do extrému popisovaného v následujícím odstavci, a pak už museli jednat.
Na opačném konci škály pak je situace, kdy ke kompromitaci privátního klíče došlo, s absolutní jistotou nebo takřka s jistotou. Zde mohou komplikace při revokaci revokaci oddálit, nebo v krajním případě jí dokonce zamezit. Což je rozhodně bezpečnostní problém a oslabení celého systému důvěryhodných certifikačních autorit.
To, že je certifikát vydán do špatných rukou (ať už chybou certifikační autority nebo chybou vlastníka domény), se bude na škále pohybovat spíš někde u té jisté kompromitace. Jak správně píšete, odvolat takový certifikát asi nebude snadné u žádné autority – což je podle mne problém, protože se dost energie věnuje tomu, aby se takové certifikáty odhalily (např. Certificate Transparency), ale už se moc neřeší, co s těmi odhalenými certifikáty dělat. Mělo by platit, že kdo dokáže projít validací, aby mohl nějaký certifikát získat,měl by mít automaticky možnost kterýkoli certifikát vystavený na základě ekvivalentní validace revokovat.
-
V zásadě celkem souhlasím. Je tu určitá šklála možností, z hlediska procesu revokace se mi to rozpadá na dvě hlavní varianty. (Ano, tyto varianty mohou mít ještě podvarianty*, ale to bychom zacházeli zbytečně do detailů.)
Certifikát vydaný do špatných rukou a leak privátního klíče jsou sice podobné z hlediska míry rizika, ale liší se z hlediska možností revokace. Leaknutý privátní klíč je chyba vlastníka domény, který ale jej s trochou štěstí má k dispozici (může jím podepsat žádost o revokaci) a často má u té CA nějaký účet, kterým by mohl žádat o revokaci. Ani jedno z toho není případ certifikátu vydaného do špatných rukou (ať už je chyba na kterékoli straně), kde musí nastoupit jiný proces revokace.
> Na opačném konci škály pak je situace, kdy ke kompromitaci privátního klíče došlo, s absolutní jistotou nebo takřka s jistotou. Zde mohou komplikace při revokaci revokaci oddálit, nebo v krajním případě jí dokonce zamezit. Což je rozhodně bezpečnostní problém a oslabení celého systému důvěryhodných certifikačních autorit.
Pokud jde o kompromitaci privátního klíče (a ne certifikát vydaný do nesprávných rukou), pak souhlasím, že je to problém. Řešení je ale prosté: použijte jinou CA, kde revokaci vyřešíte snáze. Tady žádné „oslabení celého systému důvěryhodných certifikačních autorit“ nevidím.
Pokud by šlo o revokaci certifikátu vydaného do špatných rukou, tak to sice není ideální, ale nevidím nic, z čeho by plynulo, že je zde tato CA horší, než je dnes zvykem. Pokud zde vidíte ono „oslabení celého systému důvěryhodných certifikačních autorit“, pak ano, ale bez dalšího průzkumu to nevypadá jako vina jediné CA.
> Mělo by platit, že kdo dokáže projít validací, aby mohl nějaký certifikát získat,měl by mít automaticky možnost kterýkoli certifikát vystavený na základě ekvivalentní validace revokovat.
Souhlas. A je tu CA, u které to platí: https://letsencrypt.org/docs/revoking/
O jiných takových bohužel nevím, třeba u Comodo jsem ani nenašel k revokaci přímo od nich nic.
*) Snad jediná relativně zajímavá podvarianta by bylo nahlášení podezřelého certifikátu třetí stranou. Tady se proces bude dost těžko automatizovat.
-
Filip JirsákStříbrný podporovatel
I v případě certifikátu vydaného do špatných rukou může mít vlastník domény účet u CA a dokonce i držet příslušný privátní klíč – ten certifikát může být vydán např. neoprávněnému zaměstnanci oprávněného vlastníka domény.
Řešení je ale prosté: použijte jinou CA, kde revokaci vyřešíte snáze. Tady žádné „oslabení celého systému důvěryhodných certifikačních autorit“ nevidím.
Celý systém certifikačních autorit ale přece není určen žadatelům o certifikáty, ale spoléhajícím stranám. Pokud jako spoléhající strana vím, že existují plané certifikáty, které by měly být revokované ale nejsou, mou důvěru v celý systém certifikačních autorit to snižuje – a nezáleží na tom, že já osobně bych si pro vystavení certifikátu vybral jinou autoritu, než tu problematickou. Jako spoléhající strana můžu narazit na certifikát, který měl být odvolán, od kterékoli autority. -
> I v případě certifikátu vydaného do špatných rukou může mít vlastník domény účet u CA a dokonce i držet příslušný privátní klíč – ten certifikát může být vydán např. neoprávněnému zaměstnanci oprávněného vlastníka domény.
A taky je tu vždy možnost, že ten, komu se podaří získat podvodný certifikát, následně pošle privátní klíč majiteli domény… Pokud certifikát získá neoprávněný zaměstnanec, pak ho buď získá ke svému privátnímu klíči (pak asi ho nemá zaměstnavatel, ledaže by mu ho dobrovolně poskytl), nebo ho získá k privátnímu klíči, ke kterému nemá mít přístup (a pokud má, je primárně problém zde). Možné je ledacos, ale někdy jde o poměrně okrajové případy – asi jako by se vám zloděj přišel chlubit s lupem, ale nehodlal nic vrátit.
> Celý systém certifikačních autorit ale přece není určen žadatelům o certifikáty, ale spoléhajícím stranám.
Adminovým úkolem je zabezpečit server. Jedna věc je volba CA s realizovatelnou revokací, druhá věc jsou bezpečnostní aktualizace, třetí věc je přístup k samotnému serveru. Je-li admin kompetentní, zvolí vyhovující CA. Není-li kompetentní, máme jakožto spoléhající se strana větší problémy než obtížnější revokaci. Mimochodem, použití vhodné CA se kontroluje ve srovnání s jinými věcmi (aktuální software, heslo roota, …) poměrně snadno.
P.S.: Rozhodně netvrdím, že mají revokaci vyřešenou ukázkově. Jen tvrdím, že když vám to vadí, tak to prostě nemáte používat, čímž se to v rámci možností řeší. Ostatně je na rozhodnutí admina, co je pro něj easy enough. Jestli revokace musí být automatická, nebo jestli ticket na helpdesku je OK. Stejně jako Starcom kdysi požadoval (požaduje?) poplatek za revokaci z vlastního rozhodnutí. (Ne, to nebyl ten důvod pro distrust. Naopak, toto bylo v Mozillou zamítnuto jako nedostatečný důvod. Snad v roce 2014.)
-
Filip JirsákStříbrný podporovatel
Nepoužívat certifikační autoritu znamená nemít ji na seznamu důvěryhodných autorit. Vzhledem k tomu, že je na globálních seznamech, tudíž jí používají miliardy uživatelů, to, že jí já sám přestanu důvěřovat, na celém systému nic nezmění. A ti, kdo důvěřují těm globálním seznamům, budou oprávněně kritizovat, že na nich jsou nedůvěryhodné autority.
To, že StartCom požadoval poplatek za revokaci, jsem považoval za ukázkový příklad toho, jak CA fungovat nemá. Ostatně, on byl StartCom celý takový…
Obecně je ve světě DV certifikátů dost divoký. Doufám, že společně s tlakem na používání HTTPS bude i tlak na to, aby se certifikáty pro HTTPS dalo opravdu spolehnout. Ideálně úplně zrušit DV certifikáty a používat DANE.
-
Nepoužívat jsem myslel z pozice admina/provozovatele. Protože to je jeho odpovědnost.
Když se připojíte na server, jehož admin to nějak řeší (třeba root.cz, pokud to nebylo náhodou), máte jistotu, že admin má možnost revokovat mnoha způsoby a poměrně snadno. Nemáte samozřejmě jistotu, že tak admin skutečně učiní, stejně jako se může pokazit spousta dalších nesouvisejících věcí, které jsou ve zodpovědnosti provozovatele a do kterých vidíte mnohem hůře než do použité CA.
-
Filip JirsákStříbrný podporovatel
Jak už jsem psal, na seznamy důvěryhodných certifikačních autorit spoléhá celý svět. To spoléhání se, důvěra, to je role certifikačních autorit. To, že si jeden správce jednoho serveru vybere důvěryhodnější CA, nezmění nic na faktu, že v těch seznamech důvěryhodných certifikačních autorit budou i méně důvěryhodné autority.
Představte si třeba situaci, kdy by se mezi těmi důvěryhodnými autoritami vyskytla taková, která dá certifikát na libovolnou doménu každému, kdo si o něj požádá. Jistě, odpovědný správce serveru root.cz si certifikát od takové autority vystavit nenechá. Ale tím se nic nevyřeší, když si ten certifikát na jméno root.cz u té autority můžu nechat vystavit třeba já.
Problémy s revokací certifikátu jsou jen slabší varianta téhož. Mezi důvěryhodné autority se může dostat taková, která zavede nový způsob ověřování vlastnictví domény přes webový server, s nímž nebude každý počítat – vymyslí si nějakou vlastní „well-known“ cestu. Admin/provozovatel nějakého serveru se svědomitě této autoritě vyhne, ale nějaký redaktor, který má právo umístit soubor do příslušného umístění, si iniciativně nechá od této nové autority vystavit certifikát. Když se na to přijde, může spolupracovat, ale když bude problém u CA certifikát odvolat…
-
Je dost rozdíl mezi autoritou, která vydá certifikát na cokoli každému na požádání, a autoritou, která nemá ideální revokaci. Autorita vydávající certifikáty komukoli na cokoli je problém, pokud je mezi důvěryhodnými. Autorita, která komplikuje revokaci těm, kdo si certifikát nechali vystavit, zdaleka takový problém není – nelze na to uplatnit argument „co když nějaká třetí strana“…
K redaktorovi: No nevím. Pokud si bude chtít snížit trest, tak ho asi nebude bolet ani těch $25 (nebo kolik to bylo) Starcomu, natož založení ticketu u AlwaysOnSSL…
Přijde mi to jako moc povyku kolem něčeho, co stejně pořádně nefunguje: https://scotthelme.co.uk/revocation-is-broken/
Až bude revokace fungovat dobře, snad bude CA/Browser fórum vyžadovat něco podobného, jako má Let's Encrypt. Do té doby jsou důležitější problémy na řešení.
-
The KLP (neregistrovaný)
Celá to důvěryhodnost je pošahaná, protože nevidím jediný rozumný důvod proč domená .cz by měla mít certifikát od zahraniční CA.
Vyhláška přece definuje státem uznávané CA - I.CA, PostSignum a eIdentity.
Nevidím důvod proč <dosaš zahraniční stát> .cz.
(Konspirace: "Mimochodem DANE TLS záznamy tohle řeší, ale NSA si dala práci, aby se do prohlížečů nikdy nedostala.") -
Ravise (neregistrovaný)
Co třeba zahraniční firma s mimo jiné českou doménou, která si certifikáty zařizuje hromadně s autoritou v jejím domovském státě?
Nevidím jediný rozumný důvod, proč by nějaký $WEB měl povinnost mít certifikát od státem uznané autority. Nebo vůbec certifikát vystavený nějakou autoritou. Na *svůj* server, který používám pro *své* věci si klidně hodím *svůj* self-signed.
Konspiruješ s DANE TLS záznamem, ale nenapadne tě, že takhle by stát dostal do rukou celkem dost velkou páku na autority a jejich poslušnost?
-
The KLP (neregistrovaný)
Vždy je to o tom, čemu důvěřuji. Je zde situace kdy
a) certifikát může vydat prakticky kdokoliv (těch CA jsou mraky)
b) vydá to státně posvěcená CAV případě a) je kompromitace jasná, stačí napadnout kteroukoliv z tisíců CA.
V případě b) je zde problém že dáš "zbraň" do rukou státuČemu věříš víc?
-
To, že nějaký stát podporuje CA, ještě neznamená, že je ta důvěryhodnost zajištěna. Navíc je rozdíl mezi státně posvěcenou a vlastněnou. U podpory je pouze jen ta podpora. Veškerá režie je stále na CA a stát do toho nekecá. Pokud CA selže, tak stát okamžitě ukončí spolupráci.
Krásným příkladem je PostSignum. Tehdy byl státem podporovaný, a přesto systém i prohlížeče ho neměly ještě mezi důvěryhodné. Já na to narážel v době, kdy se poprvé zprovoznily datové schránky. Web tehdy měl certifikát od PostSignum a přesto při načtení stránky datovek se vždy objevovala hláška o neznámé CA. -
CertCenter je jeden z největších německých resellerů SSL certifikátů a projekt AlwaysOnSSL je reakcí na Let's Encrypt. Přímo majitel CertCenteru se stará o vývoj API a automatizaci. Škoda že článek nevyšel minulý týden, mohl jsem se zeptat na podrobnosti v Rustu na CloudFest 2018, kde projekt prezentovali i v přednášce jako nutnost nabídnout free verzi a automatizaci. Docela mne překvapuje délka platnosti na 1 rok. Mimochodem Encryption Everywhere má na svém hostingu i Zoner.
Zajímavé bude co s tím vším udělá DigiCert. Mluví se o redukci značek CA Symantec a např. zrušení Thawte. -
Martin DrábStříbrný podporovatel
> Sice se to netyka uplne Linuxu, ale netusite, jestli se nekde da
> "zadarmo" poridit certifikat vhodny na podepisovani Win aplikaci ?
> Tedy aby Win nekvakaly, ze aplikace je z nepodepsana, nebezpecna,
> atd.Nevím o tom, myslím si, že nic takového neexistuje a nedává moc smysl. Důvodem podepisování Windows aplikace (či ovladače) není šifrování, ale kontrola její integrity a (v podstatě) autora. Autority takové certifikáty vydávají jen po ověření osoby či společnosti (úroveň ověření závisí na tom, jak silný certifikát chcete, a co s ním chcete podepisovat). Tohle ověření se nedá úplně automatizovat, takže zde vždy budou extra náklady na straně CA.
U Let's Encrypt neověřujete, kdo certifikát pořizuje (a ten certifikát k tomu nelze použít).
Ale pokud chcete takový certifikát levně, myslím, že Certum dává pro použití s open source dobrou cenu (28 EUR). Je tam teda trochu zrada, jelikož ten certifikát dávají pouze na smartcard, takže pokud ji nemáte, musíte si nějakou kompatibilní sehnat. Ta od Certum je dost drahá (myslím, že cca 100 EUR + 50 EUR poštovné, ale to rozložení může být klidně jinak), ale obsahuje všechen potřebný software a dokumentaci (včetně návodu, jak s tím podepisovat). Smartcard půjde použít i opakovaně (budu zkoušet někdy v červenci, až mi vyprší můj standard code signing).
Co se týče ověření osoby, chtěli vidět naskenovaný OP a důkaz používání adresy (účet od operátora jim stačil). Vyřízení bylo velmi rychlé, dokonce v sobotu. U open source certifikátu budou chtít odkazy na projekty.
https://www.certum.eu/certum/cert,offer_cert_comparision_cs.xml -
fe (neregistrovaný)
Nutno si uvědomit, že:
1) Není certifikát jako certifikát (nemíchat doménové, aplikační, S/MIME…),
2) Vše je o důveryhodnosti celého certifikačního řetězceNevím jak Microsoft, ale Apple si dělá vlastní certifikáty s vlastní kořenovou (a intermediate) autoritou, které (kterým) důvěřuje. Systém automatické revokace v jejich workflow funguje dobře.
A je to přesně o tom, komu jako výrobce OS budete důvěřovat. Pokud se rozhodnete důvěřovat certifikátům od Symantecu, můžete na tom postavit celé svoje workflow. Ale hádám, že ani Microsoft by do takového risku nešel.Jinak řečeno pro podepsání aplikace pro Windows bude nejlepší použít certifikát od Microsoftu:
https://msdn.microsoft.com/cs-cz/library/windows/desktop/jj835832(v=vs.85).aspx -
Petr M (neregistrovaný)
K čemu to?
- Mám věřit někomu, kdo se nepředstaví? Asi ne.
- Mám hosting s IPv4 i IPv6, mám kvůli CA vypnout šestku, nebo tam jet na HTTP? Asi ne.
- Mám čekat nedefinovanou dobu a revokaci certifikátu? Asi ne.
- Mám se zříct DNSSEC a riskovat, že někdo unese spojení od zákazníka? Asi ne...Takže tohle bych viděl jako německý nedodělek typu Energiewende nebo kóty na uprchlíky... Ne, díky.
-
Ondřej CaletkaZlatý podporovatelJen pro korektnost, absence IPv6 vás trápí jen v případě, kdy chcete validovat IPv6-only službu. Pro dual-stack službu validace bez problému projde po IPv4.
-
Ondřej CaletkaZlatý podporovatel
Nepochybujte o tom, že takhle autorita má nějaký velmi podobný blacklist. Nejspíš nenajdete žádnou, která by takový blacklist neměla.
-
Ondřej CaletkaZlatý podporovatel
Nejspíš ano, vyzkoušejte. Ani StartSSL to neblokovalo, dalo se získat neomezené množství certifikátů, každý s jedním jménem. Jen se nesmělo opakovat jméno už vydaného platného a nerevokovaného certifikátu.
-
Drahé řešení zadarmo (neregistrovaný)
Tak jsem to zkusil ... a zadarmo drahé.
Po zkušenosti autora jsem si účet zřídil předem a přihlásil se. Stejně to následně chtělo login, naštěstí to pokračovalo.
Ale vydání certifikátu přes soubor na webu - asi tak napotřetí a to jsem to tlačil i očima.
Následný pokus použítí v Apache: asi to neumím, ale tyto certifikáty mi Apache hlásí, že to není správný certifikát.Výsledek: Strávil jsem s tím necelou hodinu, což je fakt dlouho (LE mi trvá cca 10 minut).
Takže buď LE, nebo raději komerční certifikát za nějakých 400-500Kč/rok a je to v klidu.
Toto je naprosto nedotažená věc a vhodná podle mě tak maximálně pro nadšence, nebo ty, co odmítají zaplatit CA z principu.Pro mě nepoužitelná.
-
Existuje i nějaké služba, která by vydávala zdarma osobní certifikáty, které by měly povolené kromě podepisování emailů také PODEPISOVÁNÍ DOKUMENTŮ?
Patrně ne. Aby měl takový podpis smysl, musela by certifikační autorita zajistit to, že zná / ověřila totožnost toho, kdo certifikát drží. Nedovedu si představit, jak by někdo ve velkém ověřoval totožnost lidí a zadarmo.
Další otázkou je, k čemu je podpis, když certifikační autoritě stejně příjemce dokumentu nemusí důvěřovat. Když mi od Vás přijde dokument podepsaný certifikátem vystaveným CA z Číny, proč bych měl takovému řetězu vztahů věřit?
Na to, na co se ptáte, slouží kvalifikovaný elektronický podpis. Za ověření totožnosti se pak zaručuje Česká republika, podobně jako u osobního dokladu. Stojí asi čtyři stovky na rok a důvěřovat mu musí celá EU (resp. její orgány, státy a samosprávy); soukromé subjekty se mohou rozhodnout, ale když se rozhodnou, tak mají jistotu autenticity podpisu.
Takže proč nějaký certifikát zadarmo?
-
Martin Ž. (neregistrovaný)
Ta moje myšlenka byla taková, že když mám certifikát, který ověřuje mojí emailovou adresu, tak na spoustu věcí by mi stačilo tím stejným certifikátem podepsat nějaký PDF dokument.
Chápu, že tam by byla jen identifikace právě tou emailovou adresou (žádným jménem). Ale i takový malá síla ověření autora mi přijde mnohem více, než nic.
-
d.c. (neregistrovaný)
Tak to by me zajimalo, jak lze dokazat, ze jsem dostal e-mail z nejake adresy.
Problem s oficialnimi CA u nas (a vubec v EU) je v tom, ze se nijak nezenou do duveryhodne distribuce svych korenovych certifikatu. Ostatne take v oblasti zajisteni duveryhodneho procesu overovani by se i od mnoha ne-zcela prikladnych certifikacnich autorit mohli ucit.
-
Filip JirsákStříbrný podporovatel
Na to jste přišel jak, že podepisování e-mailů a podepisování dokumentů je něco jiného?
Kvalifikovaný certifikát má nastavené následující parametry:
* Key usage: Digital Signature, Non-Repudiation
* Extended key usage: E-mail ProtectionKdyby v něm nebyl některý z těch příznaků Key usage, nepůjde s ním podle mne podepsat ani e-mail ani jiný dokument.
ČLÁNKY DO MAILU