StartCom jako certifikační autorita končí

Společnost StartCom oficiálně oznámila, že jako certifikační autorita končí. Od 1. ledna 2018 přestane vydávat nové certifikáty a následující 2 roky bude poskytovat OCSP a CRL. Počátkem roku 2020 budou všechny platné certifikáty zneplatněny.

19.11.2017 23:55 | Ladislav Hagara | IT novinky

Komentáře

[Max]

Takže StartCom bylo prodáno WoSign. Následně vědomě vydávaly jednak certifikáty lidem, které na ně neměli nárok, dále certifikáty se starším datem, aby v nich mohli použít sha1. To na ně prasklo a na základě těchto šetření provedených Googlem a Mozillou došlo ze strany těchto firem ke snížení důvěryhodnosti této CA, tedy v chrome a firefoxu/thunderbirdu. Následně se k nim přidal i Apple.
Výsledkem je, že StartCom, aktuálně řízený nějakou Qihoo360, zavírá krám.

Pěknej bazmek.
Zdar Max

[Michal]

Qihoo360... Jsem si říkal, že jsem to už někde slyšel a on je to v podstatě nový vlastník Opery.

[little.owl]

on je to v podstatě nový vlastník Opery

Presne tak. Odvaha nekterych lidi, kteri si nainstaluji binarni blob od neduveryhodne cinske firmy je skutecne obdivuhodna.

[Lobzo]

Navic kdyz mohou pouzivat antivirus od duveryhodne ceske firmy, ktera ho dava zadarmo a stejne na tom vydelava nejake hrozne miliony.

[R]

Ten antivirus, ktory sa sprava ako malware? Spomaluje system, otravuje vyskakovacimi podvodnymi reklamami. Tak vyzera bezpecnost vo Windows...

[Vykook]

A důvěřuje opera starcomu?

[trautenberk]

Celý tenhle systém certifikačních autorit je prohnilý. Radši kdyby se už konečně zavedlo do praxe DANE a s tím související DNSSec (myšleno globálně).
DV certifikáty pro nekritické weby (Wikipedia, abclinuxu.cz,...) by se staly zbytečnými, prohlížeč by pouze ověřoval jestli klíč z DNS sedí s certifikátem serveru. Zůstaly by jen OV a EV certifikáty pro služby, kde opravdu o něco jde (banky atd.).
Jenže to by pak certifikační autority neměly co žrát (kdyby si mohl každý vygenerovat certifikát sám, aniž by potom prohlížeče křičely, že je nedůvěryhodný), a taky nevím jak by se s tím vypořádaly různé korporátní firewally, které dělají na SSL spojení MITM útok.

[Harvie.CZ]

No, s DANE je to slozity. Prohlizece to nechtej implementovat. A ja nevim, jestli to je, protoze jedou v nejaky certifikatovy mafii, nebo systemu vladnich odposlechu. To je paranoia, ale kdo vi. Dal jsou tady nejaky dalsi technicky duvody:

Jak funguje DANE pokud nemam DNS validujici resolver? Veme proste vsechny certifikaty co nekdo (treba ISP pod soudnim prikazem) prida do DNS trafficu? Existuje mechanismus jak prohlizec pozna jestli ma DNS odpovedi z duveryhodnyho zdroje? To je asi duvod, proc to prohlizece zatim nechtej.

Jediny reseni asi je aby si prohlizec delal rekurzivni DNS dotazy sam, tim se ale efektivne zrusi moznost cachovani na urovni isp/site a teda se vyrazne zvysi DNS traffic na autoritativni servery, protoze si kazda koncova stanice bude resolvovat vsechno sama. Tezko rict, jestli se tohle da nasadit globalne. Asi by bylo potreba aby v cache byl celej chain a jednotlivy klienti si ho mohli overit lokalne na zaklade korenovyho klice, kterej by mely nainstalovanej lokalne.

[trekker.dk]

Existuje mechanismus jak prohlizec pozna jestli ma DNS odpovedi z duveryhodnyho zdroje? To je asi duvod, proc to prohlizece zatim nechtej.

Ve skutečnosti je to ještě jednodušší. Pokud si vzpomínám, Google to asi rok nebo dva zpátky zkusil a dal do Chrome funkci, která testovala, co by se stalo, kdyby se tyhle DNS záznamy měly ověřovat - dělo se to na pozadí a nic dalšího se se zjištěnými informacemi nedělalo. Asi v 5% případů ty DNS dotazy skončily timeoutem - neprošly přes resolver poskytovatele připojení. Kdyby to takhle fungovalo v ostrém nasazení, tak by v těch 5% případů uživatelé museli docela dlouho čekat, než by se jim stránka vůbec začala načítat - nebo si jim naopak nenačetla vůbec.

To je vcelku jasné, že se do nasazení něčeho takového nikdo nehrne.

[Filip Jirsák]

To je docela zavádějící tvrzení. Pokud s těmi dotazy má problém DNS resolver, který uživatel používá, bude s tím mít problém i za 10 minut i za hodinu. Čili není žádný důvod, aby se to zdržení týkalo každého požadavku, protože prohlížeč by to prostě věděl, že v dané síti DNSSEC nefunguje, a neměl by důvod to zkoušet pořád znova. A dokonce nemusí být zdržen ani první požadavek – zrovna Chrome pokud vím při spuštění komunikuje se servery Googlu, aby zjistil, zda je dostupný internet nebo zda nemusí projít přes nějaký captive portál. Takže by nebyl problém, aby se v rámci téhle komunikace prohlížeč dozvěděl i zprávu „jsi v síti, kde nefunguje DNSSEC, ani to nezkoušej“.

[trekker.dk]

Výborně, teorii byste měl zvládnutou, tak zkusíme otázku na praxi. Jste v situaci, kde DNSSEC nefunguje a/nebo DANE záznamy nelze zresolvovat. Prohlížeč má podle těchto záznamů ověřit platnost SSL certifikátu webu, na který se uživatel zrovna pokouší podívat. Co ten prohlížeč podle vás má udělat?

[Filip Jirsák]

Praktickou ukázku si můžete vyzkoušet sám – spusťte si libovolný prohlížeč a navštivte s ním nějakou stránku přes HTTPS. Uvidíte, co se stane, když prohlížeč nepracuje s DANE záznamy.

[Kate]

Jenže thread začal tvrzením že „DV certifikáty pro nekritické weby (Wikipedia, abclinuxu.cz,...) by se staly zbytečnými“

Osobně by se mi taky DANE líbilo, ale DV certifikáty zatím bohužel nenahradí.

[Filip Jirsák]

Je potřeba rozlišovat mezi vzdálenou budoucností, o které píše Trautenberk, a nedávnou minulostí, o které psal Trekker.dk.

[trekker.dk]

Vlákno se zabývá tím, proč se místo certifikačních autorit pro DV certifikáty nepoužívá DANE. Důvod, který jsem zmínil já, byl, že na 5% systémů tyto záznamy nešlo resolvovat nebo ověřit. Jenom Filip Jirsák dokáže pro takovou situaci navrhnout řešení, že to prohlížeč ani nemá zkoušet.

Samozřejmě si velmi cením toho, že jste mě jako odborník na všechno poctil svými fundovanými vědomostmi, ale pro příště bych vám doporučil přečíst si, k čemu se vyjadřujete.

