Názory k článku Let's Encrypt už není beta, zůstávají však nesplněné sliby
-
Filip JirsákStříbrný podporovatelTy limity se předpokládám počítají v rámci domén druhé úrovně, tj. za týden je možné vystavit 20 certifikátů pod doménou example.com a dalších dvacet pod doménou example.org.
-
Ondřej CaletkaZlatý podporovatelAno, je to přesně tak. Ještě přesněji nejde čistě o doménu druhé úrovně ale doménu na seznamu https://publicsuffix.org/
-
Ondřej CaletkaZlatý podporovatel
Nechal jsem do článku přidat poznámku, že limity se týkají jednoho doménového jména. Přesně se tím myslí jedno jméno plus veřejná koncovka ze seznamu https://publicsuffix.org
-
Ondřej CaletkaZlatý podporovatel
Nepochopil. Nejde o důkaz držení privátního klíče nově vydávaného certifikátu, ale o důkaz držení privátního klíče existujícího certifikátu. Takže útočník by kromě únosu síťového provozu musel také ukrást privátní klíč ze serveru oběti.
-
Palo (neregistrovaný)
Aha jasne, dik. Potom by uz ale bolo jednoduchsie/bezpecnejsie aby si uzivatelia/admini ktory robia vela certifikatov urobili nejaky osobny certifikat a s tym by potom podpisovali poziadavky. Keby doslo k nejakemu fake utoku zrusili by sa vsetky certifikaty daneho uzivatela/admina.
-
Ondřej CaletkaZlatý podporovatel
Všechny certifikáty Let's Encrypt jsou už nyní vázané k tzv. ACME účtu, což je něco jako osobní certifikát pro stroj, který o certifikáty žádá.
Dokonce se pracuje se na rozšíření CAA záznamů v DNS, aby umožňovaly kromě identifikace certifikační autority i identifikaci konkrétního ACME účtu. Majitel domény si tak bude moci DNS záznamem určit nejen, že pro danou doménu má vydávat certifikáty pouze Let's Encrypt, ale i který jediný ACME účet může certifikáty vydávat.
-
Ondřej CaletkaZlatý podporovatel
To se odvíjí od toho, kdo bude validovat. TLSA záznamy musí validovat každý účastník komunikace, a zatím to skoro nikdo nedělá. Kdyby to ostatně dělal, nebude vůbec potřeba zřizovat autoritu Let's Encrypt, protože si vystačíme se self-signed certifikáty.
CAA záznamy proti tomu validují pouze certifikační autority a už dnes to dělají, takže tento způsob je účinný teď hned.
-
Lol Phirae (neregistrovaný)
TLSA záznamy musí validovat každý účastník komunikace, a zatím to skoro nikdo nedělá.
Bodejť by to taky dělal, když nemá jak, že...
CAA záznamy proti tomu validují pouze certifikační autority a už dnes to dělají, takže tento způsob je účinný teď hned.
Účinný k čemu? Jako že krom toho, že mám věřit jakési podiférní CA, tak ještě k tomu mám věřit tomu, že si v době vydání ověřila CAA záznam, přičemž pokud se od té doby změnil, tak to stejně podle specifikace nemá žádný vliv na to, že je prý vše OK? To je validace jak pojď do mě z boku.
-
Ondřej CaletkaZlatý podporovatel
CAA záznam vám umožní snížit množství útočných vektorů. Pokud máte například kontrakt s nějakou autoritou, můžete pomocí CAA vynutit, aby ostatní autority (včetně Let's Encrypt) pro vaší doménu certifikáty nevydávaly. Vzhledem k relativně malému množství certifikačních autorit je zde navíc reálná naděje, že brzy žádná autorita nebude důvěryhodná, pokud kontrolu CAA nebude implementovat.
Proti tomu implementace TLSA validace velmi pravděpodobně nebude stoprocentní ani za 10 let.
-
CAA záznam osobně považuju za úplný nesmysl, z několika důvodů.
CA, které nejsou v CA/B fóru na to všechno můžou zvesela hodit bobek. I kdyby CAA záznam normálně kontrolovaly, tak hádám, že v případě *. certifikátů pro state-funded útočníky na něj zrovna koukat nebudou.
Netuším, co je "relativně malé množství certifikačních autorit", ale ze SSL Observatory vypadlo úplně něco jiného než "relativně malé množství" - viz třeba tahle mapka: https://www.eff.org/files/colour_map_of_cas.pdf a CAA záznam musí podporovat úplně všechny tyto CA.
-
Ondřej CaletkaZlatý podporovatel
I kdyby CAA záznam normálně kontrolovaly, tak hádám, že v případě *. certifikátů pro state-funded útočníky na něj zrovna koukat nebudou.
Stejně tak se můžu pustit do DNSSECu, že i když registry implementují třeba zamykání údajů na úrovni registru, tak to nepomůže proti state-funded útočníkům. U nás třeba i bez soudního příkazu.
…ze SSL Observatory vypadlo úplně něco jiného než "relativně malé množství"…
I kdyby důvěryhodných autorit bylo skutečně víc než tisíc, pořád je to o mnoho řádů méně než počet TLS klientů. Ve skutečnosti je těch ale skutečných autorit (ve smyslu entit, které vydávají důvěryhodné certifikáty) výrazně menší množství – například Let's Encrypt je jedna entita, která však provozuje čtyři různé CA (X1, X2, X3 a X4). Nebo třeba sdružení akademických sítí GÉANT má svou vlastní „autoritu“ zvanou Terena SSL CA 3, ale nikdo z GÉANTu od ní nikdy privátní klíč neviděl – ten totiž dodavatel, v tuto chvíli společnosti DigiCert, nedá z ruky. Má taky konečné slovo ke každému certifikátu, takže tahle autorita ve skutečnosti není vlastně vůbec nezávislá.
CAA záznam musí podporovat úplně všechny tyto CA
Nemusí to podporovat všechny. S každou novou se sníží povrch pro útočníka. Když bude CAA záznamy podporovat většina a objeví se incident s autoritou, který bude způsoben nepodporou CAA, bude velmi snadné zbývající autority donutit pod hrozbou vyřazení z důvěryhodných.
-
j (neregistrovaný)
" můžete pomocí CAA vynutit" ... ehm lol ... a to jako jak? Ne to opravdu nemuzu. Je to PRESNE totez, jako trebas SPF. Adresat to MUZE ale NEMUSI.
Implementace TLSA je otazka par radku kodu, ale ono se na to musi kurwa politicky, ze Halik ... protoze prave naprosta nadbytecnost CA v !bezne! komunikaci je neco, co se nesmi dopustit.
Misto picovin jako talk, ruseni addonu a pluginu, ... by se melo zaintegrovat prave tohle https://www.dnssec-validator.cz/
A to odkazuju presto, ze jiny aktivity NICu zasadne neschvaluju.
-
Lol Phirae (neregistrovaný)
vyhodis so zoznamu v browseri a HOPS uz je namiesto zelenej cervena
A s příští aktualizací prohlížeče ho mám zpět (Firefox), případně si ho OS stáhne sám od Microsoftu. Takhle se to opravdu nedělá.
Kefalin a skuste mi naznacit ako si predstavujete to overenie bez toho aby ste nejakej 3tej strane doverovali?
Viz TLSA. Možná by to chtělo před tím, než budete reagovat, pročíst i zbytek diskuse.
CAA je uživatelům úplně k ničemu, to je věc, která pro ně není vůbec určená. To, že CAA záznam nesouhlasí s vydaným certifikátem, není dle tohohle geniálního vynálezu důvodem k tomu, aby ten certifikát považoval za nedůvěryhodný, jediné, k čemu to má sloužit je to, že by CA neměla ten certifikát vydat. No, ona by taky neměla vydat certifikáty Googlu nebo Microsoftu podvodníkům, a přesto se tak děje furt dokola.
-
Ondřej CaletkaZlatý podporovatel
To není ani tak náhrada, jako spíš zbavení se certifikačních autorit. V současném modelu je totiž potřeba důvěřovat jak CA, tak i systému DNS – když někdo zmanipuluje DNS, může si vydat certifikát od CA.
Při použití DNSSECu a TLSA záznamů je možné CA z procesu eliminovat a důvěřovat pouze systému DNS. Systém by tedy měl být jako celek bezpečnější.
-
Filip JirsákStříbrný podporovatel
Nejde o úplné zbavení se certifikačních autorit. Jde pouze o zbavení se DV certifikátů, které CA začaly vydávat jako „levné certifikáty“, a které jsou nesmyslné (CA certifikátem potvrzuje vlastnictví domény, které ale potvrdit nemůže).
Certifikační autority, které vydávají certifikáty subjektů (osobám, firmám), mají pořád svůj význam.
-
j (neregistrovaný)
Co nechapes na tom, ze vyradis zcela nadbytecnou cast retezu a tudiz narosto razantne redukujes potencial k utoku?
Kdyz lezes na web ... tak zcela ucite potrebujes dns. (nebavme se o tom, ze zadas IP, stejne si nepomuzes). Tzn, pokud ti DNS vraci nejakou odpoved, tak ji muzes nebo nemusis verit (a je sumafuk, jestli ma nebo nema DNSSEC), ale pokud uz ji teda veris, a tudiz na ten web vlezes, je zcela zbytecny do toho tahat jeste nejakou CA, ktera stejne da certifikat komukoli. V pripade ze budes verit DNS mas minimalne jistotu, ze ten nekdo vazne ma k DNS pristup.
V pripade CA vubec netusis, jak proc a komu vlastne ten cert vydala.
Protoze tady je naprosto primarne rec o tom, ze se sifruje komunikace mezi tebou a serverem, vubec neni reci o tom, ze by se nejak overovala identita tvoje nebo serveru.
A je to vlastne cely jen dusledek toho, jak naprosto imbecilne se browsery chovaj. Protoze misto aby sme teda rekli "neprudte uzivatele kokotskejma hlaskama o nebezpeci", ale umoznete mu certifikat NEBO CA pro ten KONKRETNI web autorizovat, tak se radsi vymysli "CA", ktera da certifikaty komukoli a prohlasi se za duveryhodnou ... lol. Tzn, vysledek je naopak razantni zhorseni bezpecnosti. Protoze kdyz si necham vydat certifikat na českáspořitelna.com (je volna, takze si ji muzu regnout) a na ni skopipruju web ... tak kolik tisicin promile useru bude resit ze to je na com? A sviti to zelene, takze sou prece v bezpeci. Pritom browser by to mel povazovat zanaprosto anonymni a tudiz "neduveryhodny", protoze sem nijak ten web neautorizoval. Zato kdyz vlezu na web, kde je selfsign, prave a pouze proto, aby se sifrovalo, tak se z toho browser muze posrat ... ale je to PRESNE totez.
-
Ondřej CaletkaZlatý podporovatel
No, ona by taky neměla vydat certifikáty Googlu nebo Microsoftu podvodníkům, a přesto se tak děje furt dokola.
Tohle není úplně fér, k podobným incidentům došlo ještě před implementací blacklistů a CAA; ty byly implementovány právě na základě těchto skandálů. Takže „děje se to pořád dokola“ je poněkud zavádějící.
-
j (neregistrovaný)
Ne, jen to je realita, a ani zadny blacklist nepomuze. Protoze to bude fungovat tak maximalne v okamizku, kdy se "falesny" cert objevi verejne v siti. Ale pokud se pouzije jen proti vybrany casti site, tak se jaksi nijak nezjisti, ze nejakej dalsi cert vubec existuje.
A samo, pak muzem zacit resit, kolik % lidi resi pripadny zneplatneni certifikatu, alternativne, jak se pekne daji useri pomoci toho smirovat.
-
Ondřej CaletkaZlatý podporovatel
Podle statistik to ani zdaleka nevypadá, že by validace pomocí
dns-01byla nějak zásadně populární. Ona se také velmi obtížně automatizuje. Jen málo kdy je webserver zároveň DNS serverem. -
lol (neregistrovaný)
nevidim zasadny problem preniest certifikat z DNS serveru ktory ho ziska na webserver. Rovnako ani poslanie commandu cez ssh z webserveru na DNS server aby zalozil DNS zaznam s response aby webserver ziskal certifikat
Osobne dns-01 pouzivam cez letsencrypt.sh - zo vsetkych moznosti to je najjednoduchsie a najcistejsie.
-
Ondřej CaletkaZlatý podporovatel
V čem je validace pomocí HTTP horší než validace pomocí DNS, nebo třeba než validace automatický e-mailem na hostmastera? Podle mě jsou všechny v zásadě ekvivaletní z hlediska bezpečnosti.
-
lol (neregistrovaný)
Vystavit subor niekde na webe je ovela jednoduchsie nez vystavit dns zaznam pre danu domenu. Staci jeden deravy script. Nezabranila by tomu ani specialna hlavicka (ktora vypadla z podmienok), kedze cez .htaccess sa da toho spravit tolko...
Ani DNS validacia nie je terno... obecne DV je cela naprd. Tieto certifikaty nie su o nic bezpecnejsie nez self-signed.
-
Lol Phirae (neregistrovaný)
obecne DV je cela naprd. Tieto certifikaty nie su o nic bezpecnejsie nez self-signed.
Hurá. Takže bychom se mohli konečně shodnout, že ty certifikáty mají zajistit šifrování komunikace a na ty tanečky okolo (včetně příšerného opruzování uživatelů v prohlížečích) se konečně vysr*t a že k tomu žádné "důvěryhodné" CA nepotřebujeme?
-
Ondřej CaletkaZlatý podporovatel
K šifrování komunikace certifikáty nejsou vůbec potřeba. Na to stačí anonymní TLS, jaké se používá třeba u Nagiosu (NRPE) nebo u některých SMTP serverů. Certifikáty vždy slouží pouze k autentizaci.
-
Filip JirsákStříbrný podporovatel
Pokud nám nevadí, že obsah šifrované komunikace může útočník odposlouchávat, pak autentizaci protistrany opravdu nepotřebujeme.
-
Ondřej CaletkaZlatý podporovatel
Mně teda nadává pokaždé, když server změní klíč. A nedá se to snadno odklepnout. To má být to správné chování? Ke každému doménovému jménu jeden klíč zabetonovaný na vždy?
-
j (neregistrovaný)
Tak proc si ten klic menis? Neni k tomu zadnej duvod. Nemluve o tom, ze SSH se chova asi tak milionkrat lip. Protoze ti umoznuje prave tu autorizaci konkretniho klice pro konkretni stroj => pokud se zmeni, tak MUZE byt neco spatne. Ale to, ze sam o sobe je selfsign, mu vubec neva.
Jinak prave proto je tu TLSA a pro SSH pak trebas SSHFP.
-
Ondra Satai NekolaZlatý podporovatelNenapadlo te, ze to jsou uplne ruzne situace? Ze je obrovsky rozdil mezi stroji, ktere mas (nebo tva organizace) pod kontrolou, a stroji tam kdesi venku?
-
Filip JirsákStříbrný podporovatel
Ale me je sumafuk jestli na druhy strane je franta nebo pepa ... ja chci sifrovat to spojeni ...
Jasně. Nevadí, že komunikujete s útočníkem, ale hlavně, když je to šifrované.narozdil od CA nesmyslu pak tady mam i ten bonus, ze u ssh muzu zcela jednoduse zjistit, ze komunikuju se stejnym pepou co minule
V případě SSH to můžete zjistit, když vám server pošle stejný veřejný klíč. V případě HTTPS, když vám server pošle stejný veřejný klíč, nemůžete to zjistit, protože… -
j (neregistrovaný)
Nj jirsak dment samo netusi, ze pokud bude na webu zcela JINY klic, ale podepsany CA, kterou mi nejakce imbecil z Mozilly/M$/Googlu natlaci do browseru v ramci aktualizaci, tak bude browser ZCELA spokojen. Takze je ti jirsak to, ze si pridas konkretni cert zcela khovnu. Protoze neexistuje zadnej zpusob jak rict, ze pouze a vyhradne tento klic ma byt pouzivan na tomto webu.
Jasne, jeste muzu pri kazdym kliknuni na webu kontrolovat (rucne) jestli sedi fingerprint ... proti tomu, co si napisu nekam na papir ... jo, to mame uzasnej SW ...
-
Ondra Satai NekolaZlatý podporovatel
j: a tak to vypada, kdyz nekdo skonci u cteni skript u Alice a Boba, nez se tam zamichaji dalsi postavy.
(povinny odkaz na xkcd: https://xkcd.com/177/ )
-
-
Lol Phirae (neregistrovaný)
Já nevím, na koho to je tedy reakce, protože díky geniálnímu vylepšení diskusí z dílny žižkovských studentíků to prostě není vidět, ale co přesně nefunguje na tom TLSA, nebo co nefunguje na SSHFP, proč tady vymýšlíme kraviny typu CAA záznamy, které jsou uživatelům v tomto směru úplně k ničemu a nějaké podobné pseudometody ověřování, které nic neřeší. Furt v té diskusi žádnou rozumnou odpověď nevidím.
-
Souhlasím, TLSA mám rád a používám. Ale bohužel tvůrci prohlížečů s ním mají zásadní problém. On by totiž prohlížeč nejdřív musel začít validovat DNSSEC a až pak se dá použít TLSA a SSHFP. No a třeba v Chrome chvíli ten kód byl, ale pak ho vyhodili, protože to byla režie navíc a zpomalovalo to přístup k webu :-(. Byl bych moc rád, kdyby se to prosadilo.
-
j (neregistrovaný)
A s cim maji tvurci browseru presne problem, kdyz existuje addon, kterej to dela? Jo aha, oni nezvladnou ani daleko primitivnejsi veci ... https://bugzilla.mozilla.org/show_bug.cgi?id=14328 .. mozna za dalsich 15 let to bude umet srv, a tudiz tlsa tak nekde kolem roku 2100.
Zato maji spoustu casu integrovat hovadiny, ktery nikdo nanic nepotrebuje.
-
Jenda (neregistrovaný)
janek: Já tu k SSH nepřirovnával.
Petr Krčmář: Já vím, že to jinde takhle nejde, ale předřečník si bohužel vybral jeden z mála příkladů, kde to jde.
Mimochodem - jakým způsobem jsem se dozvěděl, že Softcom je důvěryhodný obchod a Centrum je důvěryhodný freemail? Nemohl bych se stejným způsobem („lidovou slovesností“) dozvědět rovnou i otisk jejich klíče?
-
Ondra Satai NekolaZlatý podporovatel
@Jenda:
"A email mam na Centru, super. Mimochodem otisk jejich klice je 9390a42aefd34534df. Jdeme ke mne nebo k tobe?" -
-
Filip JirsákStříbrný podporovatel
Pokud mám důvěřovat tomu starému klíči, není potřeba vydávat klíč nový. Evidentně je ale výměna klíčů (třeba za silnější) všeobecně považována za dobrý nápad.
-
Ondra Satai NekolaZlatý podporovatel
Jak uz psali predrecnici...
U ssh se predpoklada, ze mas jeste nejaky dalsi kanal, kterym resis ty veci, ktere jsou doopravdy tezke. -
Ondřej CaletkaZlatý podporovatel
V případech, kdy je DNS server po ruce, to skutečně může být praktické. V drtivé většině případů je to ale výrazně složitější, případně to vyžaduje ruční práci. Spousta webserverů má například DNS hostováno u registrátora domény.
ČLÁNKY DO MAILU