Hlavní navigace

Po úniku klíčů bude dnes zneplatněno 23 000 TLS certifikátů

Sdílet

Andy_S 1. 3. 2018
Zámek klíč klávesnice

Po obchodní rozepři mezi společnostmi Trustico a DigiCert bude zneplatněno 23 tisíc TLS certifikátů a to během několika málo hodin. Důvodem je únik privátních klíčů k certifikátům, o který se postarala společnost Trustico mailem zaslaným společnosti Digicert.

  1. Kvůli problémům s TLS certifikáty v minulém roce předal Symantec správu těchto certifikátů společnosti DigiCert.
  2. Trustico počátkem tohoto února oznámil, že kvůli problémům s bezpečností ukončuje s okamžitou platností přeprodej certifikátů Symantec a zároveň požádala DigiCert jakožto provozovatele těchto certifikátů o ukončení platnosti již vydaných certifikátů (cca 50 tisíc).
  3. DigiCert požadavek obratem odmítá s poznámkou, že není zcela jasné, jestli může o zneplatnění certifikátu požádat prodejce, nebo pouze koncový zákazník. Uvedli taktéž, že k okamžitému zneplatnění certifikátů by mohlo dojít, pokud by se prokázalo, že privátní klíče byly vyzrazeny. DigiCert potvrdil, že vzájemná spolupráce s Trustico končí.
  4. Trustico e-mailem zasílá DigiCertu 23 tisíc privátních klíčů s identifikátory, DigiCert okamžitě spouští kroky pro jejich zneplatnění do 24h a všech 23 tisíc zákazníků Trustico, neboť držení privátního klíče kýmkoliv vyjma majitele je pádný důvod k zneplatnění certifikátu. Zároveň o dané skutečnosti informují Mozillu a slibují zveřejnění daných klíčů, aby je mohli zneplatnit i další výrobci prohlížečů.

Otázkami však zůstává, proč si Trustico uchovával privátní klíče, zdali k tomu využil svůj webový nástroj pro generování privátních klíčů a zdali dojde k zneplatnění i zbývajících 27 tisíc certifikátů.

