Vlákno názorů k článku Let's Encrypt zablokoval nebezpečnou validaci pomocí self-signed certifikátu od Kouli - Já to ověření tls-sni-01 používám na všech serverech,...
-
Kouli (neregistrovaný)
Já to ověření
tls-sni-01používám na všech serverech, kde mám certifikát LE: je to - ehm byl to - jediný způsob, jak získat/obnovit certifikát přímo z toho serveru, aniž by tam bylo potřeba mít spuštěno cokoliv na portu 80 (na některých místech - podnikový server s přísným správcem firewallu - ten port 80 ani není dostupný).Většina serverů s LE certifikátem běží i na portu 80 (s přesměrováním na 443) - těm stačí
http-01. Ale když už mám na serveru potřebu použít šifrování, tak se mi ho nechce oslabovat přesměrováním z portu 80 (byť jen při prvním přístupu v kombinaci s HSTS): uživatelé si prostě zvykli zadat to jedno písmenko v URL navíc... -
Filip JirsákStříbrný podporovatelPokud by měla být metoda
tls-sni-01trvale zablokována (podle mne měla, blacklist webhosterů nic neřeší), dávalo by smysl vytvořit metodu ověřeníhttps-01, která bud fungovat stejně, jakohttp-01, ale přes HTTPS (s libovolným certifikátem). I s ohledem na to, že je snad cílem postupně se nešifrovaného HTTP úplně zbavit – bylo by absurdní, kdyby podpora nešifrovaného HTTP musel na serverech zůstat kvůli vystavování HTTPS certifikátů… -
Ondřej CaletkaZlatý podporovatelPokud dobře vzpomínám, tak tohle se kdysi v IETF řešilo a řešení s ověřováním přímo po HTTPS (bez ohledu na certifikát) se ukázalo jako zranitelné, počkejte si, kvůli sdíleným hostingům ;)
Problém je zde v tom, že existuje spousta hostingů, které na jedné IP adrese hostují různé množiny HTTP a HTTPS serverů. Příklad: porovnejte http://sut.sh.cvut.cz/ a https://sut.sh.cvut.cz/ (je třeba odkliknout neplatný certifikát)
Takže uživatel ovládající výchozího virtuálního https hosta by dostal ověřovací požadavky pro všechny http hostingy, které nemají https zavedeno. Čili je to obdoba aktuální zranitelnosti. Proto je při
http-01nutné projít přes port 80.Ale určitě by bylo fajn mít možnost ověřovat pomocí web serveru bez nutnosti provozovat zastaralé HTTP. Snad někdo vymyslí dostatečně bezpečné řešení.
-
Filip JirsákStříbrný podporovatel
Přesněji ten důvod spočívá v tom, že na spoustě webů je HTTPS zprovozněno „omylem“ a vede na nějaký náhodný virtualhost. Jenže ten samý problém může nastat i s HTTP, a dá se očekávat, že s prosazováním HTTPS se ten poměr bude postupně otáčet – že bude ubývat těch serverů, kde je zapomenuté HTTPS, a bude přibývat těch, kde je zapomenuté HTTP.
Upřímně řečeno, každá metoda jiná než DNS bude vždy mít větší míru rizika, protože se tam přidává další prvek, který může mít z rozumných důvodů v moci někdo jiný, než vlastník domény. Asi by bylo rozumné, aby se každá metoda ověřování musela explicitně zapnout v DNS – tak, jako je možné pomocíCAAzáznamů určit povolené certifikační autority. Ten záznam by se dal do DNS jednorázově, a rotace klíčů už se pak dá dělat normálně přeshttp-01,tls-sni-02nebo hypotetickéhttps-01– pokud by byly v DNS povolené. -
Upřímně řečeno, každá metoda jiná než DNS bude vždy mít větší míru rizika, protože se tam přidává další prvek, který může mít z rozumných důvodů v moci někdo jiný, než vlastník domény.
DNS ve skutečnost mívá v ruce také někdo jiný. Navíc je to umocněné tím, že v praxi ještě najdete laiky, kteří si svůj web spravují sami (instalace redakčního systému, správa obsahu), ale DNS už je nad jejich znalosti. Takže přístupy ke správě DNS se šíří možná ještě rychleji.
Jakmile se začne používat automatizace mezi web serverem a DNS pro vložení ověřovacího záznamu, vzniknou další možnosti kompromitace.
Používání HTTPS přešlo z roviny zejména ověření poskytovatele vydavatelem certifkátu, do prostého šifrovacího mechanismu. Z jednoho pohledu se jedná o povýšení stavu (šifrování dostupné všem), z druhého pohledu došlo ke snížení standardu (nevím s kým ve skutečnosti komunikuji).
Mně víc chybí ta druhá funkce, i když vnímám argumenty o tom, jak je nutné šifrovat za všech okolností.
-
Certifikáty, které ověřují "s kým komunikují" přece stále existují a používají se.
Pochopitelně ano. Ale před léty bylo pravidlem, že certifikát byl vystavený jen osobě (fyzické či právnické), jejíž totožnost byla ověřena. Pak se začaly vystavovat DV certifikáty a pomalu to upadalo. Dnes už certifikát neznamená víc, než že data od Vás na druhý konec jdou šifrovaně. Ale jestli je druhý konec opravdu tím zamýšleným druhým koncem, to už nevíte. V praxi: ztratíte přístupy ke správě DNS (běžný spotřebitel, u nějakého registrátora); útočník získá DNS, přesměruje si A záznamy k sobě a nechá vystavit certifikát.
Když bude šikovný, provede to v noci, a po snížení TTL, takže ani nevíte, že certifikát na Vaši doménu někdo má. Když nebude potřebovat svoji činnost utajit, ale půjde jen pro "velkou ránu", může "zabezpečený" web provozovat Vaším jménem.
Nemusíme pak snad už ani rozebírat, že registrátoři Vám odešlou postup k obnově zapomenutého hesla e-mailem, který jde nešifrovaně a ještě se může válet po cestě ve frontách.
Tedy, to co říkám je, že rizika se přesunula jen do jiné oblasti, a že nejtenčí článek řetězu je někde jinde. Osobně hodnotím tyto "nové zranitelnosti" jako ještě zákeřnější, než když někdo tu a tam po cestě zamění obsah - to lze vystopovat v reálném čase. Napadení administrace DNS a vystavení DV certifikátu zjistíte až ex post.
-
L. (neregistrovaný)
Koukám, že chápaní psaného textu není vaší silnou stránkou. Takže ještě jednou a podrobněji: Certifikáty, které ověřují nejen vlastnictví domény ale i jejího vlastníka, stále existují a používají se. Když jdu třeba na https://www.servis24.cz, tak hned vedle doménového okna (v Chrome) vidím "Česká spořitelna, a.s. [CZ]", tedy vím, že komunikuji nejen šifrovaně, ale i s Českou spořitelnou. Kapišto?
-
Lol Phirae (neregistrovaný)
Soudruhům z Číny a další hromadě agentů s teplou vodou defaultně důvěřuje tvůj operační systém a/nebo prohlížeč. Certifikát NIC neověřuje, to jen ty nesmyslně věříš, že někdo někde něco ověřuje předtím, než ten certifikát vydá, zatímco ve skutečnosti toho, kdo to vydává, zajímá akorát tak to, jak si co nejrychleji s co nejmenšími náklady namastit kapsu.
-
j (neregistrovaný)
"Certifikáty, které ověřují "s kým komunikují" přece stále existují a používají se."
Existuji .. .ale nefunguji, protoze nikdy nefungovaly. Co ti rekne browser na to, kdyz ti osobne predam selfsign cert? Bude mit kecu az na pudu ... OK, pridas si ho ... a co ti browser rekne, kdyz na tom webu znicehoz nic bude cert trebas od LE? Vubec nic, bude drzet hubu, pricemz by mel rvat jako protrzenej.
Tzn chova se PRESNE opacne nez by mel, rve tam, kde zadny riziko nehrozi (selfsign cert sifruje stejne dobre jako kterejkoli jinej), ale v okamziku kdy budes chtit vyuzit tu dalsi moznost = overeni identity protistrany, naprosto selhava.
ČLÁNKY DO MAILU