[Filip Jirsák]

Nikoli, vlákno se zabývá tím, proč se v praxi nepoužívá DANE („kdyby se už konečně zavedlo do praxe DANE“). Vy jste uvedl krásný teoretický příklad, který ovšem nijak nebrání praktickému nasazení DANE v prohlížečích tam, kde se daří DANE záznamy získávat a ověřovat.

Samozřejmě si velmi cením toho, že jste mě jako odborník na všechno poctil svými fundovanými vědomostmi, ale pro příště bych vám doporučil přečíst si, k čemu se vyjadřujete.

[trekker.dk]

Takže se to zavede, ale vlastně nezavede... no... dobře. Ještě něco tam máte?

[Filip Jirsák]

Pro 95 % uživatelů by to fungovalo. Jaký podíl má dnes HTTPS, DNSSEC, IPv6? Neměli bychom to všechno zrušit, když to hned od zavedení nemělo 100 %? Je poněkud trapné, že všeználek jako vy netuší, že pokud je to jenom trochu možné, nové technologie se zavádějí postupně – a situace, kdy to v nejhorším případě funguje stejně, jako dříve, a v lepším případě to funguje lépe, je při zavádění nové technologie ideální stav. Zároveň to zavedení nějaké technologie do praxe je jediný způsob, jak na některé provozovatele zatlačit. V sítích, kde nefunguje DNSSEC, se tím nezabývají s odůvodněním, že to přece stejně nikdo nepoužívá. Takže nezbývá, než to začít používat tam, kde to jde.

[trekker.dk]

To zní opravdu jednoduše a použitelně, je opravdu zajímavé, že na to v Google v Mozille ještě nepřišli. Možná byste jim měl poradit, určitě na vás čekají.

[Filip Jirsák]

Nemyslím si, že by na to nepřišli. Jenom prostě bezpečné používání webu uživateli není jejich priorita. Což ostatně víme i z jiných příkladů – každý den se řeší nějaké úniky hesel, únosy sezení apod. To je způsobené jenom tím, že vrcholem bezpečného přihlášení k webu je webový formulář, kam uživatel zadá heslo, které si pamatuje, web ho autentizuje a uloží si jeho identifikaci do cookie, která se pak posílá s každým požadavkem. Samozřejmě, že existují jednoduchá řešení, která by vyřešila všechny tyhle problémy s hesly a sessions. Ale autory prohlížečů to nezajímá.

[trekker.dk]

Nemyslím si, že by na to nepřišli. Jenom prostě bezpečné používání webu uživateli není jejich priorita.

Což se projevilo tak, že společně zatlačili - úspěšně - na masové nasazení HTTPS... dneska vám to jde, jedna perla za druhou.

[Jendа]

Je to podobně schizofrenní jako třeba Auto*mat. Sice podporují LE, ale současně dělají spoustu bezpečnostních WTF (například posledních 10 let neuvěřitelné opruzy při přístupu k webu se self-signed certifikátem, se slabým šifrováním (ale přes HTTP je to asi OK) nebo ta zmíněná hesla).

[Filip Jirsák]

K tomu, aby to bylo bezpečné, musí dnes uživatel hlídat, že je na webu opravdu přes HTTPS, že tam není vložený nějaký obsah přes HTTP, že má správnou adresu… To, že prohlížeče udělaly jeden krok ze sto nutných, podle mne neznamená, že by to byla jejich priorita. Poslyšte, neměl byste se tak vytáčet tím, že si s vámi někdo dovolí nesouhlasit. Pak děláte takovéhle hloupé chyby, jako že něco, na co se někdo úplně nevykašlal, hned označujete za prioritu.

[trekker.dk]

No vidíte, ještě pár příspěvků zpátky jste tvrdil něco o zavádění nových technologií postupně, ale když prohlížeče postupně vytlačují HTTP ve prospěch HTTPS, tak to nic neznamená. Ale dobrá, takovými detaily bych vás zatěžovat neměl, určitě vás to ruší od tvorby další převratné myšlenky. Už tak se zdá, že jste dost vytočený z toho, že si někdo dovolil s vámi nesouhlasit, když máte potřebu tento svůj pocit vidět u ostatních.

[Filip Jirsák]

tak to nic neznamená

Psal jsem to už v předchozím komentáři, ale zřejmě to stále nechápete. Já jsem psal, že to pro ně není prioritou, to znamená, že to není na prvním místě důležitosti. Vy rozporujete, že není pravda, že by to pro ně nic neznamenalo, tedy podle vás to není na posledním místě důležitosti. To by ovšem platilo pouze tehdy, pokud by ten seznam věcí k řešení byl pouze dvouprvkový. Jakmile je delší, „není na prvním místě“ neznamená „je na posledním místě“.

Za mne je to poslední pokus vysvětlit vám význam spojení „nebýt prioritou“, pokud ho stále nechápete, je to váš problém.

[trekker.dk]

No, než se pustíte do vysvětlování, měl byste nejdřív chápat to, co se pokoušíte vysvětlovat. Priorita nemusí být první místo důležitosti, když je víc věcí, na kterých se dá pracovat současně. V tomto případě není problém, aby prioritou bylo zároveň zvýšení zabezpečení protlačením HTTPS i něco jiného (třeba dostat uživatelům nové funkce.)

Takže pokud jste chtěl tvrdit, že pro ně bezpečnost není na prvním místě, měl jste to tak napsat.

[Filip Jirsák]

Vy jste svým způsobem umělec – vždycky do něčeho šlápnete, a když se snažíte z toho vykličkovat, neomylně šlápnete do dalšího. Jistě, nejoptimálnější je řešit první, druhou a třetí prioritu současně, a vůbec nejideálnější je, když všechny tři priority řeší hlavní protagonista. Ale klidně si dál myslete, že první nemusí být první. Mimochodem, ani s tím vaším výkladem ovšem „není prioritou“ neznamená „je na posledním místě.

Takže pokud jste chtěl tvrdit, že pro ně bezpečnost není na prvním místě, měl jste to tak napsat.

Však jsem to tak také napsal. V tom, že jsem místo „první“ použil cizí slovo znamenající totéž, nebyl žádný záměr, opravdu to neměla být návnada, abyste se měl na čem zase zesměšnit.

[trekker.dk]

Vy jste svým způsobem umělec – vždycky do něčeho šlápnete, a když se snažíte z toho vykličkovat, neomylně šlápnete do dalšího

Je to v principu možné, tohle se mi zatím nestalo, takže si to ale nemůžeme ověřit.

Jistě, nejoptimálnější je řešit první, druhou a třetí prioritu současně, a vůbec nejideálnější je, když všechny tři priority řeší hlavní protagonista.

Dobrá, možná jsem se na vás nevyjádřil dost jasně, tak pro jistotu - když jsem napsal Google a Mozilla, tak jsem měl na mysli tu hromadu lidí, co pro ně pracují. Samozřejmě, každý z těch lidí dokáže v jednu chvíli řešit jenom jednu věc. No ale je jich víc, takže každý může řešit něco jiného, což znamená, že organizace, která je zastřešuje, pracuje na více věcech současně a může tedy mít více priorit. Doufám, že takhle podrobně už to na vás bude dost pochopitelné.

