Vlákno názorů k článku Protokol HTTP/2 byl dokončen. Prohlížeče už ho podporují od Joe - Šifrování je hezké, to ano, jen by to...
-
Joe (neregistrovaný)
Šifrování je hezké, to ano, jen by to chtělo doladit. Proč? Ceny za certifikáty nejsou zrovna lidové a když máte jako já 10 webů, tak je celkem sranda řešit certifikáty. Mimochodem, copak se stane, když prošvihnete termín platnosti certifikátu? No, to bude nefunkčních webů, že. No a pak případné prodeje domén se tím také dost zkomplikují. Tohle se bude muset nějak inteligentně vyřešit.
PS: software není možné nikdy na 100% zabezpečit. Proto počítejte s tím, že do týdne tu bude 10 způsobů, jak se s vynuceným šifrováním vypořádat, třeba pomocí podrvžených certifikačních autorit apod. A v nejhorším si zaskočí do Lenova, ti budou vědět jak na to. Konec konců stačí do počítače dostat jeden certifikát a pak komunikaci přesměrovat na proxy, která vše bude dekriptovat a znovu skládat dohromady. Když o tom tak přemýšlím, tak jediné co se vynuceným šifrováním vyřeší, je odposlech plain textu amatéry, kteří dnes jen vystčí wifi anténu z okna a sosají co kolem létá. Nic víc se šifrováním nevyřeší a to je dost málo.
-
muf (neregistrovaný)
Konečně někdo, kdo o tom přemýšlí a není fanatický aktivista. Díky.
____
Vynucené šifrování všeho na Webu skutečně téměř nic neřeší. Služby, které z podstaty šifrované být musí, jsou šifrované už dnes. Pokud ne, je to jen hloupost jejich provozovatele, proti které není imunní nic.
HTTP/2 může být zajímavá možnost i když jeho binární návrh je ošklivý...ale proč jej povinně šifrovat, opravdu nechápu. Google zřejmě potřebuje vyvolat pocit bezpečí u těch, ze kterých saje data - proto ta podivná implementace v prohlížečích...(Mozilla je dnes v jeho vleku). -
Filip JirsákStříbrný podporovatelInteligentní řešení už existuje, jmenuje se DANE. Stačí, aby ho prohlížeče implementovaly.
-
Ondřej CaletkaZlatý podporovatelTeoreticky máš pravdu. Prakticky má správce root zone jen velmi omezené možnosti jak, útočit na DNSSEC koncové entity. Když přidá útočný záznam, DNS servery je budou ignorovat jako ne-glue záznam uvnitř delegace. I kdyby upravil všech 13 sad DNS serverů, aby poskytovaly i takové záznamy, úspěšnost útoku bude beztak velmi malá, protože rekurzory budou mít správně nacachovanou delegaci pro jiné domény ze stejné TLD.
Jedinou možností tak v podstatě je předelegovat celou TLD a pak ještě čekat na douhatánské TTL. Na to by kterýkoli postižený správce TLD jistě velmi rychle přišel a rozpoutal skandál, pokud by nebyl nějakým vnějším vlivem umlčen.
-
Ondřej CaletkaZlatý podporovatel
Pravda, pokud má útočník pod palcem veškerý tvůj síťový provoz, a zároveň pouze tvůj, pak ano.
Spíš jsem to myslel tak, že pokud se někdo, kdo drží privátní klíč kořenové zóny, bude chtít globálně zbavit/přesměrovat/pozměnit obsah domény nsalitomerice.cz, protokol DNS jí to neumožní.
-
Lol Phirae (neregistrovaný)
Já myslím, že všiml... nebo by si toho všimli uživatelé. Zcela nedávný příklad:
https://forum.pfsense.org/index.php?topic=87491.0
http://www.unbound.net/pipermail/unbound-users/2015-February/003774.html -
Jenda (neregistrovaný)
Asi zpackaná implementace, ne? (tl;dr; "web pages load blank") Představ si, že se ti prostě v případě kompromitace root zone změnil klíč pro zónu .cz, v případě kompromitace CZ.NIC se změnil jenom klíč pro zónu tastránka.cz. Jediné jak by sis toho podle mě mohl všimnout je mít pro DNS nějaký network consensus jako dělá Perspectives pro HTTPS.
-
Ondřej CaletkaZlatý podporovatel
Můžeš to prosím nějak shrnout? Přečetl jsem čtyři stránky z toho fóra i oznámení o vydání a stále netuším jak to spolu souvisí.
Zatím jsem jen pochopil, že někteří uživatelé pfSense mají jakýsi problém s podvrženým DNS provozem s nadřazených rekurzivních serverů.
-
Ondřej CaletkaZlatý podporovatel
Tak už jsem se konečně dočetl; tedy pro odstatní TL;DR:
Majitelé pfSense si nainstalovali Unbound a z nepochopitelného důvodu u něj vypnuli volbu harden-glue. Následně se strašně divili, když jim někdo v glue záznamech otrávil cache. V unboundu žádná vada nebyla, jen byl v nejnovějším RC vylepšen, aby i v případě, že někdo vypne harden-glue, nebyla jeho cache tak snadno otrávená.
-
- Již zmíněný projekt Let's Encrypt to dokonce chce zautomatizovat (a CA by pak v podstatě prodávaly akorát EV + certifikáty státní správě :))
- StartCom (a i když Vás donutí udělat Class 2 validaci, protože máte na stránce slovo Donate, tak je to jenom cca $60 jednou rocne, coz je vcelku snesitelne - a jeste na konci te periody si muzete vystavit certifikaty na dalsi dva roky. Tj. platba je nutna cca jednou za tri roky...)
- Některé CA Vám dají cert zdarma, pokud jste aktivní Open Source projekt
-
anonymovič (neregistrovaný)
Systém CA je možná prohnilý (netvrdil bych, že je k ničemu), ale vymyslel někdo něco lepšího? DANE nenahradí certifikáty podepsané důvěryhodnými CA. Pro vydání OV e EV certifikátů stejně budou CA potřeba.
>Vlezes na zcela bezpecnej web, kterej ma seflsigned a browser se z toho muze posrat.
A kde berete tu jistotu, že je to právě ten zcela bezpečný web, na který se chcete dostat? A kde berete jistotu, že vás nikdo neodposlouchává.
Pokud tomu certifikátu věříte, tak si ho nainstalujte a nemusíte takové problémy řešit.
Chování browseru je v tomto případě úplně správné.>Vlezes na web banky, mas tam uplne jinej cert nez vcera, a browseru to vubec nevadi.
A na tom je špatného co? Třeba provozovatel stránky certifikát revokoval (ať už z důvodu vyzrazení klíče nebo třeba kvůli přechodu k jiné CA). V takovém případě by browser plašil zcela zbytečně. -
anonymovič (neregistrovaný)
>Měl by se tedy podle tebe browser chovat stejně i v případě, že vlezeš na HTTP stránku?
Na to není jednoduchá odpověď. U HTTP neprobíhá žádná kontrola identity serveru, takže z tohoto hlediska není před čím varovat. To, že nemám jistotu, zda jsem na pravém webu vyplývá už z toho, že komunikuji HTTP protokolem.
Bohužel, většina uživatelů to vůbec neřeší, takže je vhodné na to upozornit.Nakonec Chrome (a později určitě i další) bude přesně takové varování zobrazovat. Mají to v plánu na rok 2016.
Nešifrovaný protokol bez ověření identity prostě nemá na internetu co dělat (s jednou jedinou výjimkou).
Ale to není jenom věcí HTTP. Daleko horší situace je FTP. -
Jenda (neregistrovaný)
> U HTTP neprobíhá žádná kontrola identity serveru, takže z tohoto hlediska není před čím varovat. To, že nemám jistotu, zda jsem na pravém webu vyplývá už z toho, že komunikuji HTTP protokolem.
U HTTPS se self signed certifikátem neprobíhá žádná kontrola identity serveru, takže z tohoto hlediska není před čím varovat. To, že nemám jistotu, zda jsem na pravém webu vyplývá už z toho, že komunikuji HTTPS protokolem bez důvěryhodného certifikátu.
> Nakonec Chrome (a později určitě i další) bude přesně takové varování zobrazovat.
Jako že se ti fakt zobrazí stránka, kde se musí klikat na Advanced a Proceed? U každé HTTP stránky? Nebojí se, že se na ně uživatelé vykašlou?
-
anonymovič (neregistrovaný)
>U HTTPS se self signed certifikátem neprobíhá žádná kontrola identity serveru, takže z tohoto hlediska není před čím varovat.
Nikoli, drahý Watsone, kontrola identity probíhá. Jinak by to popřelo principy TLS.
>To, že nemám jistotu, zda jsem na pravém webu vyplývá už z toho, že komunikuji HTTPS protokolem bez důvěryhodného certifikátu.
A co je podle vás důvěryhodný certifikát? Ten který vydala nějaká CA?
Já bych to tak moc nebral. Pro někoho nejsou CA dostatečně důvěryhodné a tak si udělá vlastní CA, které věří on sám.
Důvěra je velmi subjektivní. Jako jediné kritérium důvěryhodnosti nelze brát fakt, zda je certifikát předinstalován v OS nebo v úložišti prohlížeče.Mám-li úzkou skupinu uživatelů, například firmu a pro interní potřeby si zavedu web s vlastním certifikátem, tak pro mě a ostatní zaměstnance bude více důvěryhodný, než kdyby ho vydala důvěryhodná CA. Nad certifikátem mám plnou kontrolu.
>Jako že se ti fakt zobrazí stránka, kde se musí klikat na Advanced a Proceed? U každé HTTP stránky?
Ano, tak néjak to bude.
> Nebojí se, že se na ně uživatelé vykašlou?
To se musíte zeptat jinde. -
Jenda (neregistrovaný)
> Nikoli, drahý Watsone, kontrola identity probíhá.
Ano, proběhne kontrola, že server, který ti poslal ten certifikát, je server, který ti poslal ten certifikát. Velmi užitečné.
> A co je podle vás důvěryhodný certifikát? Ten který vydala nějaká CA?
To nedokážu obecně zhodnotit. Ale o tom diskuze nebyla.
-
anonymovič (neregistrovaný)
>Ano, proběhne kontrola, že server, který ti poslal ten certifikát, je server, který ti poslal ten certifikát. Velmi užitečné.
Kontrolovat se dá vůči certifikátu, který je nainstalovaný.
Pořád mluvíte jen o selfsigned, což jsou obecně všechny kořenové certifikáty (ty které vydala CA i ty, které si sám vygenerujete).
Já bych to zůžil na certifikáty, které nejsou vydané CA se všeobecnou důvěrou.Kromě toho, použít selfsigned CA rovnou pro webserver, to je tak trochu čůňátko-řešení.
-
>Vlezes na web banky, mas tam uplne jinej cert nez vcera, a browseru to vubec nevadi.
A na tom je špatného co? Třeba provozovatel stránky certifikát revokoval (ať už z důvodu vyzrazení klíče nebo třeba kvůli přechodu k jiné CA). V takovém případě by browser plašil zcela zbytečně.Třeba má banka v obchodních podmínkách fingerprint certifikátu nebo jméno CA a vaši povinnost toto ověřovat při každém použití internetového bankovnictví.
-
j (neregistrovaný)
"A na tom je špatného co? Třeba provozovatel stránky certifikát revokoval (ať už z důvodu vyzrazení klíče nebo třeba kvůli přechodu k jiné CA). V takovém případě by browser plašil zcela zbytečně."
Ne, zbytecne by rozhodne neplasil, dal by uzivateli moznost overit, zda ta zmena je vporadku. Treba tak, ze zvedne telefon a do banky zavola.
Ona totiz banka CA meni pomerne vyjimecne, a korenovy certifikaty dost casto plati desitky let, takze to, ze by certifikat byl ze dne na den podepsanej uplne necim jinym ne pomerne velmi nenormalni stav.
=> browser by si mel pri prvni navsteve (volitelne s dotazem) zapsat "tenhle strom pro tenhle web" a rvat, pokud se to zmeni. A ne vopruzovat na kazdym webu s ssl, kterej pouziva strom provozovatele, kterymu se nechce calovat za milost distribuce v 158 browserech.
-
anonymovič (neregistrovaný)
Takové CA existují, ale většinou je to dost omezující. Některé nejsou někde důvěryhodné.
StartSSL je sice důvěryhodná téměř všude, ale certifikát bych od nich nechtěl. Nechávat si generovat svůj privátní klíč u nich je poněkud nebezpečné. Moźnost vygenerovat si klíč u sebe a jim poslat žádost k podepsání u free certifikátů není, pokud vím.To už je lepší si za cca 300 koupit certifikát od nějaké pořádné CA.
Až se rozšíří DANE, tak DV certifikáty úplně ztratí smysl.
-
anonymovič (neregistrovaný)
SW generátor nikdy nedá tak kvalitní klíč, protože negeneruje zcela náhodná čísla.
SW: http://scruss.com/wordpress/wp-content/uploads/2013/06/randu17_rgb.png
HW: http://scruss.com/wordpress/wp-content/uploads/2013/06/random20130606210630.png -
anonymovič (neregistrovaný)
Nechápu, co tím chtěl básník říci. CA také používají si generují klíče na HSM a tam je také mají uložené.
Vy si vygenerujete klíč, jím podepíšete certifikát, ten odešlete CA, která ho podepíše ze svého HSM a pošle zpět.Pro uživatele je HSM možnost, pro CA nezbytnost. Kromě generování dostatečně náhodných čísel ještě slouží HSM k bezpečnému uložení klíče.
-
Ja (neregistrovaný)
Zpět k: http://www.root.cz/clanky/protokol-http-2-byl-dokoncen-prohlizece-uz-ho-podporuji/nazory/534347/
Přečíst bod b), pak přečíst vaši odpověď na bod b)
-
JSH (neregistrovaný)
Tak bez mlžení :
- OS napsal, že je Startcomu možné poslat k podepsání _jakýkoliv_ certifikát pomocí CSR.
- Ty jsi odepsal, že to není dost dobré, protože lepší je kdyby byl vygenerovaný hardwarově.
- "Já" odepsal, že je úplně jedno jakým způsobem je ten certifikát vygenerovaný a dal jako příklad kostky.
- Ty pořád píšeš o tom, že softwarově vygenerované certifikáty nejsou to pravé.
- "Já" tě považuje za idiota, nediv se.Pokud to pořád není jasné, tak hardwarově vygenerované certifikáty jsou podmnožina jakýchkoliv certifikátů.
-
anonymovič (neregistrovaný)
Tak teď jste tomu dal na prdel, kolego. Na specializovaném zařízení se negeneruje certifikát, ale privátní klíč, kterým se pak certifikát podepisuje. Z hlediska procesu vydávání certifikátu je jednu, jakým způsobem byl klíč vygenerovaný. Z hlediska síly klíče zde ale je diametrální rozdíl mezi kvalitou klíče vygenerovaného nějakou aplikací a kvalitou klíče vygenerovaném na speciálním hardwaru.
Takže není jedno, na čem se bude klíč generovat.>Pokud to pořád není jasné, tak hardwarově vygenerované certifikáty jsou podmnožina jakýchkoliv certifikátů.
A to, že je něco podmnožinou něčeho vypovídá o vlastnostech, kvalitě a nekvalitě?
-
Ad b) Díky.
Ad a) libnss umí PKCS#11 (Firefox, Chrome), Windows asi taky nějak (IE). Ve Firefoxu je to pod "Security Devices", ale nikdy jsem si s tím nehrál, takže jen předpokládám, že Vám rozhodně nic nebrání přidat si do systému poskytovatele PKCS#11, zintegrovat jej s prohlížečem. A pak už je to jen podmnožina b).