Každopádně to znamená ponaučení pro všechny: nikdy nikomu nesvěřovat své klíče, ani vydavateli certifikátu a generovat si je vždy na svých zařízeních.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 1. 3. 2018 9:15

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Aaano... dalsi !!duveryhodna!! CA .... ale jo, ten system funguje naprosto paradne ... lol.

  • 1. 3. 2018 9:26

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    CA zareagovala, jak podle pravidel měla. Zneplatnila certifikáty, u kterých byl vyzrazen soukromý klíč.

    Průšvih je na straně přeprodejce, protože:
    1) Neměl vůbec mít soukromý klíče a držel je neoprávněně.
    2) I kdyby je mít směl, v žádným případě by je nesměl komukoliv předat.

    Doufám, že se vlastníci certifikátů spojí a budou na přeprodejci požadovat odškodný + náhradu ušlých zisků + poplatky za vystavení nových klíčů. A CA je zažaluje o náklady spojený s touhle akcí a tučný odškodný. Kopanec do peněženky totiž bolí nejvíc.

  • 1. 3. 2018 9:48

    mngnt (neregistrovaný) 212.36.164.---

    Ano, zareagovala, ako podla pravidiel mala. A co sa tym vyriesi? Akurat sa tu v clanku rozobera efektivita zneplatnovania certifikatov. Mozilla ich zaradi do svojho dalsieho Firefoxu, my co bezime na ESR, mame smolu, mozme si akurat rucne zablokovat digicert a symantec. Cely ten system sa dost rozpadava...

  • 1. 3. 2018 9:55

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Ten system je naprosto nefunkcni odjakziva, jen to holt sype $$$, tak se to snazi vsichni zucastneni udrzet pri zivote. Na bezpecnost pritom serou zvysoka, protoze to s bezpecnostni nema spolecnyho zhola nic.

    Kdyby chtel nekdo bezpecnost na webu zlepsit, tak implementuje dane.

  • 1. 3. 2018 10:10

    Ondra Satai Nekola

    Neblabol. System ma dost problemu (protoze, ruku na srdce, resi to _hodne_ obtizny problem), ale kdyz se aplikuji reseni na dilci problemy (transparency...), tak lidi jako ty krici hovadiny o tom, jak to prospiva Google atp.

  • 1. 3. 2018 12:06

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Copak nekola, zase sis prisel zablejt o vececch o kterych vis lautr hovno?

  • 1. 3. 2018 16:40

    Allstar

    Naprostý souhlas. S bezpečností to nemá co dělat. Když na moji .cz doménu může vystavit prakticky kterákoliv CA na světě platný certifikát, tak je něco špatně.

  • 1. 3. 2018 18:46

    Ondra Satai Nekola

    Zkus si najít někoho, kdo to zvládne přečíst, pochopit a vysvětlí ti to...

    Nebo snad máš nějakou realistickou situaci, kde to s daným problémem nepomáhá? Za ty měsíce, co o tom blábolíš jsi žádnou nevytáhl, jen jsi našel neexistující problémy (velká moc Google, nerealistické velikosti dat...), které spíš svědčí o tom, že ti to nedocvaklo.

  • 1. 3. 2018 19:23

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    A ty tu blabolis o jednom, velkym hovne ...

    Co udela tvuj browser, kdyz se ... NAPRIKLAD (a znova NAPRIKLAD, protoze to je jedna miliardtina celyho pruseru PKI ktery je naprosto nepouzitelny) nemuze z libovolnyho duvodu pripojit a zjistit zda cert neni revokovanej?

    No naprosto s klidem se tvari, ze je vse OK.

    Kecy typu ze CA musi udelat co ci ono si strc do svy rite. Kdyby CA delala co ma, tak nemuze takovej cert nikdy vydat. A presne stejne funguje ta kokotina kterou odkazujes.

    O soukromi, ktery samozrejme 100% pada - coz je primarni ucel - (protoze stovky GB si lokalne bude urcite syslit kazdy BFU) ani nemluve. Tohle nikdo svepravnej s aspon IQ debila nemuze pouzivat.

  • 2. 3. 2018 12:47

    Ravise (neregistrovaný) 2001:67c:1220:----:----:----:----:----

    CAA nemá podle standardu ověřovat klient, ale CA. Takže spíš ne.

  • 2. 3. 2018 13:08

    Miroslav Šilhavý

    Kdokoli, kdo se podívá do seznamu Certificate Transparency.

    Tím nezjistíte porušení CAA, což není prvotním účelem CAA. Přesto, bylo by to bezzubé, kdyby neexistovala kontrola. Potřebujete v době blízké vystavení certifikátu vidět, jestli někdo CAA překročil.

  • 2. 3. 2018 15:23

    Filip Jirsák

    Nezjistím tím porušení CAA, ale získám tím silné podezření. Nebude moc časté, že by někdo CAA záznam změnil ihned po vystavení certifikátu. Když mám silné podezření, nemusím samozřejmě hned alarmovat kde koho, ale stačí poslat dotaz vlastníkovi domény – nalezl jsem tento certifikát vydaný autoritou A, v CAA máte autoritu B, je to v pořádku? Vlastník domény by už měl vědět, jestli opravdu CAA záznam měnil, nebo jestli CA vydala certifikát neoprávněně.

    Dobu blízkou vystavení certifikátu právě zajistíte tak, že se podíváte do logu Certificate Transparency na poslední přidané záznamy.

  • 1. 3. 2018 9:58

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Není součástí toho systému ověření revokace certifikátu prohlížečem? A on to FF nedělá? jak pak FF řeší revokaci certifikátu Máni Čičmrndové, když někdo jeho certifikát zneužívá a Máňa ho nechá zneplatnit? Vykopnutím jedné CA a 20% internetu kvůli jednomu blogu s koťátkama?

    Prostě standardní postup:
    1) Symantec nekončí, netřeba ho vyhazovat.
    2) Pokud cert k doméně není v cache, ověří se kdo ho vydal a jestli je platný. pokud je z téhle dávky, ověřením neprojde.
    3) Když je v cache, za pár hodin expiruje a z cache vypadne sám. Dál viz bod 2.

    Ty můžeš maximálně zneplatnit jejich certifikáty v cache, zbytek se zařídí sám. A pokud to FF nepodporuje, změň prohlížeč.

  • 1. 3. 2018 10:09

    Vít Šesták

    Proč by uživatelé ESR měli mít smůlu? IMHO toto spadne pod security updates. (Pravda, v rychlosti jsem nenašel přímo tvrzení, které by to potvrzovalo/vy­vracelo, ale dává mi to tak smysl.)

  • 1. 3. 2018 9:58

    kb (neregistrovaný) ---.eurotel.cz

    "ponaučení pro všechny: nikdy nikomu nesvěřovat své klíče"
    hezké ponaučení, ale třeba internet banking komerční banky funguje právě na principu, že v rámci autentizačního procesu pošlete svůj certifikát vč. privátního kliče v balíčku pkcs12 přes webový formulář bance a musíte rovněž do formuláře zadat heslo k certifikátu:/

  • 1. 3. 2018 10:39

    Rad (neregistrovaný) 165.225.72.---

    a neni jednodussi to poslat rovnou cele v plaintextu a nic nesifrovat, kdyz vysledek je uplne stejny? :-D
    (nekomu posilat privatni klic, to je uplne stejny, jako mit kodovy zamek k baraku a kod napsat na stitek vedle dveri)

  • 1. 3. 2018 11:52

    jf (neregistrovaný) 2001:67c:289c:----:----:----:----:----

    To je blbost. Privátní klíč se serveru neposílá, jen se jím provede podpis pro autentizaci uživatele.

  • 1. 3. 2018 12:02

    Miroslav Šilhavý

    To je blbost. Privátní klíč se serveru neposílá, jen se jím provede podpis pro autentizaci uživatele.

    No mnoho CA generuje klíče v prohlížeči. Je možné, že někteří dokonce na své straně. Je to jakási úlitba adminům, kteří si klíč vygenerovat a odeslat ho s CSR neumějí. Pak už je jen krok k úvaze archivovat i klíče.

    Samozřejmě máte pravdu, klíč odesílat nikam ven NENÍ potřeba.

  • 1. 3. 2018 13:46

    Dw (neregistrovaný) ---.cust.vodafone.cz

    Zrejme mate na mysli klientsky certifikat, pouziva to sice rovnaku technologiu ako serverovy certifikat ale ma inak nastavene priznaky... ale aj v tomto pripade staci k podpisu odoslat CSR, podpisany CRT je potom mozne lokalne spojit s klucom do podoby pksc12...

  • 1. 3. 2018 14:22

    Ondřej Caletka

    Vkládá, ale to ještě nemusí znamenat, že se taky někam posílá. Předpokládám, že se podpis vytvoří lokálně a po síti putuje už jen ten – jinak by to nemohlo fungovat s čipovou kartou.
    Ovšem běžný uživatel to nemá šanci poznat, on prostě dává soubor s privátním klíčem a heslo k jeho rozšifrování do webového formuláře. To je samozřejmě koncepční chyba, se kterou se ovšem těžko dá něco udělat.

  • 1. 3. 2018 15:53

    kb (neregistrovaný) ---.eurotel.cz

    Pokud z .p12 vytáhnu pomocí openssl jen certifikát (bez klíče) a ten vložím do formuláře pro přihlášení do KB, tak se zobrazí zpráva, že certifikát je neplatný, formulář vyžaduje pkcs#12 formát a k tomu heslo. Co se pak reálně odesílá do banky se těžko zjišťuje, ale pokud se klíč odešle uživatel tomu taky težko zabrání.

  • 1. 3. 2018 14:58

    jkotek (neregistrovaný) ---.o2.cz

    IMHO celý popis je o importu PKCS#12 souboru (balík privátní klíč + jeho certifikát) do _prohlížeče_, nikoliv na server KB. Neboli zůstane na klientově počítači. Tedy pokud nepoužije nějaký roaming profil prohlížeče a i potom putuje privátní klíč na jiné servery než ty v KB.

  • 1. 3. 2018 15:58

    kb (neregistrovaný) ---.eurotel.cz

    v úložišti prohlížeče žádný certifikát není, autentizace do KB se provádní přes webový formulář, do kterého se vkládá pkcs12 a k němu heslo

  • 5. 3. 2018 10:30

    dw (neregistrovaný) 92.62.225.---

    Tak to je zle implementivane, pri nadvazovani tls by si mal server povedat ze nechce automaticky generovany anonymny crt ktory prehliadac generuje pri beznom https ale overeny klientsky certifikat. Prehliadac potom zobrazi vyzvu ktory pksc12 ma byt pouzity, server potom vidilen cast v ktorej je certifjkat a verenny kluc. Prehliadac samohrejme potrebuje aj privagny kluc. V ziadnom pripade by nemal byt poslany na server cely pksc12. Ak to nejaka sajta vyzaduje tak je dobre ju vylucit zo zonamu navstevovanych...

  • 1. 3. 2018 10:05

    Vít Šesták

    Nějaký nápad, co Trustico motivovalo k takovému kroku? Tím šli proti svým zákazníkům. Být mezi poškozenými, celkem jistě nový certifikát pořídím u někoho jiného, i kdyby to mělo být dražší.

  • 1. 3. 2018 10:51

    Filip Jirsák

    Pokud jde o tu první část, že požadoval i revokaci certifikátů, to je správně a nešli proti zákazníkům, právě naopak. Pokud mají podezření na snížení bezpečnosti, je v zájmu zákazníků, aby certifikáty revokovali – dávají tím najevo, že berou bezpečnost vážně a udělají i krok, který je nepopulární, pokud je to v zájmu bezpečnosti.

    Což je ovšem úplně postavené na hlavu, když se ukáže, že mají schované privátní klíče. Pokud o tom klienti nevěděli, je to obrovský průšvih a žádná CA už by s nimi nikdy neměla podepsat smlouvu o zprostředkování. Pokud o tom klienti věděli, asi je to v pořádku, i když z hlediska bezpečnosti je to hodně sporné.

  • 1. 3. 2018 11:14

    Vít Šesták

    Budu-li se držet jejich argumentů, nešlo o snížení bezpečnosti, ale o vyřazení CA z truststore, a to někdy v budoucnu. To není snížení bezpečnosti, to je jen budoucí nefunkčnost. A to rozhodně není argument k okamžitému znefuknčnění...

    Naopak, mohl bych argumentovat, že poslání private keys e-mailem může představovat riziko pro jejich zákazníky.

    To, že drželi private keys, je druhá věc. Únik těchto private keys by byl legitimní důvod k vyžádaní revokace. Ale tím neargumentovali.

  • 1. 3. 2018 11:41

    Filip Jirsák

    Šlo o snížení bezpečnosti (důvěryhodnosti) – Symantec přestává být důvěryhodnou CA. To, že budou kořenové certifikáty odstraněny ze seznamu důvěryhodných certifikátů, je důsledek téhož.

    Ano, poslání privátních klíčů e-mailem může představovat riziko, ale pokud Symantec nedokázal správně zareagovat na požadavek na revokaci (což je mimochodem také snížení bezpečnosti), neměli moc jiných možností. Mohli každou žádost podepsat příslušným privátním klíčem, jenže to by zase bylo zneužití těch privátních klíčů.

    Registrační autorita musí mít vždy možnost certifikát revokovat. Když třeba zjistí, že nějaký zaměstnanec podváděl a neověřoval osoby, musí registrační autorita ty certifikáty odvolat – nemůže to být tak, že začne shánět ty, komu certifikát vystavili (mezi nimi i možné podvodníky), a slušně je žádat, jestli by byli tak laskavi a svůj certifikát revokovali. A pokud dokonce registrační autorita má privátní klíč, není už vůbec o čem debatovat, jestli má nebo nemá právo žádat revokaci. Certifikační autorita nemá vůbec posuzovat, jestli důvod k vyžádání revokace je nebo není legitimní. Má akorát ověřit, že o revokaci žádá ten, kdo je k ní oprávněn.

  • 1. 3. 2018 12:13

    Vít Šesták

    > Šlo o snížení bezpečnosti (důvěryhodnosti) – Symantec přestává být důvěryhodnou CA.

    Problém ale spočívá v tom, že někdo má tento certifikát v truststoru. Pak je ale jedno, jestli mám certifikát od této CA, nebo od jiné. Ve výsledku jediný problém pro správce serverů je availability, a Trustico tento problém akorát zvětšilo...

    > Symantec nedokázal správně zareagovat na požadavek na revokaci (což je mimochodem také snížení bezpečnosti)

    Symantec dostal požadavek od resellera, ne od legitivního držitele klíčů. IMHO je správné se k tomu stavět jako k požadavku libovolného náhodného kolemjdoucího. Stejně jako bych je já požádal o revokaci certifikátu pro eBay.com, bez dostatečně dobrého důvodu.

    > Mohli každou žádost podepsat příslušným privátním klíčem, jenže to by zase bylo zneužití těch privátních klíčů.

    To by bylo menší zlo, resp. správný postup pro případ, že mám leaknutý klíč.

    > Registrační autorita musí mít vždy možnost certifikát revokovat. Když třeba zjistí, že nějaký zaměstnanec podváděl a neověřoval osoby

    Kdo je "registrační autorita" ? Pokud reseller, pak ten typicky neprovádí samotné ověření, to je úkolem samotné koncové CA. A možná by to bylo i porušení nějakých pravidel.

    > A pokud dokonce registrační autorita má privátní klíč, není už vůbec o čem debatovat, jestli má nebo nemá právo žádat revokaci.

    Souhlas. Ale to tu padlo až později. A na to tak také zareagovali.

    > Certifikační autorita nemá vůbec posuzovat, jestli důvod k vyžádání revokace je nebo není legitimní. Má akorát ověřit, že o revokaci žádá ten, kdo je k ní oprávněn.

    Pokud o revokaci žádá oprávněná osoba, pak ano. Otázkou ale je, kdo je tou oprávněnou osobou. Za mě to reseller standardně není.

  • 1. 3. 2018 12:27

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    "Symantec dostal požadavek od resellera"
    To je uplne jedno, jakejkoli clanek v retezu je opravnen revokovat libovolny klice ktery pres nej protecou. Jak si to vyresi se svejma oveckama je jeho vec. Je to jen dalsi ukazka toho, jak to cely naprosto vubec nefunguje.

  • 1. 3. 2018 12:59

    SSLmentor (neregistrovaný) ---.vivo.cz

    V případě prvního požadavku nikdo nevěděl, že má Trustico privátní klíče. Ty poslali potom.
    Reseller je jen firma co přeprodává certifikáty, nemůže je revokovat jen tak jak se jí za chce. O tom ten řetěz není a validace dělají CA. V principu se reseller má dostat jen k veřejným klíčům co se certifikují. Pak nemá důvod cokoliv revokovat. Nebo vy byste si koupil certifikát u firmy, co by měla v podmínkách, že může kdykoliv požádat o zneplatnění Vašeho certifikátu?

  • 1. 3. 2018 16:59

    Filip Jirsák

    V případě osobních certifikátů je registrační autorita ten, kdo provede to skutečné ověření osoby, rozhodně to není jen přeprodejce. Ono by to taky jinak nedávalo smysl, abyste přišel za přeprodejcem, ten by od vás inkasoval peníze a pak by vás stejně poslal do certifikační autority. U serverových certifikátů vydávaných na dálku to tak být nemusí, ale pokud by to tak nebylo, uniká mi, k čemu by tam ten přeprodejce byl dobrý. Mimochodem, pokud by to tak bylo, reseller se nemusí dostat ani k těm veřejným klíčům – klidně by mohl jen vystavit fakturu.

    Pokud někdo vlastí privátní klíče, není „jen někdo, kdo přeprodává certifikáty“, a právo revokovat certifikát samozřejmě mít musí.

    Smlouva mezi zákazníkem a Trustico je něco jiného, než smlouva mezi Trustico a certifikační autoritou. Ve smlouvě mezi mnou a Trustico samozřejmě nechci ustanovení, že mohou požádat o zneplatnění certifikátu kdy je napadne, ale že o něj mohou požádat v případě, kdy budou mít důvodné podezření, že došlo ke kompromitaci. Mezi Trusitco a certifikační autoritou je to ale něco jiného, protože tam je zodpovědnost na Trusticu (pokud tedy jen nefakturují).

    Rozhodně bych si nekoupil certifikát od firmy, která bude mít v podmínkách, že certifikát odvolají jedině na žádost majitele privátního klíče – a pokud se nějakému útočníkovi podaří získat falešný certifikát, koupí firma bonboniéru a půjdou ho slušně požádat, jestli by byl tak laskav a certifikát odvolal.

    Mimochodem, tady v ČR se certifikáty vydávají na fakturu – protože pokud nezaplatíte, může certifikační autorita certifikát odvolat a vám bude k ničemu. Takže i kdyby někdo jen vystavoval faktury, může mít dobrý důvod certifikát odvolat (i když to nijak nesouvisí s bezpečností).

  • 1. 3. 2018 17:30

    Vít Šesták

    > U serverových certifikátů vydávaných na dálku to tak být nemusí, ale pokud by to tak nebylo, uniká mi, k čemu by tam ten přeprodejce byl dobrý.

    Dříve jako reseller fungovala třeba Simplia, která fungovala právě tímto způsobem. (CSR teda dostala ještě Simplia, ale ano, tady mohla přesměrovat na svého dodavatele...) Výhodou byla množstevní sleva. Ono to i dává smysl, u DV certifikátů není tak náročné provést ověření, mnohem náročnější by bylo kontrolovat resellera, že dělá vše správně, a vzít si na triko to riziko.

    U OV/EV/osobních certifikátů může být situace jiná, ale to pak znamená, že reseller se de facto stává součástí CA. Což klade na resellera úplně jiné nároky...

    > Pokud někdo vlastí privátní klíče, není „jen někdo, kdo přeprodává certifikáty“, a právo revokovat certifikát samozřejmě mít musí.

    Ano. Ale to není z titulu resellera (ostatně podstatnou část certifikátů Trustico patrně nerevokovalo, protože k nim nemělo privátní klíče...), ale kvůli tomu, že klíč se dostal do rukou třetí strany. Stejně jako kdyby si Franta Vomáčka vytáhl něčí klíč skrze heartbleed...

    > firmy, která bude mít v podmínkách, že certifikát odvolají jedině na žádost majitele privátního klíče

    To by skutečně tak být nemělo, vlastnictví privátního klíče je jen jeden (nikoli jediný) způsob, jak prokázat, že buď a. jsem legitimní vlastník klíče nebo b. klíč k certifikátu má neoprávněná osoba. Pokud se zjistí vydání špatného certifikátu, samozřejmě by měla CA co nejdříve certifikát revokovat. Tam je jedno, od koho se to dozví, pokud je zřejmé, že došlo k chybnému vystavení certifikátu.

  • 1. 3. 2018 19:45

    Filip Jirsák

    Podle mne je důvodem k revokaci certifikátu jakákoli zjištěná nesrovnalost týkající se certifikátu. Např. privátní klíč od zaměstnaneckého certifikátu má jenom zaměstnanec, neplatí tedy váš bod a) ani b), přesto je správné, aby firma po skončení zaměstnaneckého poměru zaměstnance ten certifikát odvolala.

  • 1. 3. 2018 20:31

    Vít Šesták

    Já ale psal něco jiného. Z požadavku na revokaci podepsaného příslušným privátním klíčem vyplývá a) nebo b), z toho obojí je důvod k revokaci. Nevyplývá z toho ale, že to jsou jediné dva důvody k revokaci.

  • 1. 3. 2018 21:25

    Filip Jirsák

    Tady ale s největší pravděpodobností žádost o revokaci podepsaná příslušným privátním klíčem nepřišla a nikdo oprávněnost případné žádosti podepsané odpovídajícím privátním klíčem nerozporoval, takže jste mimo téma diskuse.

  • 1. 3. 2018 22:07

    Vít Šesták

    Jestli je to mimo téma diskuze - mám pocit, že je tu spíše nějaké nedorozumění, ale asi to není zásadní otázka našeho sporu, takže bych to zbytečně nerozváděl.

  • 1. 3. 2018 13:13

    Vít Šesták

    Reseller je asi takovým článkem v řetězu, jak vydavatel platební karty, kterou za ten certifikát zaplatím. Aspoň standardně to tak funguje. Ověření pak provede samotná CA. Nejde o transfer důvěry resellerovi. Ten v procesu vystupuje jako entita, které nemusíme moc věřit, ideálně (pokud si vygenerujeme CSR a použijeme 3rd party platební bránu) kromě zdrhnutí s penězi bez vydání certifikátu nemá žádnou možnost nás podvést.

  • 1. 3. 2018 13:27

    j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----

    Nevsim sem si, ze bych pri platbe kartou uzaviral nejakou smlouvu s bankou ...

    Zato kdyz si od nekoho kupuju cert, uzaviram smlouvu s nim, a je mi uprdele jestli provozuje CA sam, nebo vyuziva sluzeb nekoho dalsiho. Pokud budu neco resit, budu to resit s tim, s kym mam smlouvu, a ten si to bude resit se svym dodavatelem. Ten dodavatel me pak naprosto logicky posle dorite s libovolnym pozadavkem, protoze ja snim ani on semnou nemame nic spolecnyho.

  • 1. 3. 2018 14:04

    SSLmentor (neregistrovaný) ---.vivo.cz

    Když si kupujete certifikát, tak si vybíráte důvěryhodnou CA, takže vám rozhodně nemůže být ukradený, kterou CA vybíráte. Kupovat cert můžete u Franty Omáčky, ale podmínky použití platí od CA. U DV certifikátů potvrzujete e-mail zaslaný od CA. U EV certifikátů přímo komunikujete s CA a je jedno, zda jste si koupil certifikát u Pepy nebo u Franty. Např. u EV Comoda odsouhlasujete sám jejich podmínky a posíláte jim potřebnou dokumentaci. U OV a EV cert jste ověřován telefonicky přímo CA. Jinak máte ID objednávky, můžete se obrátit na CA na chat nebo mail, klidně i zavolat.
    CA tu garantují Vaše ověření, takže to co popisujete rozhodně pro certifikáty neplatí.

  • 1. 3. 2018 17:09

    Filip Jirsák

    Problém ale spočívá v tom, že někdo má tento certifikát v truststoru.
    Ano, pokud má někdo v trustoru certifikát nedůvěryhodné CA, je to problém.

    Reseller není žádný náhodný kolemjdoucí, zvlášť když má v ruce privátní klíče.

    Registrační autorita je ten, kdo provádí ověření – někdo, komu CA důvěřuje a na základě jeho informací vystaví certifikát. Trustico nevypadá jako reseller, který jenom fakturuje a jinak se procesu vystavení certifikátu nijak neúčastní.

  • 1. 3. 2018 18:18

    Vít Šesták

    Úkol resellera typicky končí fakturací. Ostatně jsem se zkusil podívat, jak řešili EV certifikáty. Na https://www.trustico.com/validation/ev/extended-validation-requirements.php (v době psaní nedostupná a archive.org je taky nedostupný, ale pomohla Google cache) zmiňují, že validaci s vámi vyřeší Symantec přímo. U DV to nejspíš bude totéž, tam by se důvod pro delegaci ověření hledal ještě hůře...

    OK, reseller není úplně náhodný kolemjdoucí, ale po vydání certifikátu má stejnou roli.

    Privátní klíče může různými způsoby získat i náhodný kolemjdoucí (ačkoli by ideálně neměl), stejně jako je nějakým způsobem získal tento reseller (ačkoli by taky ideálně neměl). Jejich pozice je prakticky stejná - standardně nemohou certifikát revokovat, ledaže by měli v ruce vhodný důkaz...

    > Trustico nevypadá jako reseller, který jenom fakturuje a jinak se procesu vystavení certifikátu nijak neúčastní.

    Zdroj? Já jsem svoje zdroje i úvahy uvedl, teď jste na řadě vy.

  • 1. 3. 2018 19:58

    Filip Jirsák

    Shodneme se na tom, že při pouhé fakturaci není jak se dostat k privátnímu klíči vystavovaného certifikátu? Věříte té informaci, že Trustico mělo 23 000 privátních klíčů k certifikátům vydaným jejich zákazníkům? Mně z těchto dvou informací plyne, že Trustico nebyl přeprodejce, který jenom fakturuje a procesu vystavení certifikátu se nijak neúčastní.

    Navíc pokud ten přeprodejce i jenom fakturuje, má asi se zákazníkem nějaký vztah, zákazník se možná přihlašuje do jeho systému nebo existuje nějaký způsob, jak přeprodejce zákazníka pozná. Takže i v případě odvolání certifikátu bude zákazník komunikovat s přeprodejcem a ne s certifikační autoritou. Podle mne přeprodejce musí mít možnost jím zprostředkovaný certifikát odvolat, ostatně je to inverzní operace k žádosti o ten certifikát, a tu přeprodejce dělá. A že by mohl přeprodejce certifikát svévolně odvolat? To už je otázka vztahu mezi zákazníkem a přeprodejcem, aby tohle nedělal. Ostatně stejně tak může přeprodejce stopit žádost o vydání certifikátu nebo fakturovat dvojnásobnou cenu, způsobů jak škodit svým zákazníkům má mnoho.

  • 1. 3. 2018 20:28

    Vít Šesták

    Co jsem viděl u Simplie, tak ti dostávali CSR, které pak předávali samotné CA. Technicky nejspíš něco podobného bylo i u Trustico, akorát oni uměli CSR vygenerovat za zákazníka (u Simplie nevím, možná i to uměli) a jako bonus si asi zalogovali klíč. Každopádně ověření EV probíhalo přes Symantec (vizte link výše) a u DV tuplem není důvod to dělat jinak a brát na vlastní triko riziko.

    Já nepsal, že Trustico jen fakturovalo, to je takové zjednodušené vyjádření, které není přesné. Trustico patrně bylo jakýmsi frontendem, kde uživatel prošel až k ověření, které už dělal Symantec.

    > A že by mohl přeprodejce certifikát svévolně odvolat? To už je otázka vztahu mezi zákazníkem a přeprodejcem, aby tohle nedělal. Ostatně stejně tak může přeprodejce stopit žádost o vydání certifikátu nebo fakturovat dvojnásobnou cenu

    Stopení desítek až stovek dolarů je často menší problém než náhlá nedostupnost. A dvojnásobná cena - pokud s tím zákazník souhlasí...

  • 1. 3. 2018 20:00

    SSLmentor.cz (neregistrovaný) ---.vivo.cz

    Začíná se nám to tu motat :)
    Takže Vít Šesták má samozřejmě pravdu. Reseller fakturuje a poskytuje support.

    Jinak FB Trustico píše "A dedicated SSL Certificate provider, its aim is to revolutionise the market by being a one-stop shop for your online security needs at sensible prices."
    Trustico je obyčejý reseller. A ten může mít klidně další resellery a ti další partnery. Vše ale začíná a končí u CA, která provádí validaci.

    Byla tu otázka, proč vlastně tedy kupovat u resellera. Trh se tak vyvinul, oficiální ceny CA jsou o 50 - 90% větší než se prodávají certifikáty. Kdokoliv si může koupit certifikát u CA, ale nevyplatí se to. Má to pro CA i zcela zásadní výhody - s uživatelem řeší problémy reseller/partner. A TLS certifikáty dost často potřebují nějaké konzultace, doporučení. Tyto informace reselleři poskytují na lokálním trhu, zajišťují zákazníkům support, atd. atd.

    Dále naprosto základní věc k současné situaci - nikdo, nikdo krom žadatele by neměl mít privátní klíče. Prostě neměl a hotovo. Takže neřešme že Reseller má mít možnost revokovat certifikáty zákazníků. Jediné právo Resellera na revokaci může být to, že např. v administraci nabídne žádost o zneplatnění.
    Celý problém je v tom, že si Trustico uchovávala klíče bez vědomí zákazníků. To je prostě exces co tu ještě nebyl a v takovém množství. A ani s něčím takovým nikdo nepočítal. Privátní klíče má mít každý u sebe. Jinak web mají už několik hodin nedostupný a na twitteru se řeší jak (ne)byl server zabezpečen. Imho to skončí pro ně hodně špatně.

    V Česku je to taky zajímavé s generováním klíčů. Zkuste se zeptat na wedosu jak na certifikát. Support doporučí jeden web, který vygeneruje zákazníkovi klíče a vloží do Organizational unit: svoji reklamu. Na druhou stranu když pak řeší člověk objednávku, tak aspoň ví že se to má zahodit ;)

    Petr

  • 1. 3. 2018 20:14

    Filip Jirsák

    Reseller fakturuje a poskytuje support. Trustico je obyčejý reseller.
    Tak to bych teda fakt rád věděl, jak při fakturaci (nebo poskytování supportu) získáte privátní klíč od certifikátu, který si nechává vystavit váš zákazník.

    Má to pro CA i zcela zásadní výhody - s uživatelem řeší problémy reseller/partner.
    Souhlasím. A jedním z nejčastěji řešených problémů bude revokace certifikátu.

    Dále naprosto základní věc k současné situaci - nikdo, nikdo krom žadatele by neměl mít privátní klíče. Prostě neměl a hotovo.
    Já s tím souhlasím. Ale „zjednodušování“ vede k tomu, že privátní klíč vlastní někdo jiný. Jestli se nepletu, tak tohle umožňují i některé služby eIDASu. Může se nám to nelíbit, můžeme proti tomu protestovat, ale to je asi tak všechno.

    Takže neřešme že Reseller má mít možnost revokovat certifikáty zákazníků. Jediné právo Resellera na revokaci může být to, že např. v administraci nabídne žádost o zneplatnění.
    Nejdřív to nechcete řešit, a pak napíšete, že by to právo vlastně měl mít. S tím souhlasím, já si také myslím, že by reseller měl mít právo na revokaci jím zprostředkovávaných certifikátů, protože je to on, kdo se zákazníkem komunikuje.

    Celý problém je v tom, že si Trustico uchovávala klíče bez vědomí zákazníků.
    Můžete něčím doložit to, že to bylo bez vědomí zákazníků?

    Já tedy jako problém vidím především to, že Symantec (údajně) odmítl revokovat certifikáty na žádost resellera.

    na twitteru se řeší jak (ne)byl server zabezpečen
    To má nějaký reálný základ, nebo je to jen další ničím nepodložená spekulace?

  • 1. 3. 2018 20:48

    SSLmentor.cz (neregistrovaný) ---.vivo.cz

    Dobrý večer,
    jak získali klíče? Naprosto jednoduše - v objednávce je formulář na generování klíčů. Klient si to vykliká a objednávka je hotova. Ti serióznější po vygenerování napíší, aby si klient uložil TXT KEY u sebe a neukládá je, Trustico si to ukládalo. Možná i z důvodu, že když tuto službu nabídli, tak se zjistilo, že po vystavení zákazník nemá privátní klíč - neuložil si to, ztratil jej. U nich se mohlo jednat možná o tisíce objednávek, tak "našli" řešení.

    Můžete něčím doložit to, že to bylo bez vědomí zákazníků?
    Nevím zda tady neslovíčkaříme. Rozhodně nemyslím, že by to měli někde uvedené, v principu to totiž nesmí dělat. Ale např. tady https://twitter.com/Manawyrm/status/969230542578348033 ?

    Že to bude ještě větší prů...r než jsme doufali třeba tady:
    https://twitter.com/darkflib/status/969287195277365249

    K tomu "A jedním z nejčastěji řešených problémů bude revokace certifikátu." Za 15 let si nevzpomínám, že bych někdy řešil kompromitaci privátního klíče více než v jednotkách kusů. Takže to rozhodně není pravda.

    Moje informace že Reseller nemůže sám revokovat certifikáty platí. Asi nebylo pochopeno co znamená nabídnout možnost v administraci. Tím je myšleno že zákazník sám požádá někde v rozhraní u Resellera, CA žádost ověří, např. mailem jak ověřovala vystavení, a poté certifikát zneplatní. Reseller do toho opět zasahuje pouze jen jako mezičlánek. Může samozřejmě pomoci zákazníkovi problémy řešit, konzultovat, ale revokace je pouze na CA - majitel certifikátu.

  • 1. 3. 2018 22:00

    Filip Jirsák

    Ten formulář pro generování klíčů ale není součástí fakturace, zcela jistě je součástí procesu vystavení certifikátu. Takže se Trustico účastnilo procesu vydávání certifikátu a tudíž musí být (pokud to má být bezpečné) oprávněno k revokaci takto vydaných certifikátů. I kdyby privátní klíče nearchivovali, dokonce i kdyby se k těm privátním klíčům ani nedostali, pořád mohli mít třeba chybu v generátoru klíčů, který by generoval slabé klíče. Prostředník, který vstupuje do procesu vystavení certifikátu a ovlivňuje jeho bezpečnost, tedy musí mít právo ten certifikát odvolat, když zjistí oslabení bezpečnosti. A certifikační autorita musí certifikát revokovat bez zbytečného odkladu, když obdrží žádost o revokaci – nemůže to zdržovat tím, že ještě bude něco ověřovat e-mailem. To mezitím může někdo ten privátní klíč vesele zneužívat. Zdržování revokace je porušením bezpečnosti ze strany CA. Upozornit zákazníka má CA v případě, kdy přijde opravdu někdo z ulice a bude tvrdit, že certifikát by se neměl používat, ale nebude schopen např. kompromitaci privátního klíče prokázat. Přístup „hlavně nerevokovat certifikát zbytečně“ má význam z obchodního hlediska, aby se ušetřilo, ale z bezpečnostního hlediska musí platit opačný postoj, „při pochybnostech revokovat“. To, že by přeprodejce revokoval certifikát neoprávněně, je samozřejmě riziko, ale to je riziko obchodního vztahu mezi přeprodejcem a jeho zákazníkem. Pokud zákazník přeprodejci nevěří, ať u něj nenakupuje.

    To, že nesmí mít uchované privátní klíče klientů, má Symantec/DigiCert někde v podmínkách, nebo je to „jen“ teorie? Já s tím jako s teoretickým principem samozřejmě souhlasím, ale v praxi je holt někdy bezpečnější, když má privátní klíč nějaký prostředník.

    Kompromitace privátního klíče není jediný důvod pro revokaci certifikátu. Podívejte se na nějaký CRL, rozhodně tam nenajdete jen jednotky kusů certifikátů a rozhodně nebude kompromitace privátního klíče převažující uvedený důvod odvolání.

  • 1. 3. 2018 22:13

    Vít Šesták

    To je otázka nastavení hranic. Pokud si privátní klíč a CSR vygeneruju přes OpenSSL, mají mít autoři OpenSSL možnost revokovat můj certifikát? Mají tu možnost mít maintaineři Debianu? (I tady se může chyba stát: https://www.schneier.com/blog/archives/2008/05/random_number_b.html ) Má tu možnost mít výrobce CPU, který vyrobil kousek zranitelný na Spectre/Meltdown?

  • 1. 3. 2018 21:07

    SSLmentor.cz (neregistrovaný) ---.vivo.cz

    Jinak ještě k tomuto:
    Já tedy jako problém vidím především to, že Symantec (údajně) odmítl revokovat certifikáty na žádost resellera.
    Digicertu prý poslali 2/2 žádost o revokaci 50k certifkátů. Digicert psal, že to skončilo na nějakém špatném oddělení. Potom Trustico vydalo zprávu, že nebude nabízet na novém webu žádné certifikáty od Symantecu (dnes ráno tam ale měli ještě Thawte 123 s informací že lepší je Comodo :). Důvodem prý byla ztráta důvěry - tj. problém s Chrome. Pak to spolu řešili a ve finále Trustico poslalo Digicertu 25.000 privátních klíčů jako důkaz, že došlo ke kompromitaci.

    Datumy nevím přesně, ale nějak tak jsem to pochopil, vyvrcholilo to nyní.
    PKI Symantec patří nyní pod Digicert, to ale určitě víte.

    Takže se lze jen dohadovat co se stalo, ale chování Trustica je více než divné. A podle mne to vypadá, i na základě aktuálních informací, že už dříve došlo k nějakému úniku a proto chtěli revokovat všechny certifikáty.
    To že Digicert to odmítl bez nějakého vysvětlení je zcela logické.

    Uvidíme co se bude dít dál.

  • 1. 3. 2018 22:23

    Filip Jirsák

    Důvodem prý byla ztráta důvěry - tj. problém s Chrome.
    Jste už druhý, kdo to převrací. To není tak, že by byl nějaký „problém s Chrome“, ze kterého by plynula ztráta důvěry v certifikáty Symantecu. Je to opačně, certifikační autorita Symantecu přišla o důvěru těch, kteří spravují všeobecně používané seznamy důvěryhodných autorit, důsledkem čehož je, že certifikáty přestanou být důvěryhodné v prohlížečích.

    Pak to spolu řešili a ve finále Trustico poslalo Digicertu 25.000 privátních klíčů jako důkaz, že došlo ke kompromitaci.
    Ano, to je zvláštní postup, ale já tam jako první bezpečnostní problém vidím to, že Symantec odmítl ty certifikáty revokovat. Dovedu si představit, že pokud se Symantecem jednali a nikam to nevedlo, zveřejnění těch privátních klíčů byla poslední možnost, jak Symantec donutit, aby ty certifikáty revokoval. A opět, pokud se Symantec až teď dozvěděl, že Trustico ty privátní klíče ukládá a je ochotné je zveřejnit, opět musí revokovat všechny ty certifikáty, tedy i těch zbývajících 27 000. Zajímalo by mne, co podle vás mělo Trustico udělat, pokud mírnější požadavky na revokaci certifikátů Symantec ignoroval nebo odmítal.

    Takže se lze jen dohadovat co se stalo, ale chování Trustica je více než divné.
    Pro mne je divné hlavně chování Symantecu a pokud je pravda to, co je zatím veřejně známé, nenapadá mne, jak mělo Trustico postupovat jinak.

    A podle mne to vypadá, i na základě aktuálních informací, že už dříve došlo k nějakému úniku a proto chtěli revokovat všechny certifikáty. To že Digicert to odmítl bez nějakého vysvětlení je zcela logické.
    Jak můžete tyhle dvě věty napsat vedle sebe? Podle vás je tedy pravděpodobné, že došlo k úniku privátních klíčů, a zároveň je správně, že DigiCert ty certifikáty odmítl revokovat? K čemu pak ta revokace certifikátů má sloužit, když je únik klíčů v pohodě a v žádném případě to nemá být důvod k revokaci?

  • 1. 3. 2018 23:41

    SSLmentor.cz (neregistrovaný) ---.vivo.cz

    Nezlobte se, ale nějak nerozumím Vaší diskuzi. Bavíme se o souvislostech nebo řešíme slovíčkaření?

    K tomu poslednímu odstavci a otázce dvou vět vedle sebe.
    Přečtěte si vyjádření Digicertu proč to tak bylo a proč revokují certifikáty neprodleně nyní
    https://www.digicert.com/blog/digicert-statement-trustico-certificate-revocation/

    A poslední věc k Vašemu názoru, že Trustico účastnilo procesu vydávání certifikátu a tudíž musí být (pokud to má být bezpečné) oprávněno k revokaci takto vydaných certifikátů.
    Jejich postup naprosto odporuje pravidlům jak by se mělo s certifikáty pracovat. Takže se podobná věc nikdy neřešila a už se také diskutuje na CAB fóru, kde vidím, že názor je jasný. Privární klíče mít neměli, není důvod aby mohli sami revokovat certifikáty. Možná se to změní, ale řešit se musí příčina ne důsledek.

  • 2. 3. 2018 7:33

    Filip Jirsák

    Nezlobte se, ale nějak nerozumím Vaší diskuzi. Bavíme se o souvislostech nebo řešíme slovíčkaření?
    Já se bavím o souvislostech. Na Vaši otázku Vám nemohu odpovědět, protože jste nenapsal, v čem vidíte slovíčkaření.

    K tomu poslednímu odstavci a otázce dvou vět vedle sebe. Přečtěte si vyjádření Digicertu proč to tak bylo a proč revokují certifikáty neprodleně nyní https://www.digicert.com/blog/digicert-statement-trustico-certificate-revocation/
    Ano, to je přesně o čem celou dobu píšu. DigiCert to evidentně vnímá tak (a Vy to obhajujete), že certifikát se primárně revokovat nesmí, a teprve pokud mají velmi vážný důvod k revokaci a velkou jistotu, že byl privátní klíč kompromitován, pak tedy velmi neochotně k revokaci přistoupí. Podle bezpečnostních pravidel to ovšem má být opačně, že se certifikát revokuje při jakémkoli důvodném podezření, že došlo ke kompromitaci. Že ředitel Trustico naznačil, že mají privátní klíče k dispozici, mi připadá jako více než dostatečný důvod k odvolání těch certifikátů. A stále nevycházím z údivu, že DigiCert má tuhle informaci, má důkaz, že Trustico opravdu mělo minimálně 23 000 privátních klíčů, má důkaz, že jsou schopní a ochotní privátní klíče zveřejnit – ale s DigiCertem to nehne a stejně těch zbývajících 27 000 certifikátů nerevokuje.

    Jejich postup naprosto odporuje pravidlům jak by se mělo s certifikáty pracovat.
    Souhlasím. Ale DigiCertu je to zjevně úplně jedno a dál nechá ty certifikáty v platnosti. Ale tak aspoň už víme, že u DigiCertu tohle pravidlo reálně neplatí – kdyby platilo, musel by jeho dodržování DigiCert nějak vymáhat, a revokace certifikátů je ten nejsnazší krok.

    Privární klíče mít neměli, není důvod aby mohli sami revokovat certifikáty.
    Už jsem tu vysvětloval, že to, že někdo drží privátní klíč, není jediný důvod k revokaci certifikátu.

    Možná se to změní, ale řešit se musí příčina ne důsledek.
    To je takové líbivé pravidlo, které ale se skutečnou bezpečností nemá nic společného. Pokud chcete skutečnou bezpečnost, musíte počítat s tím, že lidé dělají chyby, a snažit se zmírnit následky těch chyb. I proto je v PKI zaveden mechanismus revokace certifikátu, a proto je taky v pravidlech nastaven tak přísně, že se certifikát v případě pochybností raději revokuje. Protože k chybě může dojít, a celý systém certifikačních autorit je postaven na důvěře. Součástí té důvěry je i to, že v oběhu nebudou nezneplatněné certifikáty ke kompromitovaným klíčům, u kterých se o kompromitaci ví. Napravit mylnou revokaci certifikátu je možné, vydá se certifikát nový a nějak se kompenzují starosti, které se revokovaným certifikátem klient měl. Napravit mylné ponechání certifikátu v platnosti možné není, protože na základě důvěry v ten certifikát mohly být provedeny transakce, které už nikdo nikdy nedohledá a nevrátí.

  • 2. 3. 2018 9:59

    Miroslav Šilhavý

    To je takové líbivé pravidlo, které ale se skutečnou bezpečností nemá nic společného. Pokud chcete skutečnou bezpečnost, musíte počítat s tím, že lidé dělají chyby, a snažit se zmírnit následky těch chyb. I proto je v PKI zaveden mechanismus revokace certifikátu, a proto je taky v pravidlech nastaven tak přísně, že se certifikát v případě pochybností raději revokuje.

    K tomu ale nesmíte zapomínat na pravidlo přiměřenosti. Každé opatření má své potenciálně pozitivní důsledky a své potenciálně negativní důsledky. Jsou situace, kdy víte s jistotou, že existují nebo výrazně převyšují pozitiva a pak se nemusíte rozhodovat a můžete konat. Pak jsou ale situace, kde váháte a minimálně zdrženlivost je na místě. Důvěra v jakoukoliv autoritu, včetně certifikační, není jen o tom, že do puntíku následuje postupové protokoly, ale i v to, že v extrémních situacích má mechanismus, jak od protokolu ukročit a posoudit situaci individuálně. Vaše pojetí je čistě binární, ano/ne. Příčina, důsledek. Svět takto nefunguje (za sebe: naštěstí).

    V konkrétním případě: pokud zjistím, že nevyhovující stav trvá už týdny, měsíce, či roky, nevyhnutelně dojdu k tomu, že zbrklou reakcí už nic zásadně nezlepším. Pozitiva jsou nízká. S jistotou bych tím přinesl mnoho starostí desetitisícům lidí. Proto je na místě jednat uvážlivě. Obdobně pomalu probíhal distrust StartSSL - který podle Vaší logiky měl být také bleskový.

    Napravit mylnou revokaci certifikátu je možné, vydá se certifikát nový a nějak se kompenzují starosti, které se revokovaným certifikátem klient měl.

    To by mě zajímalo jak.

    Napravit mylné ponechání certifikátu v platnosti možné není, protože na základě důvěry v ten certifikát mohly být provedeny transakce, které už nikdo nikdy nedohledá a nevrátí.

    Obojí má vyjádřitelnou míru rizika a v extrémích situacích, jako je tato, lze považovat mezi nimi. To, co píšete, je univerzální pravda pro běžné, časté a hromadné jevy, ne pro průšvih tohoto rozměru, či toho, co se stalo kolem StartSSL.

  • 2. 3. 2018 10:30

    Filip Jirsák

    Moje pojetí není binární, právě naopak – tvrdím, že v případě certifikátů nemusí být jistota, že je důvod k revokaci, může být jen různě silné podezření. A pro zachování důvěryhodnosti celého systému certifikačních autorit má platit pravidlo, že v případě pochybností se přikloní na bezpečnější stranu, tedy k revokaci certifikátu. Binárně se na to dívá DigiCert a někteří zdejší diskutující – o revokaci nežádá vlastník privátního klíče, tak se nic revokovat nebude. Vzpomeňte, jak se hromadně revokovaly certifikáty při Heartbleed – s tím vaším binárním přístupem by certifikáty nikdo nerevokoval a všichni by čekali, dokud jim útočník osobně nepřinese jejich privátní klíč.

    DigiCert neměl co posuzovat, jestli je to zbrklá reakce nebo není. Dostal požadavek na revokaci od subjektu, který ovlivňoval bezpečnost vydávaných certifikátů. Ty desetitisíce lidí nebyly zákazníky DigiCertu, ale Trustica, je tedy starostí Trustica, ne DigiCertu, zda to ty desetitisíce lidí zasáhne. Trustico klidně mohlo se svými klienty už dávno certifikáty vyměnit a po DigiCertu mohli chtít jenom revokaci starých už nepoužívaných certifikátů.

    Pro mne je důležitá ta zpráva, že u DigiCertu nebyl schopen odvolat certifikáty ani zákazník, který od nich má desítky tisíc certifikátů, takže asi bude patřit mezi významné zákazníky. Pro mne to znamená, že já jako jednotlivec bych s největší pravděpodobností odvolání neplatného certifikátu nedosáhl už vůbec, takže je nejlepší od nich vůbec žádné certifikáty nemít.

    Kompenzovat chybně revokovaný certifikát je možné třeba tím, že bude mít dotyčný jeden, dva, tři následné certifikáty zdarma.

    Ten průšvih ovšem vyrobil DigiCert tím, že odmítl certifikáty revokovat, přestože požadavek k jejich revokaci byl oprávněný. Je možné, že kdyby ty certifikáty odvolal, ukázalo by se, že to nezvládá ani Trustico, protože například nedokázalo svým zákazníkům zajistit jiné certifikáty. A nebo je taky možné, že to Trustico mělo perfektně procesně zvládnuté, ty odvolané certifikáty už drtivá většina jejich zákazníků nepoužívá a jejich odvolání byl jen závěrečný krok dělaný „pro jistotu“. Jak to bylo ve skutečnosti se možná ještě dozvíme, každopádně původně bylo riziko, že něco pokazí, na straně Trustica, ale DigiCert to odmítnutím revokace certifikátů vzal na sebe a donutil Trustico ke zveřejnění klíčů.

  • 2. 3. 2018 10:59

    Miroslav Šilhavý

    Moje pojetí není binární, právě naopak – tvrdím, že v případě certifikátů nemusí být jistota, že je důvod k revokaci, může být jen různě silné podezření. A pro zachování důvěryhodnosti celého systému certifikačních autorit má platit pravidlo, že v případě pochybností se přikloní na bezpečnější stranu, tedy k revokaci certifikátu. Binárně se na to dívá DigiCert a někteří zdejší diskutující – o revokaci nežádá vlastník privátního klíče, tak se nic revokovat nebude. Vzpomeňte, jak se hromadně revokovaly certifikáty při Heartbleed – s tím vaším binárním přístupem by certifikáty nikdo nerevokoval a všichni by čekali, dokud jim útočník osobně nepřinese jejich privátní klíč.

    Obchodní vztah je čistě mezi výstavcem a uživatelem. Třetí osoba, byť je to zprostředkovatel, nemá co vyjadřovat vůli za uživatele. Uživatel ví nejlépe, co od služby očekává a jestli preferuje zneplatnění certifikátu, či ne. S jistotou Vám mohu říct, že podstatná skupina z poškozených zákazníků má certifikát jen proto, že byl uměle vytvořený tlak na šifrování jako o život, a že ve skutečnosti necítí potřebu ani šifrovat, ani prožívat kompromitaci klíče, natož aby museli cokoliv dělat či platit pro "nápravu" stavu, který jim vlastně jako vadný ani nepřijde.

    V čem se, pan Jirsáku rozcházíme je to, že já kladu svobodnou vůli osob nad pravidla, která ze svobodné vůle většiny nevzešla. Pokud je tu systém důvěryhodných certifikačních autorit, nejsou jejich zákazníky uživatelé internetu, ale zejména poskytovatelé obsahu. Jejich zájmem je, nebo není, svůj obsah chránit před změnou, odposlechnutím atd. Proto jsem proti vnucování silou a zaštiťováním se "ochranou koncových uživatelů". Historicky se vždy ti nejzaslepenější zaštiťovali abstraktně vyjádřenou vůlí existujících mas. Ve skutečnosti ale jediné, co se ukázalo být udržitelné, jsou zákony ekonomiky.

    Pokud bych já něco viděl jako správný postup, tak je to okamžité informování zákazníků o situaci a dát jim na vybranou, jestli chtějí starý certifikát ponechat v platnosti, či ne. Tím by vznikly tři skupiny: 1) ti, co chtějí nový, 2) ti, co chtějí ponechat planý původní, a 3) ti, co neodpovědí. Teprve tu třetí skupinu bych zpracovával - asi nejprve další vlnou oslovení, či telefonicky. Na konci bych stál před rozhodnutím, co mám udělat. Třetí skupina je nekontaktní, a revokací cetifikátu jim mohu způsobit škody, stejně jako jim může způsobit škody jeho kompromitace. Na to, abych mohl tuto otázku rozhodnout podle svědomí (a tedy i podle přirozeného práva), vedl bych vyšetřování, kterým bych se snažil zjistit, jak velké je riziko, že někdo kompromitované klíče zneužije. Tedy, musel bych stanovit okruh lidí, kteří mohou klíče mít a prověřil bych je. Teprve na konci toho procesu bych byl s to říci, co je větší zlo.

    Určitě ale nemohu s Vámi souhlasit, že jakékoliv potenciální riziko má vyvolat takto hromadnou panickou reakci jen kvůli tomu, že techničtí odborníci to považují za nutné. Ne jen odborníci na elektronickou komunikaci vládnou našemu světu.

  • 2. 3. 2018 11:58

    Filip Jirsák

    Obchodní vztah je čistě mezi výstavcem a uživatelem.
    Nikoli, obchodní vztah je čistě mezi resellerem a majitelem certifikátu. Zákazník má uzavřenou smlouvu s resellerem, fakturuje mu reseller, support mu poskytuje reseller, nějaký administrační systém mu případně taky poskytuje reseller. Certifikační autorita pouze zákazníka ověří a podepíše certifikát. Ale fakturuje pak resellerovi, ne koncovému zákazníkovi. Navíc Symantec má přímo v podmínkách uvedené, že reseller může revokovat certifikát jménem koncového držitele.

    S jistotou Vám mohu říct, že podstatná skupina z poškozených zákazníků má certifikát jen proto, že byl uměle vytvořený tlak na šifrování jako o život, a že ve skutečnosti necítí potřebu ani šifrovat, ani prožívat kompromitaci klíče, natož aby museli cokoliv dělat či platit pro "nápravu" stavu, který jim vlastně jako vadný ani nepřijde.
    To je chyba těch zákazníků, že věří těm bludům, že šifrování někde není potřeba. Ale právě proto jsou tu firmy jako Trustico, které se to snaží zákazníkům maximálně usnadnit – protože vědí, že bezpečnost závisí i na snadnosti použití pro koncového uživatele.

    V čem se, pan Jirsáku rozcházíme je to, že já kladu svobodnou vůli osob nad pravidla, která ze svobodné vůle většiny nevzešla.
    Svobodná vůle bez znalostí je (nebezpečná) iluze. Pravidla vystavování certifikátů jsou daná certifikační politikou, pravidla obchodního vztahu klienta s resellerem jsou daná smlouvou případně odkazem na nějaké obchodní podmínky. Klient podpisem smlouvy vyjadřuje souhlas s těmi pravidly, pokud s nimi nesouhlasí, nikdo ho nenutí smlouvu podepisovat.

    Jejich zájmem je, nebo není, svůj obsah chránit před změnou, odposlechnutím atd.
    Zájmem každého poskytovatele obsahu je chránit svůj obsah před změnou, protože do tvorby toho obsahu investuje. Pokud by bylo jedno, že se obsah změní, ať to napojí na /dev/random a autory obsahu propustí – výrazně ušetří, a změnu obsahu mu přece nevadí…

    Pokud bych já něco viděl jako správný postup, tak je to okamžité informování zákazníků o situaci a dát jim na vybranou, jestli chtějí starý certifikát ponechat v platnosti, či ne.
    To ale cílíte na jinou skupinu zákazníků, než má Trustico. Pokud si někdo nechá vygenerovat klíč a uložit u nějaké firmy, dělá to proto, že tomu vůbec nerozumí a svěřuje se do rukou odborníka. Takže je na tom odborníkovi, aby pak řešil bezpečnostní problémy, o kterých se dozví. Ten váš postup by byl podobný, jako kdybyste šel na internu na operaci, a tam by vám oznámili, že ale budete celou dobu při vědomí, protože oni si jako odborníci nejsou moc jistí, takže definitivní rozhodnutí v průběhu operace budou na vás.

    Určitě ale nemohu s Vámi souhlasit, že jakékoliv potenciální riziko má vyvolat takto hromadnou panickou reakci jen kvůli tomu, že techničtí odborníci to považují za nutné. Ne jen odborníci na elektronickou komunikaci vládnou našemu světu.
    To je ten problém, že lidé chtějí rozhodovat o věcech, o kterých nic nevědí a vědět nechtějí. Hromadná panická reakce je váš ničím nepodložený dojem.

    Navíc tenhle spor není technický, ale obchodní – Trustico se rozhodlo od Symantecu odejít, protože mu přestali důvěřovat, a součástí té nedůvěry je samozřejmě požadavek na revokaci všech certifikátů. Pro Symantec je to asi další rána, tak si postavil hlavu a prohlásil, že certifikáty neodvolá, dokud nedostane jejich seznam a příslušné privátní klíče (což samo o sobě je neuvěřitelný požadavek). Symantec byl asi dost překvapen, když Trustico i takhle absurdní požadavek splnilo a klíče jim fakt poslali.

  • 2. 3. 2018 12:09

    Miroslav Šilhavý

    Svobodná vůle bez znalostí je (nebezpečná) iluze.

    Možná. Mně to přijde spíš jako pohrdání lidmi a tím, že si umějí své priority srovnat správně.

    Zájmem každého poskytovatele obsahu je chránit svůj obsah před změnou, protože do tvorby toho obsahu investuje.

    Nikoliv. Zájmem je mít výnosy vyšší než náklady. Je možné, že jednou z cest je i chránění obsahu, ale to prosím ponechte na těch, jejichž zájmy je třeba chránit.

    To je ten problém, že lidé chtějí rozhodovat o věcech, o kterých nic nevědí a vědět nechtějí.

    Možná o nich vědí víc, než Vy o ekonomice jejich projektů. V nejhorším případě vědí stejně: tedy nic.

  • 2. 3. 2018 20:56

    Vít Šesták

    Ten link je zajímavý. Přijde mi ale poněkud v rozporu s tím, co tvrdí zprávička, ze které jsem i vycházel, nebo aspoň jak ta zprávička vyznívá:

    * Zprávička píše, že Trustico chtělo zneplatnit všech cca 50k certifikátů. U těch 23k chápu, že k tomu mohl být dobrý důvod - ale to těch zbylých 27k?
    * Zprávička to dává do souvislosti s přesunem správy certifikátů od Symantecu k DigiCertu a s ukončením jejich spolupráce. To zní, jak by to bylo tím důvodem k revokaci (a celkem to sedí i s tím, že chtěli revokovat všechno).
    * Tomuto vyznění napovídá i fakt, že byl zmíněn explicitně Symantec/DigiCert, a není tu žádná zmínka o jiné CA. Leaknutí privátních klíčů by se ale nejspíš týkalo
    * Z tohoto vychází Trustico jako troubové, kteří chtěli zneplatnit všechny certifikáty z nějakého podivného důvodu, jako je vyřazení z truststore. (O těch 23k, ke kterým měli privátní klíče, se nepřu, tam zase vycházejí jako troubové, protože ty klíče drželi u sebe, ale to je jiná věc. Otázkou je, proč chtěli revokovat i zbylých 27k.)

    Vámi odkázaný link vyznívá trochu jinak:

    * Uvádějí rovnou důvod, tedy že Trustico naznačovalo kompromitaci certifikátů.
    * Bohužel neuvádějí, o kolik certifikátů šlo.
    * Implicitně bych předpokládal, že Trustico chtělo revokovat pouze těch cca 23k certifikátů.

    Tak jako tak, Trustico z toho vychází nezodpovědně. Skladování cizích privátních klíčů a poslání privátních klíčů e-mailem - i jedno z toho by bylo příliš. Jak dobře popsali důvody k revokaci, jestli chtěli revokovat i zdravé certifikáty a jestli jim jejich privátní klíče unikly (a případně jakým způsobem), to je otázkou, ale i bez toho jsou u mě nezodpovědní.

    DigiCert je u mě s otazníkem. Nevím, co přesně došlo z Trustica do DigiCertu. Pokud jim poslali něco ve stylu "okamžitě končíme spolupráci, revokujte úplně všechny certifikáty objednané skrze nás", nedivím se, že tak odmítli učinit bez uvedení důvodu. Ale fakt nemám záznam jejich komunikace.

    K tomu, kdy by měla CA revokovat certifikát: Za mě:

    a. Prokazatelný držitel domény si to tak přeje. Pak nemá CA zkoumat důvody.
    b. Máme dostatečný důvod si myslet, že klíč je kompromitován. Tady by naopak důvod měli mít.

    Toto evidentně nebyla varianta a. Šlo nakonec o variantu b, otázka ale je, kdy měl DigiCert dostatečné důvody. Nejenže bychom se museli shodnout, co je "dostatečné", ale zatím patrně nemáme dostatek informací.

    Mimochodem, nejspíš ani jeden z nás nezná detailně právní podmínky, které měl Symantec. Ať už budeme hodnotit jejich chování jakkoli, museli se držet podmínek, které stanovil Symantec. Ty si sami nenapsali, maximálně je mohli překontrolovat při koupi Symantecu.

  • 2. 3. 2018 21:56

    Filip Jirsák

    Mně teda připadá zajímavé přečíst si o tom něco také z druhé strany –
    Distrusted Symantec SSL Replacement. Dozvíte se tam, že Trusticu prostě přetekl pohár trpělivosti a přestali Symantecu důvěřovat. To nejsou jediní. Pokud nedůvěřujete nějaké certifikační autoritě, je logické nechat odvolat všechny certifikáty, které u ní máte – protože prostě nemáte jistotu, že je bezpečné nechat ty certifikáty aktivní. Tím spíš, pokud už ty certifikáty k ničemu nejsou a nikdo je nepoužívá. Což zatím vypadá dost pravděpodobně, protože se nikde neuvádí, že by klienti Trustica měli nějaké hromadné problémy s odvolanými certifikáty.

    Dále se tam dozvíte, že Symantec má přímo v podmínkách, že přeprodejce je oprávněn jménem vlastníka certifikát revokovat. A také se tam dozvíte, že zaslat privátní klíče e-mailem si vyžádal přímo Symantec.

    Mně z toho tedy vychází nezodpovědně především DigiCert. Věřím tomu, že ty citace podmínek Symantecu a jeho e-mailů jsou pravé, protože kdyby nebyly, Symantec by se už určitě vehementně bránil. Pokud Trustico zvládlo předem vyměnit certifikáty u všech svých klientů a ten požadavek na revokaci certifikátů Symantecu se týkal už nepoužívaných certifikátů, a byl pouhou bezpečnostní pojistkou, je na tom Trustico dost dobře. No a pokud zvládlo zatím vyměnit jenom 23 000 certifikátů, a jak se jim bude postupně dařit měnit další a postupně tahat z cold storage další privátní klíče z těch 50 000 a zasílat je Symantecu k revokaci, budou na tom taky dobře. A myslím, že teď budou mít pro zákazníky pádný argument, že certifikáty od Symantecu fakt nechtějí.

  • 2. 3. 2018 22:47

    Vít Šesták

    > Pokud nedůvěřujete nějaké certifikační autoritě, je logické nechat odvolat všechny certifikáty, které u ní máte – protože prostě nemáte jistotu, že je bezpečné nechat ty certifikáty aktivní.

    Dejme tomu, že mám nějaký certifikát podepsaný autoritou, které nedůvěřuju. Co z toho hrozí? Přímo nic. Ta CA by neměla mít privátní klíč, a pak s tím certifikátem nic nezmůže. Nebezpečí špatné CA spočívá zejména v tom, že by mohla vydat certifikát na moji identitu někomu jinému. (Ve druhé řadě taky v revokaci něčeho, co revokováno být nemělo, ale chování Trustica tu je asi jako ze strachu ze smrti spáchat sebevraždu...) Problém se špatnou CA je potřeba řešit u těch, kteří jí důvěřují, nikoli revokací certifikátů.

    Pokud to v Trusticu tak skutečně mysleli, tak to rozhodl asi někdo, kdo není technicky moc zdatný.

    > Tím spíš, pokud už ty certifikáty k ničemu nejsou a nikdo je nepoužívá. Což zatím vypadá dost pravděpodobně, protože se nikde neuvádí, že by klienti Trustica měli nějaké hromadné problémy s odvolanými certifikáty.

    Zdroj? Kdyby šlo o nepoužívané certifikáty, myslíte, že by se tím Trustico mepochlubilo?

    > Dále se tam dozvíte, že Symantec má přímo v podmínkách, že přeprodejce je oprávněn jménem vlastníka certifikát revokovat.

    Ale zřejmě ta žádost musí být nějak autorizovaná.

    > A také se tam dozvíte, že zaslat privátní klíče e-mailem si vyžádal přímo Symantec.

    Toto už vypadá jako nepořádek na straně DigiCertu. Ačkoli systém revokace evidentně zdědili ze Symantecu, toto zrovna vypadá tak prohnile, že to IMHO měli nahradit něčím lepším. Stačilo by privátním klíčem podepisovat žádost o revokaci, a Trustico si nemuselo ukládat privátní klíče...

    > No a pokud zvládlo zatím vyměnit jenom 23 000 certifikátů, a jak se jim bude postupně dařit měnit další a postupně tahat z cold storage další privátní klíče z těch 50 000 a zasílat je Symantecu k revokaci

    Myslíte, že z cold storage zatím nevytáhli všechno?

    > byl pouhou bezpečnostní pojistkou

    Zkuste jeden úkol. Předpokládejme, že vše v tom článku, co odkazujete, je pravdivé. Vžijte se do role útočníka, který má přístup k celé infrastruktuře Symantecu, nebo aspoň k její části. (Volbu nechám na Vás.) Vymyslete nějaký útok, který:

    1. by mohl způsobil jiný problém, než jaký způsobilo Trustico samo (tj. nedostupnost) a
    2. byste nemohl provést v případě, že Trustico certifikáty revokuje.

    Pokud takový útok neexistuje a pokud je pravda, co Trustico psalo (tj. mj. že privátní klíče nebyly kompromitovány), pak od Trustica nešlo o krok v zájmu svých zákazníků.

  • 2. 3. 2018 23:20

    Filip Jirsák

    Pokud máte jeden certifikát, o kterém víte všechno, hrozí jenom „drobnosti“ – dojde ke kompromitaci privátního klíče, a vy nebudete schopen certifikát odvolat; nebo prostě na ten privátní klíč přestanete dávat pozor, protože se certifikát už přece nepoužívá, a dojde ke kompromitaci. Ani v takovém případě tedy nedává smysl nechat v platnosti certifikát, který se už nepoužívá.

    Pokud ale těch certifikátů mám desítky tisíc, a certifikační autoritě jsem přestal důvěřovat, znamená to, že i mezi těmi desítkami tisíc certifikátů mohou být takové, u kterých třeba validace neproběhla tak, jak měla. Což je pádný důvod k revokaci.

    Problém se špatnou CA je potřeba řešit u těch, kteří jí důvěřují, nikoli revokací certifikátů.
    To je zase to vaše binární vidění. Pokud má Certico podezření, že na doménu některého z jejich zákazníků byl vydán certifikát neoprávněně, je logické, že ten certifikát nechá odvolat.

    Pokud to v Trusticu tak skutečně mysleli, tak to rozhodl asi někdo, kdo není technicky moc zdatný.
    Proč? Pokud skutečně stihli všem vydat náhradní certifikáty, nezpůsobilo Trustico nikomu žádný problém, ale ukázali na to, že Symantec/DigiCert jsou na tom stále špatně.

    Zdroj? Kdyby šlo o nepoužívané certifikáty, myslíte, že by se tím Trustico mepochlubilo?
    Odhad. Kdyby šlo o používané certifikáty, Trustico by pravděpodobně všude uvádělo, že to se zákazníky řeší a že všem bude poskytnuta maximální možná podpora a kompenzace.

    Ale zřejmě ta žádost musí být nějak autorizovaná.
    To tam vidíte napsané kde?

    Stačilo by privátním klíčem podepisovat žádost o revokaci, a Trustico si nemuselo ukládat privátní klíče...
    Pochybuju o tom, že si ty privátní klíče ukládali jen kvůli revokaci. Ale hlavně, důkaz vlastnictví privátního klíče nemůže být jediným způsobem, jak certifikát revokovat. Typický případ, kdy budu chtít certifikát revokovat, je ten, když mám klíč na USB tokenu nebo čipové kartě a ty fyzicky ztratím, nebo přestanou být funkční. V takovém případě samozřejmě důkaz vlastnictví privátního klíče nikomu nepodám.

    Myslíte, že z cold storage zatím nevytáhli všechno?
    Považuju to za docela pravděpodobné.

    Vymyslete nějaký útok, který:
    Opravdu vás něco tak jednoduchého nenapadne? Např. CA špatně postupovala při validaci a vystavil certifikát i na jméno, které nevalidoval. Například zákazník chtěl certifikát pro example.com a www.example.com, tato dvě jména také prošla validací, ale následně byl vystaven certifikát na *.example.com. Pokud by takový případ nastal, nebo máte takové podezření, je v zájmu vašeho zákazníka ten certifikát revokovat.

    Nedostupnost je pouze vaše ničím nepodložená spekulace. Pokud by k něčemu takovému došlo, nemyslíte, že by se ozývali postižení zákazníci, že by na to upozorňoval Symantec, že by se za to Trustico omlouvalo?

    pak od Trustica nešlo o krok v zájmu svých zákazníků
    Jak to že ne? Nepoužívaný neodvolaný certifikát je bezpečnostní riziko. Certifikát, který byl možná vydán neoprávněně, je bezpečnostní riziko.

  • 3. 3. 2018 9:16

    Vít Šesták

    > Pokud máte jeden certifikát, o kterém víte všechno

    O certifikátech by měli vědět všechno (včetně příslušného private key) zejména vlastníci. V tomto případě o části z nich věděl i reseller (Trustico). I podle toho, co píše Trustico, nebyly důvody si myslet, že něco z toho má v rukou DigiCert/Symantec.

    > nedává smysl nechat v platnosti certifikát, který se už nepoužívá

    Ano, ale:

    1. To, zda se používá, by měla být starost spíše koncových zákazníků.
    2. Jste si jist, že žádný z těch 50k certifikátů se skutečně nepoužíval? V takovém množství mi to přijde silně nepravděpodobné. Kdyby chtěli revokovat jen podmnožinu, nebylo by to aspoň tak podezřelé.

    > Pokud má Certico podezření, že na doménu některého z jejich zákazníků byl vydán certifikát neoprávněně, je logické, že ten certifikát nechá odvolat.

    A měli dostatečný důvod podezřívat všechny? V mnohých případech mohli zkusit něco jako domain validation, tedy ověřili by si, jestli to skutečně nikdo nepoužívá... Kdyby se snažili revokovat jen subset (i kdyby to byla drtivá většina), dalo by se tomuto snad věřit.

    > Pochybuju o tom, že si ty privátní klíče ukládali jen kvůli revokaci.

    Je to jediný důvod uváděný ve vámi odkazovabém článku od Trustica a taky asi nejospravedlni­telnější důvod.

    > Ale hlavně, důkaz vlastnictví privátního klíče nemůže být jediným způsobem, jak certifikát revokovat.

    Což ale není v rozporu s tím, co jsem psal.

    > Například zákazník chtěl certifikát pro example.com a www.example.com, tato dvě jména také prošla validací, ale následně byl vystaven certifikát na *.example.com.

    Což je zrovna celkem ověřitelná věc a ne důvod k plošné revokaci všeho.

    > Nedostupnost je pouze vaše ničím nepodložená spekulace. Pokud by k něčemu takovému došlo, nemyslíte, že by se ozývali postižení zákazníci, že by na to upozorňoval Symantec, že by se za to Trustico omlouvalo?

    Jako třeba e-mail od DigiCertu? https://mobile.twitter.com/mpag/status/968819119763025920

  • 3. 3. 2018 11:05

    Filip Jirsák

    O certifikátech by měli vědět všechno (včetně příslušného private key) zejména vlastníci. V tomto případě o části z nich věděl i reseller (Trustico).
    Trustico například nevědělo, jak pečlivá byla validace ze strany Symantecu.

    I podle toho, co píše Trustico, nebyly důvody si myslet, že něco z toho má v rukou DigiCert/Symantec.
    Stále vycházíte z mylného předpokladu, že jediný problém, který může s certifikátem, nastat, je únik privátního klíče. Jenže to není pravda, dalším problémem je to, pokud je certifikát vydán někomu, komu být vydán neměl – například kvůli špatnému ověření. Tohle je přesně problém, který může nastat u certifikační autority. A je to přesně ten problém, který u Symantecu nastal – proto je přece omezována důvěra v certifikáty Symantecu v Chrome a ostatních prohlížečích.

    To, zda se používá, by měla být starost spíše koncových zákazníků.
    Ano, ale přeprodejce o používání může mít docela dobrý přehled, pokud zákazníkovi nabídne výměnu a komunikuje s ním o tom.

    Jste si jist, že žádný z těch 50k certifikátů se skutečně nepoužíval? V takovém množství mi to přijde silně nepravděpodobné. Kdyby chtěli revokovat jen podmnožinu, nebylo by to aspoň tak podezřelé.
    Vždyť revokovali dvacet tři tisíc z padesáti tisíc. To snad není podmnožina?

    A měli dostatečný důvod podezřívat všechny?
    Ano, protože je všechny vydal Symantec. Certifikáty od jiných CA odvolat nechtěli.

    Je to jediný důvod uváděný ve vámi odkazovabém článku od Trustica a taky asi nejospravedlni­telnější důvod.
    Pokud certifikační autorita nutí držet privátní klíč kvůli revokaci, je to hodně špatné. Za prvé může být potřeba certifikát revokovat, i když o privátní klíč přijdete – pak jsou asi zákazníci vděční, že ho má i Trustico, pokud to Symantec jinak neumí. A hlavně revokaci certifikátu lze ověřovat i jinak, třeba heslem, které si zákazník zvolí při vystavení certifikátu.

    Což ale není v rozporu s tím, co jsem psal.
    Je, viz výše. Pokud existují i jiné možnosti revokace certifikátu, než přístup k privátnímu klíči, nemusí mít přeprodejce vůbec přístup k privátnímu klíči – a tak by to mělo být.

    Což je zrovna celkem ověřitelná věc a ne důvod k plošné revokaci všeho.
    Jedině pokud máte stroj času a můžete se vrátit do okamžiku, kdy byla prováděna validace.

    Jako třeba e-mail od DigiCertu?
    E-mail, ve kterém DigiCert bezdůvodně předpokládá, že ty certifikáty někdo používá? Pro mne není podporou pro vaši spekulaci to, že stejně spekuluje i někdo jiný, kdo navíc má zájem na tom, aby to bylo tak, jak spekulujete.

  • 3. 3. 2018 11:28

    Vít Šesták

    Nechce se mi reagovat na všechno, ale:

    > Vždyť revokovali dvacet tři tisíc z padesáti tisíc. To snad není podmnožina?

    Původně chtěli revokovat všech 50k. To není podmnožina. Že klíče měli jen k podmnožině, to je druhá věc.

    > Pokud certifikační autorita nutí držet privátní klíč kvůli revokaci, je to hodně špatné.

    Tady se nepřeme. To je nepořádek Symantecu a do jisté míry i věcí Trustica, že na to přistoupili. A taky DigiCertu, když nevylepšili postupy Symantecu.

    > Jedině pokud máte stroj času a můžete se vrátit do okamžiku, kdy byla prováděna validace.

    Mohu napsat skript, který zkontroluje, které certifikáty se právě používají u DV to bude cca ekvivalentní původnímu ověření. Ano, může mi to v pár případech certifikát označit jako nepoužívaný, ačkoli používaný je, ale pořád lepší než revokovat vše.

    > E-mail, ve kterém DigiCert bezdůvodně předpokládá, že ty certifikáty někdo používá?

    Přesvědčí vás něco jiného než přiznání od Trustica, že to vzali příliš zostra? Tato diskuze mě už unavuje...

  • 3. 3. 2018 12:07

    Filip Jirsák

    Původně chtěli revokovat všech 50k.
    Zdroj? Trustico uvádí, že je padesát tisíc postižených certifikátů. Předpokládám, že by je chtěli postupně revokovat, jak by je nahrazovali jinými certifikáty.

    Že klíče měli jen k podmnožině, to je druhá věc.
    Zdroj? Mně připadá pravděpodobnější, že padesát tisíc je celkový počet postižených certifikátů, a z toho už dvacet tři tisíc certifikátů stihli vyměnit.

    Mohu napsat skript, který zkontroluje, které certifikáty se právě používají u DV to bude cca ekvivalentní původnímu ověření. Ano, může mi to v pár případech certifikát označit jako nepoužívaný, ačkoli používaný je, ale pořád lepší než revokovat vše.
    Víte vůbec, co je validace? Už po několikáté píšete, jako byste vůbec nevěděl, co dělá certifikační autorita. Ověření vlastnictví domény vůbec nesouvisí s tím, zda se pak certifikát používá nebo nepoužívá.

    Při vydání DV certifikátu musí certifikační autorita ověřit, že žadatel o certifikát má právo disponovat s danou doménou. Ideální by bylo ověřovat to přes DNS, ale běžně se to dělá i přes web server nebo přes e-mail. Dejme tomu, že by se ověřovalo přes webserver a s kódem pro ověření by se zacházelo stejně „velkoryse“ jako s privátním klíčem, tj. znalo by ho i Trustico. Teď by zjistili, že ten soubor na serveru není. Znamená to, že byl certifikát vydán neoprávněně? Neznamená, v okamžiku validace tam mohl být.

    Pokud mám podezření, že certifikáty mohly být vydány neoprávněně, je potřeba je revokovat. V praxi se to u takovýchhle hromadných případů odkládá, aby vlastníci měli čas zařídit si jiný certifikát. Vzpomeňte si třeba na WoSign, nebo ostatně na Symantec. Chápu váš postoj, že byste s WoSign ani Symantecem nic nedělal a jedině pokud by vám někdo strčil až pod nos certifikát, u kterého by nade vší pochybnost prokázal, že byl vydán neoprávněně, revokoval byste ten jediný certifikát. Akorát že to by nemělo nic společného s bezpečností, to by se pak ty certifikační autority mohly rovnou zrušit.

    Vy se pořád bráníte revokaci a tváříte se, že jakákoli revokace certifikátu je špatná – ale nikdy jste nenapsal, proč by měla vadit.

    Přesvědčí vás něco jiného než přiznání od Trustica, že to vzali příliš zostra? Tato diskuze mě už unavuje...
    Já vycházím z vyjádření DigiCertu i Trustica. To, co tvrdím, je v souladu s oběma prohlášeními, a nepředpokládá to lež ani v jednom z těch prohlášení. Vy stavíte na spoustě ničím nepodložených spekulací – nedivím se, že obhajovat takové spekulace je únavné. Přesvědčilo by mne leccos, ale ničím nepodložené spekulace mne fakt nepřesvědčí.

  • 1. 3. 2018 10:07

    SSLmentor.cz (neregistrovaný) ---.vivo.cz

    Trustico není CA, Trustico je dodavatel certifikátů od CA, takže zprostředkovatel.

    Podle všech dostupných informací generovali zákazníkům klíče. Mají na webu info - "CSR není potřeba".
    Takže jim asi hackli systém a klíče unikly. K revokaci jiných než takto generovaných certifikátů není důvod.
    Lze se jen dohadovat, zda celé to vyjádření ohledně ukončení spolupráce s Digicert nejsou jen tanečky kolem ještě většího průseru. Rozhodně Trustico k tomu žádné informace nepublikuje a požadavek o zneplatnění posílali již začátkem února.

    Petr

  • 1. 3. 2018 10:26

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Taky bych rád věděl, co se v Trusticu stalo.

    Takováhle tajemná sebevražda je docela záhada. A mlčení o průšvihu je v řetězci důvěry jenom pojistka rychlé smrti.

  • 1. 3. 2018 14:07

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Hehehe... A při vygenerování klíče se to tam dostávalo jak? Přes napadnutelno cache, kterou 1x za měsíc vypálili na CD? Nebo disk, na který měl jejich web server přístup write only a uživatelé s UID 1000-1500 měli RW? Na takový kosočtvercoviny jako nenapadnutelný cold storage pro webovou službu tak nějak nevěřím.

  • 5. 3. 2018 8:08

    Petr M (neregistrovaný) ---.145.broadband16.iol.cz

    Jak to tady sleduju, diskuse o ...

    1) Jsou tady dvě smlouvy (zákazník - přeprodejce, přeprodejce - CA). Zákazník komunikuje pomocí přeprodejce a ten nabídne balík nějakých služeb (vystavení certifikátu, technickou podporu,...) .
    2) Zákazník má jednoznačně právo revokovat certifikát a přeprodejce mu musí poskytnout způsob, jak to udělat, nebo ho informovat o postupu. Pokud to nabídne sám, měla by to být součást obou smluv.
    3) Pokud přeprodejce zjistí, že CA není důvěryhodná, může kontaktovat zákazníka (kontakt na něho samořejmě má), sdělit mu svoje zjištění a nabídnout zdarma certifikát jiné CA s tím, že doporučuje, aby jedním kliknutím v jejich API poslal staré CA žádost o revokaci.
    4) Pokud se zákazník ztotožní s jejich názorem, vystaví si nový certifikát a revokuje starý. Nebo starý smaže (a když přeprodejce náhodou nemá kopii, neexistuje soukromý klíč a nikdo ten existující certifikát nemá jak zneužít).
    5) Podle chování obou stran bych řekl, že si ty firmy nemají co vyčítat (jedna nedělá, co má a druhá dělá co nemá) a být zákazník, najdu si pro sychr jinýho dealera s jinou CA.

    P.S. Bod 4 možná bude ten důvod - nevěděli, jestli zákazníci ještě mají PK a nechtěli riskovat.

  • 5. 3. 2018 9:11

    Miroslav Šilhavý

    Jsou tady dvě smlouvy (zákazník - přeprodejce, přeprodejce - CA). Zákazník komunikuje pomocí přeprodejce a ten nabídne balík nějakých služeb (vystavení certifikátu, technickou podporu,...) .

    Hlavní premisa je, že certifikát, ač o něm hovoříme v mužském neživotném rodě, jako by to byla věc, je ve skutečnosti soubor služeb. CA musí zajistit, že je důvěryhodná v určitém seznamu prohlížečů (technologií), vystaví certifikát a po smluvenou dobu zajistí, aby byl akceptovaný a zajišťuje přístup do revokační služby. Tedy, není to zboží, ale služba. (Zvažoval jsem ještě nehmotný majetek, ale vzhledem k nulové hodnotě - možnosti ho prodat, mi to do ani do nehmotného majetku nesedí).

    Jsou tři typy vztahů, které připadají v úvahu:
    1. přeprodej - pak přeprodejce jedná svým jménem a na svůj účet,
    2. zmocnění - pak zmocněnec jedná jménem zmocnitele a na jeho účet,
    3. zastoupení (mandát) - pak mandatář jedná jménem mandanta (klienta),
    4. zprostředkování - zprostředkovatel jedná svým jménem, ale na účet zájemce (tedy CA).

    ad 1) Přeprodej ani mandát to podle mého názoru nejsou, protože výstava a správa certifikátů je služba poskytovaná průběžně, je zcela nehmotná. Výstavcem certifikátu je CA, nikoliv přeprodejce, ten by tam jinak musel být jako nabyvatel (a to by zcela postrádalo logiku). Přeprodejce jedná svým jménem a na svůj účet.

    ad 2) Zmocnění připadá v úvahu v obou směrech. CA může zmocnit "toho uprostřed", aby uzavřel smlouvu se zákazníkem, stejně jako zákazník může zmocnit "toho uprostřed", aby jí zařídil koupi certifikátu. Podle mě to nesedí ani z jedné strany, protože taková činnost je hmotněprávní a musela by na každý jeden certfikát existvovat jedna konkrétní plná moc. Pochybuji, že to tak je. (Oproti tomu na procesněprávní úkony lze užít plnou moc generalizovatnou, ale to není tento případ). Kdyby se jednalo o současné zmocnění z obou stran, je už situace blízká zprostředkování. Zmocněnec jedná jménem zmocnitele a na jeho účet.

    ad 3) Mandát přichází v úvahu čistě technicky (zákazník pověří firmu, aby mu zařídila certifikát). Tomu ale neodpovídá charakter nabízené služby. Mandatář jedná svým jménem a na účet mandanta (koncový zákazník).

    ad 4) Ze všeho nejvíc mi vychází charakter zprostředkovatelské smlouvy. Zájemce (v tomto případě CA) pověří zprostředkovatele, aby mu vyhledával vhodné zákazníky. Zprostředkovatel pak zajistí uzavření smlouvy mezi zájemcem (CA) a zákazníkem (koncový uživatel). Za to obdrží provizi. Zprostředkovatel jedná svým jménem a na účet zájemce (CA)

    K variantě zprostředkování mě přiklání i to, že výstavcem zůstává CA, držitelem koncový zákazníky. Záruky za provoz certifikátu drží CA, nikoliv zprostředkovatel.

    Je dost pravděpodobné, že smlouva bude kombinovaná. Tedy, že z části bude zprostředkovatelská a z části si zprostředkovatel přihřeje svoji polívčičku nějakou svou službou. Kombinace dvou smluv do jednoho dokumentu nemění jejich nezávislý charakter.