Mimochodem, ani s tím vaším výkladem ovšem „není prioritou“ neznamená „je na posledním místě.

Což jsem ovšem taky netvrdil, ale dobrá, asi se snažíte působit preventivně.

Však jsem to tak také napsal. V tom, že jsem místo „první“ použil cizí slovo znamenající totéž

Víte, když používáte ty cizí termity, měl byste v nich být větší suterén. Když tomu tak není, tak si pak myslíte, že jste něco udělal, i když jste ve skutečnosti udělal něco jiného. Ale tím se nenechte vyvést z míry, určitě se nenajde nikdo, kdo by to u vás považoval za směšné.

[j]

Zeby ... to co mu rekne uzivatel? Jo aha, ono misto stranky plny blbejch kecu zobrazit prostej dotaz, jestli uzivatel tu stranku chce otevrit, a jestli chce ty dotazy zobrazovat i priste ... budem nadale pouzivat nepouzitelny CA ...

Me je treba realne naprosto uprdele, jestli ma abicko https, a jestli ma selfsign nebo jakekoli jinej certifikat. A presne stejne je mi to u rite na 99,9999% webu. Stejne neexistuje zadnej zpusob jak bych overil, jestli je to ten spravnej. Problem je trochu v tom, ze uplne stejne nemuzu nic overit ani v tom 0,0001% pripadu, kdy mi na tom sejde.

[xkucf03]

Takže by nebyl problém, aby se v rámci téhle komunikace prohlížeč dozvěděl i zprávu „jsi v síti, kde nefunguje DNSSEC, ani to nezkoušej“.

A pak se stane co? Uživatel se nedostane na žádný zabezpečený web, protože nelze rozhodnout, zda je certifikát důvěryhodný nebo ne? Nebo naopak budou důvěryhodné všechny? Případně by šlo tunelovat DNS přes HTTPS servery Googlu (prohlížeč by v sobě měl zadrátovanou CA Googlu nebo otisky jeho certifikátů), takže by se z Googlu vlastně stala jediná Globální CA, která by mohla potvrdit nebo zpochybnit libovolný certifikát.

[Filip Jirsák]

I prohlížeč podporující DANE by měl dál pracovat se seznamem důvěryhodných certifikačních autorit, například proto, že dál budou existovat OV a EV certifikáty, nebo proto, že ne každý web hned musí zavést DANE. Takže prohlížeč, který nemůže použít DANE, by dál používal přesně to samé, co používá dnes. Proč by to mělo být nějak jinak?

[xkucf03]

OK, nicméně tohle říkej spíš fanatickým propagátorům DNSSEC/DANE a kydačům hnoje na PKI. Já tohle vlastně říkám od začátku – že DNSSEC může sloužit jako vhodný doplněk a nezávislý kanál pro kontrolu a zvýšení důvěryhodnosti, ale není schopný nahradit systém PKI/CA.

[j]

PKI je zcela nefunkcni, uz desitky let, a zcela nepouzitelny. Chtel bych videt tripismenkovou agenturu, ktera tohle pouziva ... ani jedna jedina.

[Dumb]

Naopak to velmi rádi používají

[xkucf03]

Navíc: co brání, říct provozovatelům TLD domén, aby místo/vedle zavádění DNSSEC zavedli vlastní CA pro danou TLD a vydávali bezplatně certifikáty majitelům domén? Do prohlížečů pak stačí přidat tyto CA a bude to v pohodě fungovat (a naopak tam nemusí být spousta jiných CA – prostě lze vytvořit ekvivalentní situaci k fungujícímu DNSSEC/DANE). Zde je vidět, že není problém až tak v technologii (PKI, CA, DNSSEC, DANE, TOFU…), jako spíš v lidech a v tom, jak mají nakonfigurované systémy a jak ty technologie používají.

[Andrej]

Mně by se víc líbila povinnost mít správně DANE/TLSA jako nutnou podmínku k důvěryhodnosti certifikátu. Spousta úkonů by se tím zjednodušila a navíc by nebylo tak snadné vydávat se za někoho jiného postupem tak dobře známým od dnes již zkrachovalých certifikačních autorit.

[xkucf03]

Podle mého je největší vada systému PKI to, že jeden certifikát může podepsat jen jedna CA. Škoda že to není víc jako u GPG – pavučina důvěry – tím by byl celý systém mnohem flexibilnější a DNSSEC/DANE/TLSA by vlastně nebyly vůbec potřeba – tvůj certifikát/klíč by mohlo podepsat víc CA – např. a) klasická komerční CA b) státem uznávaná CA c) komunitní CA typu LetsEncrypt nebo CACert d) registrátor domény a/nebo správce TLD e) lokální CA platná jen pro danou organizaci.

Většině uživatelů by stačila možnost d), pro vyšší důvěru a nezávislou kontrolu by sis přidal c), banky a jiné kritické služby by přidaly a) s EV, pro komunikaci se státem by sis ten samý klíč nechal podepsat pomocí b). Nebo pokud bys měl třeba firemní server, tak bys na něm měl certifikát podepsaný od e) a mohla by to být jediná CA, kterou mají uživatelé nainstalovanou (chodí-li jen na intranet resp. firemní servery) a zároveň by ten server byl důvěryhodný i pro veřejnost, protože by jeho certifikát podepsaly i jiné CA – některé z možností a) až d).

Výhodou by bylo, že by se vše řešilo stejným způsobem pomocí jedné technologie – nikoli pomocí dvou nesourodých, z nichž jedna funguje jen pro některé TLD a jen některé ISP.

Pokud lze PKI/X.509 něco vyčítat, tak je to tohle omezení.

P.S. „cross-certification“ AFAIK funguje na úrovni CA, ale ne na úrovni certifikátů serverů/uživatelů – nebo jsem to tam aspoň nikdy neviděl – pokud se pletu, tak mne opravte.

[Dumb]

No hezký. A dopadlo by to stejně jako s PGP, nikdo to nepoužívá. Jak by jako měl browser určit, který certifikát je ten správný(TM)? Ten co má podpis od jedné CA, od tří nebo od dvaceti? No tak to zobrazíme uživateli ať si rozhodne sám, že jo? A babička která jde do banky bude luštit kdo všechno jí podepsal certifikát.

[xkucf03]

Dneska máš taky několik úrovní:

• web používá jen nešifrované HTTP
• web používá HTTPS, ale má nedůvěryhodný nebo třeba prošlý certifikát (zde prohlížeče reagují naprosto hystericky, přitom to není o nic horší než první možnost, která projde bez jakéhokoli varování – v lepším případě se prohlížeč jen ozve při pokusu o HTTP POST)
• web má validní DV certifikát
• web má validní OV certifikát
• web má validní EV certifikát

Můj návrh je, že by prohlížeč měl 1) zobrazit několik piktogramů podle toho, kterými testy certifikát prošel:

• na webu jsem už v minulosti byl a certifikát (resp. spíš klíč) se od té doby nezměnil
• certifikát je potvrzený přes DNSSEC
• certifikát je podepsaný CA příslušné TLD
• certifikát je podepsaný komunitní CA (LetsEncrypt, CACert…) nebo lidmi, kterým věřím (web-of-trust – kolegové, přátelé, uznávané osobnosti…)
• certifikát je podepsaný nějakou komerční nebo státní CA + co ta CA potvrzuje (na rozdíl od předchozích možností může potvrdit víc údajů než jen doménové jméno)

