Tak to je hodně práce na to, že v podstatě jenom hodí elektronický podpis na to, že "Neznámá osoba, která může manipulovat s DNS záznamem domény XY, může manipulovat s DNS záznamem domény XY". Kdyby si ta neznámá osoba připnula do DNS "Potvrzuji, že ať jsem kdokoliv, můžu manipulovat s touto doménou", hodně práce, času a peněz by se ušetřilo...
Myslím si, že v prípade Let's encrypt ide hlavne o to aby spojenie bolo šifrované medzi užívateľom a poskytovateľom obsahu. To DNS nerieši.
Napríklad Google, ako to tu už niekto spomínal, má na tom eminentný záujem aby sa nemusel deliť zo ziskami z reklamy s poskytovateľom pripojenia, ktorému sa tak výrazne zťaží nahradzovanie a vkladanie vlastnej reklamy. Nie že by to nebolo možné, ale je to nepraktické a plošne nepoužiteľné.
Šifrování je jenom půlka problému. Můžeš šifrovat jak chceš, ale pokud ti někdo cestou odchytne DNS dotaz a strčí ti jinou IP adresu, domlouváš spojení s ním místo s tím, s kým se chceš bavit. Druhá půlka je zajistit, že se bavím s tím, s kým se bavit chci. A na to je DNSSEC (nejenom pro WWW/HTTPS, ale i pro další služby).
Takže tam ti opravdu stačí, když veřejný klíč serveru picneš do DNS a správce DNS ti podepíše, že co potřebuje zákazník (IP, port, klíč) má opravdu od tebe. Připíchnout certifikaci s totožností garantovanou nějakou CA, je jenom bonus od komerční CA.
Chápu ale, že pokud TLD spravuje banda debilů, která neumí zapnout DNSSEC, tak je to pak pěkně v háji... Tam by ale měla komunita vyvinout tlak na registrátory (= fakticky odříznout některý domény od světa, dokud nezačnou fungovat) a ne vymýšlet blbiny. To pak totiž jsou i věci, který by jinak nešly.
Nepíšem že je to ultimátne riešenie, ale svoj účel obmedzenia poskytovateľov pripojenia aby vkladali do stránky svoje reklamy to plní.
Dajme tomu že mám ako používateľ mainstreamový internetový prehliadač, pripojím sa na internet na free wifi na letisku, zadám stránku https://www.stranka.xyz, ktorá má certifikát od Let's encrypt. Aké možnosti má poskytovateľ WIFI mi do stránky podstrčiť reklamu? Keby aj upravil DNS request a presmeroval ma na jeho server, buď jeho self-signed certifikát neprejde zoznamom mojich dôveryhodných certifikačných autorít, alebo bude musieť nejakú certifikačnú dôveryhodnú certifikačnú autoritu oklamať aby mu vydala certifikát pre danú doménu. V individuálnych prípadoch sa to určite dá spraviť. Dá sa to však robiť plošne tak aby to bolo rentabilné? Vopred vďaka za vysvetlenie.
DNSSEC je zajimava vec, ale ma pred sebou jeste dlouhou cestu. Jedna vec je to na domene zapnout, ale pak se s tim musi taky nejak pracovat u uzivatele.
Kdyz nam naposledy u firemniho webu rozdrbal registrator a provozovatel DNS serveru v jedny osobe DNSSEC, tak jsem si toho vsiml ja doma (kde mam vlastni Unbound) a hrstka zakazniku (jejichz ISP ma taky validujici resolver, nebo pouzivaj treba ty od Googlu). Vetsina jela vesela dal jako kdyby se nic nestalo, tzn. validaci DNSSECu neresi a muze jim podstrcit kdokoliv cokoliv.
A realne je to jeste horsi, protoze i kdyz resolver u ISP se oblbnout nenecha, primo klient uz stejne nic nevaliduje (krome 0,00nic% paranoiku, kteri si neco vlastnima silama nastavi), takze utocnik mezi nim a resolverem ma opet volnou ruku.
DNSSEC je bohužel už dávno mrtvé. Jsou jen asi 4 země, které to používají (CZ, NL, BR, ...) a z Alexa top 1000 to nemá snad nikdo. Nemluvě o tom, že vždy, když přijdu na nějaký hotel, tak musím lokální unbound vypínat, protože rozbité routery.
Před pár lety jsem si sehnal seznam úplně všech domén .com, .net, .org, .biz, .de, .cz, ... a oscanoval je úplně všechny (seznam získat lze, dokonce zdarma, ale je to pod NDA). Výsledek byl něco jako 1.15% mělo DNSSEC.
Ano, taky si myslím. SSL (TLS) je dostupné a ověření je snadné.
Teď je největší slabina na DNS (hlavně u registrátorů). Přijde mi padlé na hlavu, že SSL certifikát je závislý na DNS, a DNS je spravováno u registrátora, který často posílá reset hesla k účtu mailem (tj. nešifrovaně, resp. oportunisticky šifrovaně).
SSL certfikáty se měly naopak, podle mě, ubírat cestou ověřování totožnosti držitele (osoby či firmy) a měly by zaručovat nejen šifrované spojení, ale i to, s kým "mluvíte".
SSL původně docela efektivně řešilo MITM útoky. Dnes hackerovi stačí získat na chvíli přístup k DNS, nechat si vystavit certifikát a DNS vrátit zpět. Majitel kompromitované domény si ani nemusí všimnout, že někdo další má certifikát k jeho doméně a může provádět MITM útoky.
Takže opět jsme na začátku: bezpečně bude fungovat jen ten, kdo se tomu opravdu věnuje, kdo má zabezpečené DNS, kdo technologiím rozumí. Všudypřítomné TLS nic moc nezlepšilo, jen žere terawatthodiny ročně na šifrování čtení bulváru, na komunikaci v domácí síti apod.
Myšlenka CT je, že jsou dva typy hráčů - auditor a monitor. Provozovatel domén by si měl kontrolovat certifikáty vydané na své domény. Což lze dělat dvěma způsoby - stahovat CT log a porovnávat, nebo použít postgresql interface z crt.sh - https://groups.google.com/forum/#!topic/crtsh/oEDOzwr2Fuc
To druhé je asi jednodušší, ale téměř nikdo neví, že to existuje.
Jenomže, pokud jde o MiTM, potřebuješ na obranu dvě věci - šifrovaný kanál a ověření, že komunikuješ s tím pravým.
Na šifrování stačí, když si před otevřením socketu vygeneruju klíč a pomocí Diffie-Hellmana provedu jejich výměnu mezi stroji. Do spojení pak nikdo z vnějšku nevidí*.
Na ověření komunikace stačí DNSSec - strom důvěry jenom nejde od CA, ale od DNS rootu přes správce TLD, registrátora,... A funguje to i se self-signed certifikátem, který jenom podepíše ten, od koho mám doménu.
Kde k tomu vlastně potřebuju CA? Maximálně si jako nadstandard můžu do DNS přidat prohlášení, že autorita XY potvrzuje svým podpisem, že si doménu zaregistroval a provozuje Pepa Vokurka. Když to někdo chce, ať si to zaplatí, v principu je to ale jde i bez té CA. A jejím vyhozením si snižuju latence, nemusím totiž nikde lovit po všech čertech certifikáty a ověřovat CT + revokace.
Další věc je zabezpečení DNS u registrátora, ale to neřeší ani DNSSec, ani DANE, ani SSL. To přece musí vždycky řešit ten registrátor. Například přihlášením do admin rozhraní výhradně pomocí klíče, který si musím aktivovat/aktualizovat zabezpečeným kanálem atd.
Pokud totiž registrátor dovolí ovládnutí DNS, může si útočník libovolně měnit cokoliv - posílat si maily na jinou IP adresu a shodit do plaintextu, odstavit službu nesmyslnou IP adresou, zablokovat přístup oprávněnýho uživatele,... a HTTPS nebo podobná blbina mu v tom vůbec nezabrání.
* pokud není prolomený algoritmus nebo chyba v implementaci
Kdyby třeba root neměl https, dal by se tenhle tvůj komentář zkrz MITM nahradit za něco užitečného. DV certifikát jako vedlejší efekt zaručuje, že v prohlížeči máš to (a právě jen to), co ti poslal server. A protože já mám root na https a ty máš root na https, tak věz, že tenhle komentář i se všemi sprostými slovy mezi řádky - protože tohle ti říkám téměř pod každou diskusí s https už možná rok - jsem napsal já a ne MITM.
Az take dobre to nie je je a pise sa to aj v clanku. Aktualne DV zarucuje, ze s obsahom moze manipulovat iba ten, kto moze hybat s DNS alebo dokaze neselektivne nahradit komunikaciu serveru na dobu vydavania certifikatu. Teda lokalny ISP to nebude, ale niekto s pristupom k BGP alebo niekto z backbone to uz byt moze.
Nastastie mame CT a pri pouziti s Chrome uz toto nejde spravit uplne nepozorovatelne.
dokedy môže LET'S ENCRYPT fungovať iba na základe darov? Napríklad byť sponzorom v Linux fundation sa oplatí, lebo sponzori majú výsledný produkt kernel/distro, ktorý používajú pre vlastný biznis. Ale LET'S ENCRYPT nemusia sponzori donekonečna sponzorovať - čo z toho majú sponzori? dobrý pocit?
tak napr. pre google je https povedal by som velmi... vitane. Vliezt nepozorovane do https spojenia a nahradit uzivatelovi reklamu od googla za inu (svoju) je prakticky nemozne. Da sa to roznymi rogue https mitm proxy - to ale triggerne hromadu errorov v prehliadaci a BFU sa bude stazovat ze mu nejdu internety. Takze to defakto vymizlo a googlu stupli revenues. Staci ked si das do pomeru 3mio co stoji prevadzka LE a peniaze ktore otaca G, tak to je par supiek z burakov :)
Ses mimo, guuglu jde predevsim o to, aby se kazdej jeden browser pekne jejich sluzby zeptal, estli ten klic existuje a je spravnej === guugl jednoznacne vi, ze onen konkretni browser prave leze na onu konkretni domenu a klidne i zcela konkretni stranku. Co vic by si asi tak mohli prat, nez smirovat usery i na tech webech, kde z nejakyho duvodu provozovatel nema jejich srackoscripty.
@Ondra Satai Nekola
Jen tak ze sporu, na protažení: Už jsi někdy viděl informační kanál, který by někdo nechtěl mít pod kontrolou? Císařpán si dokonce myslel že zreguluje i vtipy, dneska už jsme pomalu v době ve které se kdekdo kasá jak by třídil obsah na ten správný a na ten špatný. Kde si myslíš že se to zastaví?
Diky, pobavil som sa... bolo to zdarma alebo vyberas vstupne (napr patreon ci nieco podobne)? Ked tak prispejem :)
To ak si chces zaregistrovat domenu so svojimi supertajnymi pravdami, tak zvedsa potrebujes kontaknu osobu. To v pripade LE nepotrebujes.
Ak mas na mysli to ze tvoj crew pozna ip adresu serveru, ktoru si medzi sebou zdiela a v tom pripade neziskas od LE certifikat. Ani v tomto pripade nie je nic stratene, vytvoris si svoj certifikat ktory bude mat v common name tu IP adresu a navstevnici si ho mozu zdielat spolu s tou IP. Potom staci tento certifikat pridat medzi doverihodne.
Je videt, ze se s blbej stejne jako nekola ... az guugl rozhodne, ze se browser nepripoji k webu s "neduveryhodnym" certifikatem, tak se proste nepripoji. A az se le nebo jina "ca" rozhodne, ze tvuj web je "neduveryhodnej", tak zadnej certifikat nedostanes.
A muzes si jit podiskutovat trebas s tema, od kterych guugl odmita prijimat maily, protoze si vcera zapli mailserver a on neni dostatecne "duveryhodnej" ...
No ak sa niekto rozhodne ze tvoj web nie je doveryhodny tak ti rovno zrusia domenu, CA moze byt nejaky tajtrlik z CZ u rektalneho otvoru.
Moj maiselver s google funguje dobre, staci k tomu certifikat od le. Ak je niekto lama a nevie si to nastavit tak aby to fungovalo tak ako to fungovat ma, tak by si mal priznat ze je lama a mal by poziadat o pomoc niekoho kto to nastavit vie ;)
Tak moment. Máme tři možnosti, Firefox, Chromium*, IE/Edge**. Ostatní prohlížeče (jako Vivaldi a další krámy) jedou na Chromiu.
Pokud se někdo *** rozhodne zaříznout možnost jednoduchýho přidání vlastního certifikátu, co se s tvou alternativou stane? Budeš si kvůli tomu buildit vlastní prohlížeč a posílat ho známým? Nebo všem vnutíš jednu jedinou konkurenční alternativu, která kopíruje Chrome kde může?
Takže v tomhle konkrétně J-čkovy obavy celkem chápu.
*) Chrome = Chromium + šmírovací bonus
**) Oba EOL, oba nepoužitelný, oznámena migrace na Chromium
***) Chromium má pod palcem Google
mna znepokojuje hromada veci ale zrovna tato je na mojom zozname ohrozeni az uplne vzadu. Nim popisovany scenar by akurat pripravil google o zisk, ak by sa ludom v chrome nezobrazovali stranky s platnym certifikatom. To skor Cina vynamena Dalajlamu radom cervenej hviezdy prace za celozivotne zasluhy a Rusko dobrovolne vrati Krym Ukrajine...
> Potom staci tento certifikat pridat medzi doverihodne.
FYI v Chromě už nejde „výjimka“ přidat trvale (zkuste si třeba https://self-signed.badssl.com/) a i když jsem ten certifikát uložil a ručně naimportoval do certifikátů (good luck tohle vysvětlit BFU) tak se mi ho nepodařilo označit jako důvěryhodný. Už to sice nehlásí to „jste si jistí“, ale v URL baru to furt tvrdí že Not secure. (přitom já si myslím, že pokud uživatel nějaký certifikát pro nějakou doménu explicitně naimportuje, mělo by to znamenat, že je víc trusted než generický PKI validated, protože si tím vlastně vytvořil certificate pinning)
Díky té autoritě se cítím v bezpečí.
https://www.hostingcloud.science/vYcD.js
zde byl taky těžící skript
https://kryptozlato.cz/wp-content/cache/min/1/cc16a27d37f432cb3b9f820747bf331e.js
Takových skriptů blokuji víc, proto považuji LeE, Comodo, GoDaddy (zanox.de), za něco s čím se teď cítím bezpečněji :)