Cetrifikaty treti strany automaticky funkcni ve vsech prohlizecich?(musim duverovat treti strane)
Nebo self signed certifikacni autorita od ktere mam klice jen ja? (kazdy musi poprve zkontrolovat fingerprint)
Exustuje jina treti cesta, ktera mi eliminuje v zavorkach uvedene nevyhody pro dane reseni?
Dik za kazdy konstruktivni tip.
Konstruktivní názor tady na rootu? :) (Mimochodem, pokud se podepíšete jako eurokomunista, tak co přesně čekáte za reakce...?)
Myslím, že mícháte v případě PKIX jabka z hruškama (naprosto typicky, tak si z toho nic nemusítě dělat). PKIX (a X509) má dvě hlavní funkce - jedna přináší informaci o tom, s kým na druhé straně mluvím - dnešní (komerční) řečí se jedná o EV certifikáty, druhá pouze dovoluje navázat šifrovaný přenos mezi koncovými body, a to jsme na úrovni DV certifikátů, kde si můžeme nalhávat, co chceme, ale jsou dnes na úrovni toho, co dělá Let's Encrypt.
Cílem Let's Encrypt tedy není přinést vyšší úroveň důvěryhodnosti mezi subjekty, které spolu komunikují, ale zvýšit úroveň šifrované komunikace mezi klientskými stranami (prohlížeč, ale i MTA) a servery (HTTP, SMTP, ...).
Hádám, že se (v celku dohledné době) dostaneme do stavu, kdy browser místo zámečku u DV certifikátů nebude zobrazovat nic, a v případě nešifrovaného HTTP spojení bude důrazně uživatele upozorňovat na fakt, že po síti komunikuje nešifrovaně.
Ale on přišel, jmenuje se to TLSA – viz článek Připíchněte si SSL certifikát k doméně. Bohužel tvůrci prohlížečů to zatím odmítají implementovat, protože by nejdřív museli implementovat DNSSEC validující resolver.
Bohužel DANE (TLSA záznamy) téměř nikdo používat nebude, protože prakticky nikdo (kromě 4 zemí - .cz, .se, .br a snad .nl) DNSSEC téměř nepoužívá. Žádné velké služby nepoužívají DNSSEC.
Tu část DNSSEC, která ověřuje vlastnictví domény, zvládá TLS (HTTPS) samo.
Certificate Transparency se taky značně opozdil, i když ho Google zdá se bude pořád prosazovat. Od roku 2011 kdy začal vznikat, se kvůli událostem jako Snowden dost změnil threat model.
Certifikační autority ale ověřují DV certifikáty také podle DNS. Takže pokud někde chybí DNSSEC, může útočník získat falešný certifikát - akorát musí zaútočit nejprve na DNS klienta CA a teprve až opak na DNS klienta své oběti. Akorát ta CA snad bude používat víc obranných mechanismů.
Tu část DNSSEC, která ověřuje vlastnictví domény, zvládá TLS (HTTPS) samo.
Buď nerozumím tomu, co jste chtěl říci, nebo to není pravda. HTTPS nedokáže samo ověřit vlastnictví domény, potřebuje k tomu právě certifikát, který právě to vlastnictví domény potvrzuje.
> DNSSEC se používá (téměř) všude, kde o to má někdo zájem.
Mám pocit, že tohle tvrzení hodně závisí od toho, jak moc překroutíme "kde o to má někdo zájem". Google například jeden čas zájem měl, zájem aby jeho služby DNSSEC záznamy měly je, jeho resolvery DNSSEC podporují, ale sám DNSSEC záznamy již nemá.
V .cz jediný důvod velkého počtu domén s DNSSEC je, že DNSSEC záznamy generují registrátoři automaticky masově. Ne kvůli tomu, že by o to byl zájem.
Spíš mně překvapuje, že se používání TLSA chytilo trochu u SMTP, tam bych to zrovna vůbec nečekal.
Dik za rozvedeni tematu.
Fakticky mi jde o to, ze provozuji z nekolika domovu propojenou VPN (OpenVPN) a zatim si generuji certifikaty pres vlastni cert. autoritu.
Myslim ze pokud udrzim tu svou autoritu v bezpeci na diskete a zaroven kazde zarizeni korektne overi pri prvnim spojeni certifikat/fingerprint serveru, tak mohu takovou VPN povazovat za bezpecnou (optikou tohoto parametru komunikace).
Jde mi o to se vyhnout nutnosti prvniho korektniho overeni serveru.
Uvazuji, ze kdyz bych zvolil CA treti strany, tak diky tomu ze ji nemam pod kontrolou, lze uvazovat o situaci kdy nekdo podvrhne certifikat a mohu se stat obeti at uz odposlechu nebo podvrzeni identity jedne stran.
Ted mne napada, ze to by se dalo eliminovat prave tim TLSA nebo jak se to jmenuje. Chapu to ze TLSA explicitne jmenuje otisk/certifikat, ktery je dannemu symbolickemu jmenu prirazen.
Záleží na tom, jak ověřujete na straně serveru certifikáty, které jsou autorizované připojit se. V OpenVPN můžete i uvádět přesně fingerprinty použitých klientský certifikátů. Obecně bych řekl, že až na "disketu" je lepší pro OpenVPN mít vlastní CA, protože v tomto případě přesně provádíte ověření identity, a je jednodušší říct, že se mohou připojit všichni klienti, kteří mají nerevokovaný certifikát Vaši CA. Ale úplně to nesouvisí s Let's Encrypt...
Ucel tohodle je proste jednoduse a pouze v tom, aby browser drzel hubu a neprudil BFU s pindama o neduveryhodnych certifikatech.
Ostatne MTA taky mailuje pres ssl a je mu naprosto uprdele ze se pouzivaj klido 10 let expirovany certifikaty ... proste proto, ze na to sral pes. Porat lepsi sifrovani expirovany nez zadny.
Jen dmentni tvurci prohlizecu to porad nechtej pochopit. Proto tvrdej svym oveckam, ze je lepsi http nez https.
Šifrování bez ověření protistrany je jako by tam žádné šifrování nebylo. Minimálně je třeba ověřit, že stále ještě komunikujete se stejnou stranu, že se třeba během komunikace nezměnil certifikát. A to je minimum, samozřejmě je nutné třeba vědět, že pepa.example.com je ve vašem případě totéž co skutečný pepa example provozuje.
Boze ... zas ty zvasty ... sifrovani nema s overovanim protistrany ZHOLA NIC SPOLECNYHO.
Kdyz prijimam mail, tak pokud nemam system vylozene nastavenej tak, ze overuje proti mnou zadanym podpisum kazdyho jednoho odesilatele a nic jinyho neprijme, tak vzdy prijima zcela anonymni mail. A kupodivu, nejakym zazrakem, umi ten mail prijmout na sifrovanym kanale ... neuveritelne co?
Web je PRESNE totez. Kdyz lezu na root, tak je rootu uprele co sem zac, a me je stejne tak upr.. co je zac ten server. Ale co mi vadit muze, ze si nekdo cestou cte, co ctu a pisu.
http taky kupodivu neresi, ze se behem browsani po jednom webu klidanko i nekolikrat meni IPcko ... divny co?
A jeste divnejsi je, ze nekteri ani netusi, ze prakticky vsechny browsery se zvladaji vuci serveru prokazat klicem ... proc to ty servery nevyzadujou a staci jim, kdyz klient pouziva https? Zeby proto, ze jim je JEDNO kdo je na druhy strane?
Kdyz lezu na root, tak … me je stejne tak upr.. co je zac ten server. Ale co mi vadit muze, ze si nekdo cestou cte, co ctu a pisu.
A přesně tady si protiřečíte. Je vám tedy jedno, co je zač server, a že to klidně může být útočník, který si někde cestou čte, co čtete a píšete? Nebo vám to může vadit?
> Šifrování bez ověření protistrany je jako by tam žádné šifrování nebylo.
To není pravda. Pokud jsi internet-scale adversary a provoz je nešifrovaný, stačí poslouchat a nikdo o tom nemusí vědět. Pokud je tam šifrování bez ověření protistrany, musíš dělat MITM na všechna spojení a tím strašně roste riziko, že si toho někdo všimne (admin vyměňující certifikát a kontrolující jestli se změna projevila atd.).
musíš dělat MITM na všechna spojení
Proč na všechna? Úplně stačí na ta, která mne zajímají - třeba od jednoho uživatele. Ostatně v některých sítích se prý MitM na HTTPS provoz dělá (pod vlajkou zvýšení bezpečnosti), aby bylo možné kontrolovat i obsah HTTPS spojení. A to je MitM zaměřený samozřejmě jen na uživatele dané sítě, a někdy prý není aplikován na všechny servery, ale třeba vybrané banky jsou z MitM vyňaty.
Tak zase ta rizika nepřehánějme, pokud mám kvalitní MITM implementaci, což se tak nějak předpokládá, když mám koupený intermediate certifikát, tak budu generovat stínové certifikáty tak, aby se v maximální možné míře shodovaly s těmi původními, takže si samozřejmě včas všimnu, že se ten zdrojový změnil.
99-procentní admin skončí u toho, že se mu změnilo datum ukončení platnosti, protože certifikát obnovuje den před skončením platnosti, případně pár dní poté, protože byla párty apod. A.k.a. me. Minimum lidí si ověří řetězec vydavatelů a ještě menší minimum i otisk. Šacoval bych to spíš na nějaký addon v prohlížeči, který bude mít nainstalovaný nějaký aktivní blbec. Blbec ve smyslu "den blbec" pro ISP.