2) prohlížeč by měl kontrolovat, zda se certifikát od minule změnil a dávat k tomu uživateli i nějakou nápovědu – např. pokud měl starý certifikát brzo vypršet, je zřejmě v pořádku, že se teď používá jiný certifikát – a pokud ho vydala navíc stejná CA nebo zůstal stejný soukromý klíč, není důvod k obavám. Tzn. to, co dělá/dělal doplněk CertificatePatrol. Při prvním vstupu na daný web by měl uživatel potvrdit, zda mu daná úroveň zabezpečení vyhovuje – a prohlížeč by následně kontroloval, zda nedošlo ke zhoršení stavu a umožnil uživateli snadno zkoumat, jakou úroveň zabezpečení daný server má.

[Filip Jirsák]

Certifikát je od toho certifikát, že se v něm někdo za něco zaručí – právě proto, aby to nemusel zkoumat uživatel, který tomu nerozumí. Možná někoho baví zkoumat, co se na certifikátu změnilo od minule, podobně jako někoho baví sledovat, na kterém vlaku jede jaká mašina nebo třeba sbírat brouky. Ale rozhodně to není něco, k čemu by měl webový prohlížeč nutit uživatele. Certifikát se může změnit třeba při každém navázání spojení, ale pokud bude validní a důvěryhodný, je to v pořádku.

Stejně tak by bylo k ničemu, pokud by zabezpečení záviselo na tom, že bude uživatel kontrolovat nějaký piktogram. V kontrolování věcí jsou lidé hodně špatní – naopak počítače jsou v tom velmi dobré, nic je neunaví. Takže je potřeba, aby HTTPS bylo všude, aby nebylo možné uživatele ošálit tím, že mu něco podstrčím po HTTP a uživatel špatně zareaguje na nějaké varování, kterému nerozumí. A pak je potřeba, aby uživatel snadno prohlížeči řekl, že má hlídat nějaký OV nebo EV certifikát – např. když si uloží adresu elektronického bankovnictví do záložek, prohlížeč zjistí, že je tam EV certifikát, a při dalších návštěvách bude kontrolovat, že je tam stále EV certifikát vydaný na stejné jméno.

[j]

U certifikatu NIKDO ZA NIC NERUCI. To ze jirsak naprosto nechape jak (ne)funguje zabecpeceni naprosto cehokoli na tom nic nezmeni.

Piktogram je minen jako informace o urovni zabezpeceni, coz bezmozek pochopit taky nemuze. Ale muze ji s klidem ignorovat. Jeho bezpecnost pak bude presne stejna jako doted - vsude presne nulova.

[j]

Kdepak, zdaleka nejvetsi problem je v tom, ze ti jakesi CA importuje kdosi do systemu/browseru a vsude mozne ... a kdyz zustanu u browseru, tak tvymu browseru je uplne uprdele, ktera z tech CA podepsala certifikat toho kteryho webu. Takze i kdyby ti banka krasne sdelila, ze jeji web podepisuje verisign, je ti to hovno platny, protoze tvuj browser bude zcela spokojen i s podepisem LE. A to je ten zdaleka nejvetsi pruser vubec.

A pak nasleduje pochopitelne hromada dalsich, copak udela tvub browser kdyz se mu nepovede overit revokace? Spokojene pokracuje ...

[xkucf03]

Takze i kdyby ti banka krasne sdelila, ze jeji web podepisuje verisign, je ti to hovno platny, protoze tvuj browser bude zcela spokojen i s podepisem LE. A to je ten zdaleka nejvetsi pruser vubec.

Viz komentář výše – prohlížeč by měl řešit, zda se situace od minule změnila.

[j]

Mel, ale neresi, zadnej. Je mu to uplne jedno. Stejne jako by ti mel umoznit delegovat pro danej web konkretni CA (trebas), taky neumi. Pokud dneska chces realne resit jakoukoli bezpecnost tak bud musis mit addon (kterej nejspis uz nikde nefunguje), nebo musis smazat vsechny CA a znemoznit aktualizace browseru (z cehoz se prozmenu browser posere na kazdym prvnim webu ... protoze je strasna katastrofa kdyz je tam cert neznamy ca ...) . Pak si totiz muzes na tom webu ulozit konkretni certifikat, a mas jakous takous bezpecnost.

[Filip Jirsák]

Proč by provozovatelé TLD měli řešit nějaké certifikáty? Oni řeší odpovědi na DNS dotazy, a to zabezpečují pomocí DNSSEC. To, že někdo nechce tuto technologii implementovat, přece není problém provozovatelů TLD. Navíc proč zrovna provozovatelé TLD? Co kdyby si třeba UK chtěla zavést vlastní CA pro doménu cuni.cz? Zavádět to místo DNSSEC by bylo už úplně zcestné – jak bych ověřil jakýkoli jiný záznam než A/AAAA?

[xkucf03]

S ověřováním jiných typů záznamů máš pravdu (DNS může fungovat jako distribuovaná databáze, lze přes něj přenášet v podstatě libovolná data a díky DNSSEC je zaručena jejich integrita – byť ne důvěrnost – nicméně je otázka, jestli je vhodné DNS takto používat… ale to je na jinou diskusi).

Nicméně pokud se bavíme o bezpečnosti komunikace na webu případně u e-mailu, tak tam si myslím, že by možná bylo užitečnější, kdyby TLD založily vlastní CA a vydávaly certifikáty. Stejně jako v případě DNSSEC totiž musí spravovat svoje soukromé klíče a musí podepisovat klíče vlastníkům domén, zajišťovat výměnu klíčů atd. Jestli to budou dělat tou nebo onou technologií mi přijde víceméně stejně pracné/náročné. A co by přineslo víc užitku? CA by se daly nasadit rychleji, nebylo by potřeba kvůli nim psát nový software a instalovat ho, nebylo by to závislé na ochotě ISP nebo na tom, zda DNS pakety nezmrší nějaký modem nebo „chytrá“ krabička cestou.

[Dumb]

Jo dostat ty tísíce CA do prohlížečů to by fakt bylo rychlé. Ochota ISP je bezmezná v provnání s ochotou Google, Mozilly a MS přidat důvěryhodnou CA do jejich browserů. A že každá taková CA si pak může vydat certifikát pro libovolnou doménu by byla taky špica. Jo super máme tu pinning! Pro HTTP. A ostatní služby? DANE je ta správná cesta ať už se ti to líbí nebo ne.

[xkucf03]

Jo dostat ty tísíce CA do prohlížečů to by fakt bylo rychlé.

Prohlížečů je jen pár a mechanismy, jak do nich (nebo do OS) dostat nové CA nebo je z nich odstranit jsou již zavedené.

A že každá taková CA si pak může vydat certifikát pro libovolnou doménu by byla taky špica.

Standard X.509 umožňuje dát certifikátům různá omezení – kromě např. omezení jen na podepisování/šifrování lze omezit CA na (sub)domény, kterým smí vydávat certifikáty – takže např. CZ.NIC by směl vydávat certifikáty jen pro .cz domény (kdyby vydal jiné doméně, byl by certifikát automaticky nedůvěryhodný). A aby je vydal jen oprávněným majitelům .cz domén, je už jeho zodpovědnost. U DNSSEC je to úplně stejné – taky máš nějaké klíče pro danou TLD a taky by je příslušný správce TLD mohl zneužít k tomu, aby přes DNSSEC podepsal doménu někomu, kdo není jejím vlastníkem.

Ve skutečnosti už dnes správci TLD (kteří zavedli DNSSEC) vystupují v roli CA –˙jen k tomu používají jinou technologii, ale princip (moc, odpovědnost, procesy…) je stejný, jako kdyby byli klasickou PKI/X.509 CA. Proto jsem tu psal, že by stálo za zamyšlení, zda by nebylo lepší, aby se (vedle nebo místo DNSSEC) používala (i) jiná (možná vhodnější, užitečnější) technologie.

[j]

Funguje to uplne stejne, jako kdyz pouzivas dns server googla nebo kohokoli - klidne svyho ISP. Nezbejva ti, nez tomu verit. Jenze narozdil od stavajiciho stavu, tu neni jeste neomezeny mnoztvi tretich stran (CA) ktery na tebe muzou udelat mitm kdykoli se jim zachce.

[Andrej]

Tohle je obrovská škoda. Než tu autoritu nový čínský majitel zprasil k nepoznání a poslal do háje, aby pak ještě rok předstíral, že dál prodává validace a že to ještě má nějaký smysl, byla to jedna z nejdostupnějších certifikačních autorit, která se dokonale hodila pro amatérské projekty všeho druhu. Byla ve všech vestavěných seznamech v browserech i distribucích. Navíc v době, kdy fungovala pod původními (pravděpodobně izraelskými) vlastníky, měla skvělou reputaci a ustála známé útoky, kvůli kterým několik jiných autorit zkrachovalo.

A teď tam člověk najednou vidí, jak mají na stránce "StartSSL EV" za $199. Hned vedle vyjádření o ukončení činnosti. Pěkná sprosťárna, vzhledem k tomu, že tohle už přes rok nemůže vůbec fungovat v žádném aktuálním browseru, protože těm certifikátům už žádný nevěří, takže v podstatě ještě zkoušejí prodávat vzduchoprázdno.

Po dobách StartSSL se mi bude dost stýskat. Na rozdíl od zoufalého paskvilu typu cacert.org StartSSL prostě fungovala, vydávala certifikáty, byla v distribucích, byla v browserech. Class 1 certifikáty byly zadarmo. Class 2 validace byla za pár šupů a omezená byla jenom časově, nikoliv počtem certifikátů — takže certifikáty pro nové subdomény již ověřených domén, včetně wildcardů, byly prostě hned a bez dalších příplatků. (To třeba Let's Encrypt neumí wildcardy dodnes.) Navíc byly certifikáty platné na 2 roky, takže roční Class 2 validaci stačilo řešit jenom každý druhý rok. Samozřejmě byly dostupné taky osobní certifikáty pro E-mail (o čemž se Let's Encrypt ani nezdá) s potvrzením identity (byť pravda je, že české úřady si s Class 2 validací tak leda vytíraly prdel a prosazovaly místo toho jisté tři ubohé korupční pseudoautority se zakázaným šifrováním, které se nikdy nedostaly ani do důvěryhodných seznamů v browserech).

No, to je asi všechno, co jsem k tomu chtěl dodat. Jedna éra skončila. Snad bude Let's Encrypt do 5 let umět aspoň část toho, co se dalo zařídit u StartSSL.

[xkucf03]

+1, taky mi bude chybět.

Líbil se mi jejich model, kdy platíš za ověření dokladů (tzn. nějakou reálnou práci, kdy ti i volají z Izraele), ale už ne za počet vydaných certifikátů (stačilo, aby ty domény byly psané na tebe).

Navíc byly certifikáty platné na 2 roky, takže roční Class 2 validaci stačilo řešit jenom každý druhý rok.

A když jsi chtěl hodně ušetřit, tak jsi mohl na konci té roční platnosti validace zažádat o nové certifikáty, takže jsi měl za cenu jedné validace certifikáty vlastně na tři roky.

[Dumb]

Já zírám, si s Andrejem podejte ruce jděte jim plakat na hrob.

To že ta autorita je roky úplně na hovno, že to dokonce došlo tak daleko, že ztratila důvěru a musela být přinucena skončit. Tak to pro vás dva nění žádný problém. Hlavně že jste neměli startosti, platili jste málo a měli jste zeleno. Fakt úchylný. To pak opravdu DNSSEC/DANE/DNS_OVER_TLS opravdu nepotřebujete.

[Andrej]

Klasické anonymní kecy.

Tahle autorita byla roky špička v oboru. Pak ji koupil čínský vlastník (za velmi netransparentních okolností), který způsobil, že cca poslední rok a půl byla na hovno.

Ještě něco jsi na tom celém nepochopil, co bych měl znova a polopatě vysvětlit?

[Heron]

Na rozdíl od zoufalého paskvilu typu cacert.org

Tuhle CA považuju za nejlepší, kterou jsem kdy měl. Netuším proč se nedostala do prohlížečů, ale na rozdíl od všech ostatních CA, které v prohlížečích jsou, tak tady proběhlo skutečné ověření face to face, doklady totožnosti apod.

To třeba Let's Encrypt neumí wildcardy dodnes.

Wildcardy považuju za vysoce problematické. Spousta zákazníků nám posílá wildcard certifikát včetně soukromého klíče, abychom na jejich web hostovaný u nás dali https. Horší nakládání s párem klíčů si nelze představit, každý, kdo tohle zachytí (posílají to houfně emailem), tak má k disposici plně validní cert na celou doménu. To potom totálně ztrácí smysl tam nějaký crt vůbec mít.

se zakázaným šifrováním

Což je správně. Existují útoky (alespoň teoretické), které ukazují, že při použití stejného klíče k mnoha různým účelům (a v tomto případě ještě útočník může připravit data, která se následně mají šifrovat) uniká informace o tom klíči a dochází k jeho oslabení.

Každý klíč by se měl tedy používat jen k jednomu účelu, tedy pro podepisování a pro šifrování by měl člověk mít dva klíče.

[Andrej]

K vzájemnému face-to-face ověřování mezi (de facto) laiky v oboru bezpečnosti / kryptografie bych byl skeptický. Já osobně bych nikoho ověřovat nechtěl. Laik těžko pozná falešné doklady od skutečných a u StartSSL byl součástí ověřovacího procesu (kromě dokladů) taky dopis, telefonát nebo obojí. Face-to-face má rozhodně smysl u systémů, kde se používá víc podpisů a vytvářejí se sítě důvěry, protože tam se vzájemně mají ověřovat lidé, kteří se znají a spolupracují spolu dlouhodobě. V případě cacert.org může jednoduše dojít k tomu, že se setkávají a ověřují nějací náhodní neznámí žadatelé certifikátů a takové transakce jsou už z principu zranitelné.

Pokud chce člověk mít funkční name-based virtual hosting, musí mít wildcard certifikáty. To se nedá nic dělat.

Ne, zákaz šifrování není správně. Stát tím vybízí své občany, aby svá ryze soukromá data posílali úřadům nešifrovaně. Podpora něčeho tak absurdního snad ani nemůže být míněná vážně. To i dopisní obálka může být (v jistém slova smyslu) bezpečnější — třeba proto, že na ni neexistují remote útoky.

S těmi klíči mícháš dohromady dvě téměř nesouvisející věci a vzniká z toho pak nesmyslné / neověřitelné tvrzení. Zaprvé, šifruje se symetrickým klíčem, který je dohodnutý prostřednictvím asymetrického klíče. Symetrický klíč je pro každou zprávu jiný a (v podstatě) náhodný. Takže tvůj soukromý (asymetrický) klíč šifruje pouze ten malý kousíček dat (symetrický klíč), nikoliv celou zprávu. Zadruhé, symetrický šifrovací klíč je (s velkou pravděpodobností) pro každou zprávu jedinečný, takže dostat se na základě velkých či opakovaných zpráv přes symetrický klíč zpět až k soukromým asymetrickým klíčům by vyžadovalo hodně velkou revoluci v algebře.

K těm symetrickým klíčům, které opravdu šifrují přenášená data, se dá říct asi tolik, že zašifrovat něco třeba pomocí starých šifer typu 3DES může mít problém s bezpečností po několika přenesených GB (což není běžná velikost jednoho E-mailu, zatím) a v případě AES256 je situace mnohem lepší.

V E-mailovém klientovi si samozřejmě můžeš naklikat, že se pro šifrování (jednorázového symetrického klíče pro šifrování zprávy) a pro podpis (hashe zprávy) (v obou případech jde o kousky dat v podstatě konstantní velikosti, bez ohledu na velikost zprávy; proto to zdůrazňuju) použije jiný pár (asymetrických) klíčů. Otázka však je, proč něco takového vůbec dělat. Nikde to není doporučeno, pokud vím. A i kdyby to doporučeno bylo, úřady by klidně mohly vydávat oddělené certifikáty (jeden vycházející z klíčů pro podpis a jeden vycházející z klíčů pro šifrování), kdyby chtěly.

[Heron]

Laik těžko pozná falešné doklady

To je sice možné, ale i tak toto bylo nejlepší ověření, jakého se mi v celém profesním životě (tisíce certifikátů), dostalo. "Ověření" u ostatních autorit veškeré žádné. Dopis a telefonát považuji za mnohem horší ověření, než byť i laické face to face (nehledě na to, že ten ověřovatel zas nebyl taková nula).

Ještě je docela přijatelné ověření u postsignum, kam člověk přijde na poštu a alespoň ukáže občanku. Při první žádosti.

Pokud chce člověk mít funkční name-based virtual hosting, musí mít wildcard certifikáty. To se nedá nic dělat.

Nevím proč by musel mít. Lze mít buďto hromadu různých crt nebo jeden cert s hromadou jmen. Wildcard není potřeba.

Stát tím vybízí své občany, aby svá ryze soukromá data posílali úřadům nešifrovaně.

To není pravda. Ten email zašifrovat můžeš, ale ne tím kvalifikovaným certem. (Otázkou je, jak si s tím potom poradí na druhé straně.)

Takže tvůj soukromý (asymetrický) klíč šifruje pouze ten malý kousíček dat (symetrický klíč), nikoliv celou zprávu.

To je jasné, ale ten útok měl využít fakt, že podepisování se provádí jedním klíčem z páru, zatímco šifrování druhým klíčem z páru. Pokud tedy útočník může (teoreticky) získat přístup k oběma stranám (tedy podvrhnout to, co se má šifrovat i to, co se má podepsat - což je stejná operace jako šifrování, jen se jí jinak říká), tak získá výstup z operací prováděných jak veřejnou částí tak i soukromou částí a z toho by mohlo jít získat informace o tom páru klíčů.

Obvykle se ty klíče používají jen jednostranně. Co se zašifruje jedním, tak se odšifruje druhým a málokdy se kombinují oba směry. V tomto případě by to nastalo. (Jeden pár klíčů k více účelům.)

Otázka však je, proč něco takového vůbec dělat. Nikde to není doporučeno, pokud vím.

Viz výše. Bavil jsem se o tom kdysi s Vondruškou, v kryptografii je ten problém, že máloco je skutečně dokázané, takže se ani příliš neví, zda z oboustranného použití páru klíčů, něco neuniká. Obvykle se používají asymetricky, jedním se jen šifruje a druhým jen dešifruje. Takže v případě nutnosti podpisu i šifrování je v rámci předběžného opatření mít dobré dva různé páry.

[Kate]

>Dopis a telefonát považuji za mnohem horší ověření, než byť i laické face to face

V tomhle mě nejvíc před lety dostali Thawte, kteří odmítali volat na číslo pevné linky z webu nebo ze zlatých stránek. Našli si nějaký pofidérní telefonní seznam na webu a trvali na jeho použití. Dostat na něj telefonní číslo naštěstí nebyl problém (bohužel ale pro kohokoliv).

[Kate]

Ještě doplním že šlo o prodloužení platnosti, takže za věrohodnost webu v podstatě svým vlastním certifikátem ručili, přeso odmítali brát v potaz uvedené telefonní číslo shodné s číslem na zlatých stránkách…

[Heron]

Asi nejzábavnější telefonát u bezkonkurenčně nejdražšího certu, co jsem kdy řešil: volala mi nějaká nejspíš Indka nebo Pákistánka nebo někde tam prostě. Že prej budeme ověřovat. No, naše angličtiny byly natolik nekompatibilní, že jsem pochopil akorát city, tak jsem řekl Brno. To asi pochopila a cert byl vystaven. Tohle "ověření" mohl provést naprosto kdokoliv a to i za situace, kdy by bylo lépe rozumět. V celém procesu nebylo žádné sdílené tajemství.

Jako třešnička na dortu potom byla obnova po Heartbleedu, kdy nový obnovovaný cert byl vydán komplet bez ověření. Takže ten, kdo by využil situace, se mohl dostat k celkem zajímavým kouskům po celém světě.

[Andrej]

Nevím proč by musel mít. Lze mít buďto hromadu různých crt nebo jeden cert s hromadou jmen. Wildcard není potřeba.

Name-based virtual hosting je hlavně o tom, že vytvořím adresář a mám z toho automaticky subdoménu. Jakmile začnu požadovat znalost všech subdomén předem (certifikát se spoustou jmen) nebo vystavení a správu certifikátu pro každou subdoménu zvlášť (oddělené certifikáty), ztrácí to celé jednoduchost a půvab. Jsem pro ztrátu jednoduchosti ve prospěch bezpečnosti, ale nějak mě nenapadá, jak přesně je ten wildcard nebezpečný.

To není pravda. Ten email zašifrovat můžeš, ale ne tím kvalifikovaným certem. (Otázkou je, jak si s tím potom poradí na druhé straně.)

Ten mail zašifrovat nemůžu, ze dvou důvodů. Zaprvé si s tím na druhé straně zcela jistě neporadí. Zadruhé, na základě kterého veřejného klíče protistrany bych měl ten E-mail zašifrovat? Snad ne na základě toho, k němuž příslušný certifikát (i ten na straně úřadu) šifrování zakazuje? Nejen já, ale i úřad by tedy musel mít ten druhý pár klíčů na šifrování. (Nebo hacknout Thunderbird, aby ta omezení certifikátů nevynucoval.)

Tohle^^^ stát nepodporuje ani náhodou a hlavně (jak už jsem psal) mi uniká užitečnost takové věci.

… získá výstup z operací prováděných jak veřejnou částí tak i soukromou částí a z toho by mohlo jít získat informace o tom páru klíčů.

Existují někde informace o zranitelnosti, která by z tohoto mohla plynout? Neznám totiž E-mailový klient, který by doporučoval oddělené páry klíčů. Thunderbird i KMail je umožňuje, ale doporučení nikde není.

Chápu, že při použití dvou párů klíčů se nikdy nebude nikam posílat výstup vytvořený soukromým šifrovacím klíčem, kterým každá strana pouze dešifruje, a výstup z veřejného podpisového klíče (ze stejného plain textu) taky pořídit nelze, protože se podepisuje pouze soukromým podpisovým klíčem, veřejným se jen ověřuje a plaintextový dokument není k dipsozici…

Takže za platnosti hypotézy o prolomitelnosti klíčů při dostupnosti obou výstupů by to pomohlo.

Celý argument ale přestane fungovat, když uvážíš, co přesně se těmi klíči zpracovává: Nikdy se nepoužije výstup pořízený oběma klíči nad stejným plaintextem. Plaintext, který podepisuješ, je výstup hashovací funkce nad dokumentem (a závisí na dokumentu). Plaintext, který šifruješ, je symetrický klíč (například AES256) a nezávisí na dokumentu; jde (dejme tomu) o náhodné číslo.

Fakt mi nepřipadá, že by dva páry klíčů poskytovaly ochranu navíc.

… máloco je skutečně dokázané …

Máloco je skutečně dokázané o RSA a asymetrických šifrách. Symetrické šifry jsou na tom nesrovnatelně lépe, co se matematického základu týká. Rozhodně to není tak, že by kryptografie stála na vodě.

Neříkám, že mít dva různé páry klíčů je špatně, jenom si myslím, že je to zbytečná komplikace, která nemá dokázaný (aspoň ve formě nějaké velmi obecné nerovnosti) benefit z hlediska bezpečnosti.

[Heron]

Name-based virtual hosting je hlavně o tom

Je hlavně o tom, že nemusím mít pro každý web unikátní kombinaci ip / port, ale že si webserver sám určí hosta dle hlavičky host (což byla vymoženost http verze 1.1) (nebo v případě https potom SNI - TLS). To nemá s wildcardem nebo adresáři nic společného.

Nicméně ani ne-wildcard crt mi v tom nijak nebrání, prostě kromě vytvoření adresáře požádám ještě třeba LE o vytvoření dalšího certu. (Nebo jinou autoritu, na kterou mám api.)

Existují někde informace o zranitelnosti, která by z tohoto mohla plynout?

Nenašel jsem rychle žádný pořádný papír, ale tady je to vysvětleno.

Je otázkou, jak by teda útočník dostal ty zprávy m, m' apod. k/od oběti, každopádně to už je jedno. Principiálně je to prostě špatná technika a klíče by se měly používat jednoúčelově a jednosměrně.

A ano, fakt není potřeba potřetí psát, že jako zprávy do RSA vstupují hashovací hodnoty nebo náhodný tajný klíč pro symetrickou šifru. Jak dobře jsou některé knihovny implementované jsme viděli v minulých letech a rozhodně bych si nevsadil na to, že není možné nějakým útokem na protokol nebo knihovnu to přinutit místo hashe použít rovnou tu původní zprávu - viz nedávná věc s WPA2, kdy se podařilo zařízení ukecat k tomu, aby jako klíč použilo samé nuly.

[Jendа]

Principiálně je to prostě špatná technika a klíče by se měly používat jednoúčelově a jednosměrně.

Na tohle jsou u PGP subkeys, ne? To SMIME nemá a musí se používat úplně separátní klíče?

[Andrej]

Ano, nemá.

Ne, nemusí.

[Andrej]

To nemá s wildcardem nebo adresáři nic společného.

No dobře, zapomněl jsem na důležtý buzzword: dynamický name-based virtual hosting. Ten jsem měl na mysli. Ten má s wildcardem nejen hodně společného, ale dokonce je s různými wildcardy naprosto nedílně spjatý. S adresáři rovněžtak.

S adresáři má tenhle virtual hosting společného opravdu hodně, například že uživatelé webového serveru (ve smyslu UNIXoví uživatelé) si můžou vytvářet libovolné subdomény pouhým vytvořením adresáře. Prostě si někam zkopírují nějaký CMS nebo jiný web a mají okamžitě novou subdoménu online.

Aby vytvoření toho adresáře bylo opravdu jediný nutný krok, o to se postarají wildcardy. První wildcard bude na straně DNS, což vyřeší resolving nových subdomén. Webový server pak bude mít name-based virtual hosting nastavený tak, aby generoval jména adresářů s weby podle subdomén, bez nutnosti měnit nastavení po přidání adresáře. Certifikát pro HTTPS pak samozřejmě musí mít taky wildcard doménu. V opačném případě by každá změna subdomény znamenala vygenerování nového certifikátu, ať už společného nebo odděleného pro novou subdoménu.

(Ano, každý majitel subdomény by mohl používat API od nějaké autority a nechat si vygenerovat certifikát, ale tím se dostávám zpátky k původnímu zadání: Chci vytvořit subdoménu s HTTPS jen na základě adresáře, ničeho jiného.)

[Andrej]

Nenašel jsem rychle žádný pořádný papír, ale tady je to vysvětleno.

Mně připadá, že to tam není nijak vysvětleno. Praktický rozměr celé věci (že podpis nemá být nikdo schopen napodobit a má platit dlouho, zatímco požadavky na šifrování jsou jiné, například ve firemním prostředí) je tam vysvětlený celkem dobře. Ale pokud jde o teorii kolem bezpečnosti, to je spíš styl kde nic tu nic. Komentář, který to tam shrnuje asi nejlépe, zní "Some sources/links would be great here".

Jediná odpověď, která se snaží ilustrovat konkrétní problém specifický pouze pro RSA na nějakém konkrétním výpočtu, má (což už jsem tu zmiňoval i já) zcela nerealistické předpoklady o tom, jaký typ dat se těmi klíči šifruje a (navíc ještě) ke kterým kryptografickým datům má útočník přístup.

Úvahy typu "let's assume a poorly designed encryption system that uses..." jsou sice zajímavé, ale nějaký S/MIME v Thunderbirdu nebo KMailu asi nebude ten idealizovaný blbě navržený systém, na který by příklad pasoval.

Ještě mě zaujal tenhle názor:

If all you have is hand-waving arguments for and against the security of a practice, one need to err on the side of caution.

Když je něco nedokázané, jak si někdo může být jistý ohledně onoho err on the side of caution? Z čeho plyne jistota, kterým směrem se mýlí? Co když je to ve skutečnosti tak, že použití téhož páru klíčů pro šifrování i podpis je bezpečnější než použití odděleného páru klíčů (třeba kvůli záhadné dosud neobjevené oblasti algebry)?

Možná je to spíš klasický bias typu "zvyk je železná košile". Pokud někdo léta udržoval a používal oddělené páry klíčů a věřil, že to má smysl pro bezpečnost, bude mít (celkem pochopitelně) tendenci takovou praxi hájit.

I já jsem měl pár let dva různé páry klíčů.

[Heron]

Jediná odpověď, která se snaží ilustrovat konkrétní problém specifický pouze pro RSA na nějakém konkrétním výpočtu, má (což už jsem tu zmiňoval i já) zcela nerealistické předpoklady o tom, jaký typ dat se těmi klíči šifruje a (navíc ještě) ke kterým kryptografickým datům má útočník přístup.

Tak vidím, že poslední odstavec jsem psal zcela zbytečně.

No takže, když bych to shrnul. Víme, že použití obou klíčů z RSA páru je problematické a útočník může teoreticky získat kompletní pár. To ale nevadí, protože věříme, že je to implementováno správně. A všechno to, co se událo s různými implementacemi za posledních pár let pro jistotu ignorujeme.

Úvahy typu "let's assume a poorly designed encryption system that uses..." jsou sice zajímavé, ale nějaký S/MIME v Thunderbirdu nebo KMailu asi nebude ten idealizovaný blbě navržený systém, na který by příklad pasoval.

Ano, protože se nikdy nic podobného nestalo. Btw, nejsi to náhodou ty, kdo často upozorňuje na případ narušení generátoru náhodných čísel v openssl v debianu? Nebo se bugy Thunderbirdu nebo KMailu zázračně vyhýbají?

že použití téhož páru klíčů pro šifrování i podpis je bezpečnější než použití odděleného páru klíčů (třeba kvůli záhadné dosud neobjevené oblasti algebry)?

No, to je docela dobře možné, ale zatímco o té záhadné oblasti algebry, který by umožňovala únik dat z použití dvou zcela nezávislých párů klíču nikdo neví, tak o úniku dat z použití téhož páru víme již dnes.

[Andrej]

Víme, že použití obou klíčů z RSA páru je problematické a útočník může teoreticky získat kompletní pár.

Ne, nic takového nevíme. Něco takového si někteří představujeme, možná se to některým zdá být v souladu s intuicí, ale nevíme to.

Priority. Ty je potřeba si ujasnit, jak už tu někdo zmiňoval. E-mailová komunikace s úřady je nešifrovaná a to je zoufale špatně. To je ten hlavní a urgentní problém. Řešit v tomhle kontextu a v téhle situaci, jestli někdo používá dva oddělené páry klíčů — byť k tomu není žádný kloudný důvod — mi připadá nesmyslné.

A všechno to, co se událo s různými implementacemi za posledních pár let pro jistotu ignorujeme.

Co tak strašně zásadního se událo? A co přesně ignorujeme? To by asi chtělo drobné upřesnění. Jinými slovy, citation needed.

Btw, nejsi to náhodou ty, kdo často upozorňuje na případ narušení generátoru náhodných čísel v openssl v debianu? Nebo se bugy Thunderbirdu nebo KMailu zázračně vyhýbají?

Proč by se někomu bugy zázračně vyhýbaly? Bugy se opravují. Nikoliv zázračně, ale díky komunitě open-source vývojářů.

Každopádně hodně odbíháš od tématu. Proti bugu s 32768 možnými klíči tě dva oddělené páry klíčů nijak neochrání. Prostě budou oba triviálně prolomitelné, stejně jako jeden. Narušení náhodného generátoru v Debianu s tímhle souvisí opravdu hodně okrajově.

[Heron]

E-mailová komunikace s úřady je nešifrovaná a to je zoufale špatně.

No diskuse začala ještě něčím jiným a to "a prosazovaly místo toho jisté tři ubohé korupční pseudoautority se zakázaným šifrováním".

Já jsem zcela pro šifrovanou komunikaci s úřady. Jen bych to rád udělal správně a vyhnul se známým potencionálním problémům. Zkrátka není problém použít dva klíče. Jeden kvalifikovaný podpisový a druhý šifrovací, který si tam uživatel dá při první registraci. Náročnost ze strany úřadu je v obou případech stejná.

Co tak strašně zásadního se událo?

Třeba to, že se implementace WPA2 nechá ukecat k tomu, aby použila jako klíč samé nuly. Opravdu budeme spoléhat na to, že neexistuje metoda, jak ukecat implementaci podpisu tak, aby místo hashe použila předem podstrčenou zprávu (a tím by se dal realizovat ten útok na rsa)? Takhle se bezpečnost opravdu nedělá.

Každopádně hodně odbíháš od tématu.

Neodbíhám. Celé vlákno je o tom, že lze provést útok na rsa, pokud se podaří dostat předem připravenou zprávu ke zpracování oběma klíči z páru. Z čehož plyne, že by se tímto způsobem neměl ten pár používat. A proto je vhodné zakázat kvalifikovaným certifikátem pro elektronický podpis také šifrovat. To je celé.

[Andrej]

Takže se ukazuje, že podepsat a zároveň zašifrovat zprávu jedním klíčem je mnohem bezpečnější než například naschvál zvolit pouze šifrování.

Zda je systém se dvěma klíči bezpečnější, to se stále neví, ale ve světle těchto nedávných zjištění mi to nepřipadá pravděpodobné.

Pokud nemáme exaktní důkaz o té či oné vlastnosti (nebo konkrétně slabosti) šifrování a pokud jenom spekulujeme, co by se mohlo stát, kdyby útočník znal (nebo mohl ovlivnit) část plaintextu, je to celé jedna velká neznámá.

[xkucf03]

v kryptografii je ten problém, že máloco je skutečně dokázané, takže se ani příliš neví, zda z oboustranného použití páru klíčů, něco neuniká.

A má smysl tyhle hypotetické možnosti řešit v situaci, kdy většina komunikace není chráněná vůbec nijak a většina lidí nepoužívá ani šifrování na úrovni, jaká tu byla před deseti+ lety? Přijde mi to jako se hádat, jestli máš na vchodových dveřích ty nelepší zámky a kameru, která vidí i v noci… a přitom máš vzadu dveře na dvůr, která se nikdy nezamykají.

Až bude nejslabším článkem řetězu, to, zda jsi k šifrování použil stejný pár klíčů jako k podepisování, tak bude mít smysl to řešit. Ale dneska to nejslabší článek (pro drtivou většinu lidí a jejich interakcí) opravdu není.

[Heron]

A má smysl tyhle hypotetické možnosti řešit

No vzhledem k tomu, kolik nepravděpodobných věcí se okolo SSL/TLS stalo v posledních letech, tak to jistě smysl řešit má. Obecně si myslím, že má smysl dělat věci správně, pokud vím, jaká je ta správná možnost. (Nebo, když alespoň vím, která možnost je horší, tak bych se jí měl vyhnout.)

Přijde mi to jako se hádat, jestli máš na vchodových dveřích ty nelepší zámky a kameru, která vidí i v noci… a přitom máš vzadu dveře na dvůr, která se nikdy nezamykají.

Tak na druhou stranu si ty vchodové dveře můžeš škrtnout z todo seznamu a už se tím nemusíš dál zabývat. Potom se můžeš věnovat tomu dvoru. A už na to máš vzor.