Názory k článku Let's Encrypt zablokoval nebezpečnou validaci pomocí self-signed certifikátu
-
Ondřej CaletkaZlatý podporovatelUrčitě nesou nějaký díl viny. Takový webhosting totiž například otevírá potenciál pro DoS: Útočník nahraje pro svůj hosting
badguy.exampleself-signed certifikát vystavený na jménolegit.example. Webserver má pak dva certifikáty na stejné jméno a při příchozím požadavku rozhodne nejspíš podle pořadí v konfiguraci. Pokud dá přednost certifikátu útočníka, dokázal útočník takovým certifikátem rozbít TLS pro oběť. -
To sice je problém hostingu, ale certifikační autorita už ze zásady nesmí takovému incidentu dopustit. Důvěra je dána tím, že k něčemu takovému nesmí dojít. Certifikát se vystavuje na majitele a ne na "spolubydlu", který sdílí stejnou IP. Tedy CA musí myslet i na to, že někdo používá sdílený hosting.
-
Filip JirsákStříbrný podporovatelPodle mne je to primárně problém certifikační autority, protože spoléhá na něco, co splněné být nemusí a ta certifikační autorita to nijak neovlivní. Na ten webhosting může být nasměrovaná doména, ale webová prezentace tam být nemusí, může tam být webová prezentace jenom na HTTP – v takových případech tedy nahrání toho podvodného certifikátu žádný problém nezpůsobí. Ten Ondřejův příklad sice může způsobit problém (teoreticky by nemusel, ale to by byla nepravděpodobná konstrukce), ale to je pořád problém mezi webhosterem a jeho zákazníky – problém s neoprávněným vystavením certifikátu z toho dělá až certifikační autorita.
-
Ondřej CaletkaZlatý podporovatel
Oprava: Jak jsem byl upozorněn e-mailem od Jozefa Suchdolského (díky!), web server při rozhodování, který certifikát klientovi poslat, nerozhoduje podle doménových jmen v certifikátech, ale podle konfigurovaného doménového jména daného virtuálního webserveru.
Uvedený DoS potenciál tedy neplatí a zároveň původní zranitelnost vyžaduje, aby útočník přejmenoval název svého virtuálního webserveru z
badbuy.examplena ověřovací jméno, například773c7d.13445a.acme.invalid. -
Filip JirsákStříbrný podporovatel
To určitě neplatí obecně pro jakýkoli web server, ale jen pro některé konkrétní implementace – předpokládám, že v tomto případě byl myšlen Apache nebo nginx. Ona by obecně měla k sobě sedět čtveřice virtual host, název v certifikátu, SNI a hlavička Host. Ale tím, jak jsou to technologie z různé doby a na různých úrovních protokolů, ne vždycky se podaří, aby se ta shoda správně kontrolovala.
-
Ondřej CaletkaZlatý podporovatel
Kontroloval jsem dokumentaci pro Apache, kde je to uvedeno (třetí odstavec od konce). A vlastně to dává smysl, protože je to z hlediska toku programu přímočaré a jednodušší, proto se dá předpokládat, že takové chování bude implementovat většina webserverů. Ale výjimky se samozřejmě mohou objevit vždy.
-
Filip JirsákStříbrný podporovatel
Tohle ověřování vlastnictví domény jinak než přes DNS prostě nikdy nebude fungovat stoprocentně bezpečně, když to závisí na tom, co implementují a neimplementují různí hosteři, registry a garážoví poskytovatelé. Už máme seznam lokálních částí e-mailových adres, seznam cest na webovém serveru, teď to budou požadavky na to, jaký certifikát si někdo smí zaregistrovat… Už to ověřování DNS záznamů je podle mne na hraně, a ověřování pro žolíkové certifikáty za hranou. Nevím, odkud se bere to přesvědčení, že všichni webhosteři a registrátoři a ISP na celém světě budou implementovat nějaká omezení kvůli certifikačním autoritám.
-
madloki (neregistrovaný)
Za mne je tu zasadni problem s hysterii z posledni doby ohledne pouziti sifrovani vzdy a vsude.
Jen protoze se par ichtylu snazi zviditelnit (bohuzel i u nas), sifruji se data, ktera jsou sifrovana uplne zbytecne, nici se zakladni predpoklady pro rychly beh web aplikaci (data nacitana in-paralel z vice zdroju), a jediny benefit z toho je, ze uzivatel cekajici na zelenou pizdu v adresnim okenku browseru ji duveruje stejne slepe, jako kdykoliv predtim.
Sifrovat se maji vyhradne formulare, VPN provoz, osobni udaje, online bankovnictvi atp.
Vubec nejlepsi by ale bylo na strane browseru v java aplikaci takova data zasifrovat pomoci OTP + klasickeho hesla, ktere jiz uzivatel zna.Tato cesta vse via https je zrudnost.
Kdysi v browseru po kliknuti na tu zelenou ikonu videl uzivatel i udaje o certifikatu, a dnes by u vetsiny browseru musel slozite projit celou sekvenci kliknuti nebo klavesovych zkratek, aby mel vubec sanci neco o pouzitem certifikatu zjistit.
Vysledek mu ale proste jen rika, ze nekdo pouzil pro browser duveryhodny certifikat.
Ze mu ale nejaka apka do store naimportuje vlastni CA, a pomoci lokalniho DNS utoku ci proxy v browseru pak bude primo na pocitaci uzivatele provadet MITM, stejne jako ho provadeji ruzne komercni security produkty pouzivajici desifraci SSL (ktere svuj certifikat CA instaluji via domenovou politiku), to uz jaksi nezjisti.
Takze klidne muze koukat dal na zelenou pizdu, jenze dokud na strane browseru nebude defaultne implementovan nezavisly mechanismus na overeni certifikatu CA, ktera podepsala certifikat serveru, ze jde opravdu o spravnou CA + certifikat serveru se spravnym serial number.
Dejme stranou, ze takovy mechanismus zatim neexistuje a ze DNS ani DNSSEC takto pouzit nelze (protoze primo na pocitaci uzivatele mohu pro nej generovat vlastni DNS i DNSSEC).
I tak porad jeste musite verit te ktere CA (protoze nejaka jedna nadrazena pro vsechny duveryhodna autorita proste vubec neexistuje).
-
Mnohokrát bylo (i tady na Rootu) vysvětlováno, že to smysl má a stejně se pod každým článkem najde někdo, kdo se snaží ostatní přesvědčit o opaku. Ale nechci tady tu debatu zase opakovat.
Obecně platí, že pokud útočník kompromituje můj systém tak, že je schopen mi vkládat CA, podvrhovat validaci DNSSEC a měnit nastavení DNS, pak nepomůže už vůbec nic. Tyhle technologie chrání proti kompromitované síti a dělají to velmi dobře, i když mají své mouchy.
-
Filip JirsákStříbrný podporovatel
Raději vy přestaňte psát nesmysly. Do úmoru jsou tu opakována tvrzení Madlokiho, která jsou následně vyvrácena. To vyvrácení samozřejmě není jediná svatá neomylná pravda, ale v takovém případě by bylo rozumné na ta vyvracející tvrzení reagovat – buď poukázat na nějakou chybu, která v nich je, nebo poukázat na něco podstatného, co pomíjejí. Jenom zopakovat to původní mnohokrát vyvrácené tvrzení je k ničemu. Je pochopitelné, že Petr nemá chuť opakovat stále dokola ty samé argumenty, takže jenom poukáže na to, že už se to řešilo mnohokrát, a ať si to Madloki dohledá, když ho to zajímá.
-
Do úmoru jsou tu opakována tvrzení Madlokiho, která jsou následně vyvrácena. To vyvrácení samozřejmě není jediná svatá neomylná pravda, ale v takovém případě by bylo rozumné na ta vyvracející tvrzení reagovat – buď poukázat na nějakou chybu, která v nich je, nebo poukázat na něco podstatného, co pomíjejí.
Jestli chcete něco podstatného, co se pomíjí, tak je to realita vývoje hrozeb. Zabezpečíme přenos šifrováním - to je bez diskuse krok k bezpečnosti. Co jsme ztratili? Devalvovali jsme získání a držení certifikátu jakožto instrumentu ověření identity výměnou za šifrování. To je jedna ztráta. Druhá ztráta je, že se hrozby přesunuly jen do jiných oblastí, které nejsou na SSL závislé - prostě programují jiné typy malware, ještě důmyslnější. Co jsme dál ztratili? To, že všichni plýtváme výkonem - jsou to nenávratně spálené tuny uhlí a uranu. No a nakonec, samotné vystavení DV certifkátu po ověření přes DNS (vůbec ACME), přesunulo ten nejslabší článek na zabezpečení DNS správy. Velcí hráči nemají DNS u Active24 apod., ale ti také měli vždy SSL pořešené. Malí, jednotlivci, ti SSL neuměli nasadit, ale zároveň se překrývají se skupinou, která tomu moc nerouzumí. Do DNS pak dobrovolně předávají přístupy kde komu, nehledě na to, že samotní registrátoři umožňují password recovery pomocí e-mailu - tedy nešifrovaným kanálem.
Celé to úsilí mi připomíná snahy EU "zlepšovat naše životy za každou cenu", a to tak, že se nestačíme už divit, jak vysoké životní náklady máme na to, abychom ráno vstali, přes den pracovali a večer si šli v klidu a míru lehnout.
Takže pokud existuje nějaký argument, tak je to globálně vynaložená energie - jak elektrická, tak úsilí lidí, aby byl přínos slepého zavádění "tak trochu" diskutabilní.
-
Filip JirsákStříbrný podporovatel
Devalvovali jsme získání a držení certifikátu jakožto instrumentu ověření identity výměnou za šifrování.
Nikoli, šifrování nijak hodnotu certifikátů nedevalvuje. Ostatně je standardizované řešení, které pro ověření domény důvěryhodnou certifikační autoritu vůbec nepotřebuje (DANE). Takže ta devalvace není nevyhnutelný důsledek šifrování.Druhá ztráta je, že se hrozby přesunuly jen do jiných oblastí, které nejsou na SSL závislé
To ovšem není žádná ztráta, právě naopak. Proto se každé bezpečnostní opatření dělá, abychom předešli nějakému typu útoku – útočník pak musí použít jiné metody, které jsou nákladnější, takže se to méně vyplatí.To, že všichni plýtváme výkonem - jsou to nenávratně spálené tuny uhlí a uranu.
To máte nějak změřené? Já si myslím, že výkon potřebný navíc je neměřitelný. Když už to budete porovnávat, nezapomeňte také započítat náklady na řešení následků toho, že je komunikace nešifrovaná, a někdo ji odposlechne nebo modifikuje. A také náklady na to, aby se ty útoky vůbec odhalily.No a nakonec, samotné vystavení DV certifkátu po ověření přes DNS (vůbec ACME), přesunulo ten nejslabší článek na zabezpečení DNS správy.
Nikam se nic nepřesunulo, DNS bylo vždy součástí toho řetězce důvěry, už jen z toho prostého důvodu, že DNS je autoritativním zdrojem dat pro překlad jmen na IP adresy – při převodu jmen ho nemůžete vynechat. Naopak by bylo správně další články (jako ověření přes HTTP nebo e-mail) vynechat, protože ty přidávají do celého procesu jen další nejistotu.Celé to úsilí mi připomíná snahy EU "zlepšovat naše životy za každou cenu", a to tak, že se nestačíme už divit, jak vysoké životní náklady máme na to, abychom ráno vstali, přes den pracovali a večer si šli v klidu a míru lehnout.
To vám sice připomíná hezky, ale nic takového reálně neexistuje. Akorát je v ČR módní být proti EU, bez ohledu na jakákoli fakta, tak to také opakujete. Všimněte si, že jste neuvedl jediný konkrétní argument – jen jakási obecné dojmy.aby byl přínos slepého zavádění "tak trochu" diskutabilní
Nejde o žádné slepé zavádění. Je to jednoduchá úvaha – každá komunikace, která může být modifikována, je pro příjemce zcela zbytečná (když můžu dostat jakoukoli informaci, je úplně jedno, když nedostanu žádnou – pokud by mi chyběla, můžu si ji vytvořit třeba z /dev/random). Takže nezbytná komunikace musí být vždy šifrována. -
Ostatně je standardizované řešení, které pro ověření domény důvěryhodnou certifikační autoritu vůbec nepotřebuje (DANE). Takže ta devalvace není nevyhnutelný důsledek šifrování.
Ano, ale v praxi došlo k té devalvaci. V praxi bylo něco možná trohcu s horkou hlavou "vylepšeno", ale to druhé zavedeno se stejnou vehemencí nebylo.
Proto se každé bezpečnostní opatření dělá, abychom předešli nějakému typu útoku – útočník pak musí použít jiné metody, které jsou nákladnější, takže se to méně vyplatí.
Ano, a toto si myslím, že bylo špatně odhadnuto a vyhodnoceno. Přínos v praxi velký není (důležité služby už dávno SSL zavedly), nedůležité jsou přinucovány. Ale ten přesun útoků / útočníků jinam jim sebral méně energie, než si myslíte. Podobné je to s našimi zákony. Vždy něco zalátáme, abychom se nakonec dozvěděli, že gauneři našli další, a ještě méně odhalitelný a ještě méně řešitelný a postihnutelný způsob kradení. Viz např. kauza nehorázně drahého tisku jízdenek pro pražskou MHD - kdy soudy skončily na tom, že není s čím porovnat, jestli ta cena je při takové zakázce přiměřená, či není, a DPP neměl povinnost to lépe soutěžit.
DNS bylo vždy součástí toho řetězce důvěry, už jen z toho prostého důvodu, že DNS je autoritativním zdrojem dat pro překlad jmen na IP adresy
Rád uvádíte, že přínosem HTTPS je, že nikdo uprostřed, v kompromitované přenosové síti, nemůže podvrhnout obsah. Ale ono to tak úplně. Už jen tím, že můžete podvrhnout DNS odpovědi, máte v kompromotované síti obrovskou moc. Jediným řešením by byl 100% přechod na HTTPS a úplné vypnutí HTTP. To není v příštích, dovolím si tvrdit, patnácti letech reálné. Podívejte, že doposud jsme nevyřešili ani šifrovaný přenos pošty, který by byl jistě prospěšnější, nebo jsme se nezbavili prehistorického FTP.
Buďte trochu realista. Já Vám přiznávám idealistické vnímání vývoje technologií, ale nejen nihilisté, ale i přílisní idealisté bývají zaseklí na stejném místě.
To vám sice připomíná hezky, ale nic takového reálně neexistuje. Akorát je v ČR módní být proti EU
Já vůbec nejsem proti EU! Jsem naopak příznivcem federalizace, sjednocení předpisů a zjednodušení a zefektivnění EU. Jsem jedině proti překomplikované EU, která vydává směrnice pro desítky států, které mají na tolik odlišnou kulturu - od Balkánu až po vlny Atlantiku -, žč nejdou v praxi implementovat bez většího výčtu výjimek, než je prvotní myšlenka samotné normy.
Takže nezbytná komunikace musí být vždy šifrována.
Nesouhlasím.
-
Filip JirsákStříbrný podporovatel
Ano, ale v praxi došlo k té devalvaci.
Akorát že ta devalvace není důsledkem šifrování. DV certifikáty se vydávají už mnoho let, dávno před tím, než přišel současný boom šifrování.V praxi bylo něco možná trohcu s horkou hlavou "vylepšeno"
Proč s horkou hlavou, proč vylepšeno v uvozovkách? Máte snad lepší nápad, jak zvýšit bezpečnost na internetu?Přínos v praxi velký není (důležité služby už dávno SSL zavedly), nedůležité jsou přinucovány.
Přece vás nikdo nenutí to šifrování používat. Ty nedůležité služby si klidně můžete číst /dev/random, šifrovat nic nemusíte, a na výsledek máte stejné spolehnutí, jako na ty nešifrované služby.Už jen tím, že můžete podvrhnout DNS odpovědi, máte v kompromotované síti obrovskou moc.
Proti tomu se dá bránit pomocí DNSSEC. Nemůžete chtít, aby se mávnutím kouzelného proutku vyřešily všechny problémy najednou – problémy se řeší postupně, nezávisle na sobě.Jediným řešením by byl 100% přechod na HTTPS a úplné vypnutí HTTP.
Ano, to je cíl. Jenže k tomu cíli se nedostaneme jinak, než postupným zvyšováním podílu HTTPS.To není v příštích, dovolím si tvrdit, patnácti letech reálné.
Já si myslím, že na webu to půjde mnohem rychleji. Ale i kdyby to trvalo patnáct let, budeme mít od teď za 15 let veškerý web šifrovaný. Jak byste to řešil vy? Čekal byste deset let, za deset let bychom začali s tím samým, co se dělá dnes, řešili bychom stejné problémy, a pak by za dalších patnáct let by byl přechod dokončen? Jaký by byl rozdíl v tom, že bychom to celé udělal i úplně stejně, se stejnými problémy, akorát o deset let později?Podívejte, že doposud jsme nevyřešili ani šifrovaný přenos pošty, který by byl jistě prospěšnější, nebo jsme se nezbavili prehistorického FTP.
I ten šifrovaný přenos pošty se v posledních letech zlepšuje, a řekl bych, že právě díky zavádění HTTPS. Ale i kdyby ne. Brání to nějak nasazování HTTPS? Nebo nasazování HTTPS naopak zpomaluje nasazování šifrování pošty nebo ukončování FTP? Mimochodem, je dost možné, že náhradou FTP bude WebDAV, protože SFTP je přeci jen trochu jiná technologie. A pro šifrovaný WebDAV potřebujete zase HTTPS.Buďte trochu realista. Já Vám přiznávám idealistické vnímání vývoje technologií, ale nejen nihilisté, ale i přílisní idealisté bývají zaseklí na stejném místě.
Buďte trochu realista. Konzervativní postoj je užitečný, ale nejde se zaseknout na místě, ani tvrdit, že když něco nevyřeší všechny problémy světa, nemáme se vůbec snažit o zlepšení.Já vůbec nejsem proti EU!
Taková deklarace nevypovídá vůbec o ničem. Miloš Zeman taky tvrdí, že nevede žádnou kampaň.Jsem jedině proti překomplikované EU, která vydává směrnice pro desítky států, které mají na tolik odlišnou kulturu - od Balkánu až po vlny Atlantiku -, žč nejdou v praxi implementovat bez většího výčtu výjimek, než je prvotní myšlenka samotné normy.
Opět jen nicneříkající obecné tvrzení. Jak mám vědět, jaká směrnice je pro vás překomplikovaná, když neuvedete žádný příklad? Naopak takové tvrzení jenom vzbuzuje podezření, že o žádné takové směrnici nevíte a akorát něco papouškujete.Nesouhlasím.
Pokud vám nevadí, že přenášený obsah může být změněn, čtěte si ta nešifrovaná data z /dev/random. Vždyť na tom přece podle vás nezáleží, jestli čtete to, co web server odeslal, nebo něco jiného. -
lojzak (neregistrovaný)
@madloki
Ale jdi ty rozumbrado.
"sifruji se data, ktera jsou sifrovana uplne zbytecne"
Možná je jen tvoje mylná představa, že se šifrují zbytečně. Mimo to, HTTPS není jen o utajení přenášené informace, zaručuje i ověření identity a důvěryhodnost komunikace - tj. že ti nikdo třetí do komunikace nic nepodstrčí (reklamy, malware...).
"nici se zakladni predpoklady pro rychly beh web aplikaci (data nacitana in-paralel z vice zdroju)"
HTTPS nebrání takovému způsobu načítání.
"ze uzivatel cekajici na zelenou pizdu v adresnim okenku browseru ji duveruje stejne slepe, jako kdykoliv predtim"
Což ale není chyba HTTPS, ale toho uživatele. Nehledě na to, že průměrný uživatel ani neví, co ta "zelená pizda" znamená.
"Sifrovat se maji vyhradne formulare, VPN provoz, osobni udaje, online bankovnictvi atp."
A jak poznáš, jaká data jsou citlivá a jaká ne? Jak to pozná browser?
"Vubec nejlepsi by ale bylo na strane browseru v java aplikaci takova data zasifrovat pomoci OTP + klasickeho hesla, ktere jiz uzivatel zna."
Ne, to by nebylo nejlepší. Jak budeš řešit distribusi OTP?
"Kdysi v browseru po kliknuti na tu zelenou ikonu videl uzivatel i udaje o certifikatu, a dnes by u vetsiny browseru musel slozite projit celou sekvenci kliknuti nebo klavesovych zkratek, aby mel vubec sanci neco o pouzitem certifikatu zjistit."
To je problém browseru, ne HTTPS samotného.
S důvěryhodností CA máš pravdu. Ale pořád lepší než nezabezpečené HTTP.
"Dejme stranou, ze takovy mechanismus zatim neexistuje"
Ehm... DANE?
"protoze primo na pocitaci uzivatele mohu pro nej generovat vlastni DNS i DNSSEC"
DNSSEC asi těžko. -
Filip JirsákStříbrný podporovatel
Mne by zajímalo, proč sepisujete takhle dlouhý komentář, když je podle vás úplně jedno, jestli se odešle a lidem zobrazí ten váš komentář, nebo jestli místo něj bude napsáno: „Podporuji co nejrychlejší nasazení HTTPS na všech webech.“ Pokud to podle vás jedno není, potřebujete nějaký mechanismus, kterým zajistíte, že ten váš komentář nemůže nikdo změnit při odesílání na server, a také že jej nikdo nemůže změnit při jeho stahování ze serveru do prohlížeče.
-
Petr M (neregistrovaný)
Zpracováváš osobní nebo citlivý údaje? Šifrovat musíš.
Žije tvoje stránka z reklamy (> 90% webů, co nemají nákupní košík)? Šifrovat musíš, jinak někdo (klidně ISPík) vymění odkazy na reklamu, máš v jeho síti 0 zobrazení a 0 Kč, i kdyby tam šlo 10% trafficu.
Máš e-shop? Šifrovat musíš, aby se cestou nedostal zákazníkovi do objednávky někdo cizí. A udržovat dva stejný weby, jenom s tím rozdílem, že před vložením první položky do košíku nebude šifrování, a ejjich přepnutí, je zbytečná pakárna.
Máš na webu diskuse s možností soukromých zpráv? Šifrovat musíš, pokud soukromá zpráva má být soukromá.
Máš odbornou poradnu? No tak podle OZ za takovou radu právně ručíš a pokud někdo na web doktora vloží cestou nějakou nesmyslnou radu, má doktor minimálně co vysvětlovat, LE je v tomto případě pojistka skoro zadarmo.
Atd.
-
Petr M (neregistrovaný)
Občanský zákoník. A ten komoušský už naštěstí zrušili.
Pokud máš z udělení rady rady prospěch (třeba takový, že dostaneš platbu za zobrazenou reklamu), a osoba, které takovou radu dáš, důvodně předpokládá, že jsi odborník, tak přebíráš zodpovědnost za správnost rady a zodpovídáš za takto způsobenou škodu v plné výši.
No a když někdo pozmění tvůj web tak, že tě pasuje na odborníka, nebo tvým jménem něco pohnojí a někdo jiný na to skočí, máš problém. Jednodušší a rychlejší, než soudy s nepředvídatelným výsledkem je zařídit, že se za tebe nemůže nikdo vydávat.
-
Za prvé: na aplikaci § 2950 OZ nestačí, aby druhá strana důvodně předpokládala, že jste odborník, ale musíte se za něj aktivně prohlásit: "Kdo se hlásí jako příslušník určitého stavu nebo povolání k odbornému výkonu nebo jinak vystupuje jako odborník, nahradí škodu, způsobí-li ji neúplnou nebo nesprávnou informací nebo škodlivou radou danou za odměnu v záležitosti svého vědění nebo dovednosti. Jinak se hradí jen škoda, kterou někdo informací nebo radou způsobil vědomě."
Za druhé: nikdo nepřebírá zodpovědnost, ale odpovědnost.
Za třetí: pokud někdo žaluje o náhradu škody, je důkazní břemeno na žalobci. Pokud není přenos šifrovaný, naopak žalobce možná neunese důkazní břemeno o tom, že si mohl / měl myslet, s kým zrovna komunikuje.
Rozhodně není pravdou, že někdo musí v uvedených případech šifrovat. Je to samozřejmě na výsost důležitá "slušnost". Pokud uniknou data po cestě, odpovědnost nese v první řadě ten, kdo jejich únik umožní - např. ISP, který je nechá odposlechnout. Poskytovatel obsahu samozřejmě ručí za to, že neuniknou data z jeho informačního systému, ale to už nemá nic společného s šifrováním přenosu.
V uvedených případech lze šifrování jen doporučit, ale neměl byste strašit pojmy a tvrzeními, která nejsou pravdivá.
-
lojzak (neregistrovaný)
"Pokud máš z udělení rady rady prospěch"
A když žádný prospěch z poskytnuté rady nemám třeba protože neprofituji z reklamy? Potom můžu dávat špatné rady?Co když jsou provozovatl webu a autor příspěvků dvě osoby. Kdo nese odpovědnost?
A pokud tu špatnou radu učiním jinak (osobně, emailem, prostřednictvím tisku...) taky mi něco hrozí?
Člověk by především neměl být ovce a obzvláště informace zjištěné na internetu dobře ověřovat.
-
> A udržovat dva
stejný weby, jenom s tím rozdílem, že
před vložením první položky do košíku
nebude šifrování, a ejjich přepnutí, je
zbytečná pakárna.Kdyby jen pakárna. Ono je to i dost rizikové. Nemůžete mít HSTS a v některých případech potenciálně děláte sami na svůj web downgrade "attack".
A co by vlastně bylo na čistém HTTP? To, k čemu má přístup nepřihlášený uživatel? Zaprvé by někdo mohl teoreticky nepřihlášenému uživateli podstrčit třeba jiný popis výrobku. Zadruhé, co uděláte s tím, když na tuto stránku vleze přihlášený uživatel? Přesměrujete ho na HTTPS? Bude obsah košíku v iframe? (Hmm, tím se otevírá clickjacking...)
-
Filip JirsákStříbrný podporovatel
On by byl problém i s tím zobrazováním produktů přes HTTP. Útočník pak třeba může změnit cenu – když ji zvýší, zákazník odejde a koupí jinde. Když ji sníží, bude mít zákazník web za podvodníky, když se po přidání do košíku cena zvýší – a taky nakoupí jinde.
Navíc nevím, proč by měl kde kdo vědět, jaké zboží si v e-shopu prohlížím.
-
Problém by byl jak dostat zákazníka z HTTP na HTTPS, když si chce něco koupit. Netřeba měnit cenu, stačí 301 na vlastní e-shop. Chápu, že nějaké konkrétní informace šifrování nemusí potřebovat. Ale pak se nedá věřit žádnému obsahu, na který jsem přišel odkudkoliv linkem z HTTP, protože nemusím být tam, kde si myslím.
-
-
NA (neregistrovaný)
Proč šifrovat všude? Zkusím to jednoduše.
Překonat šifrování dá nějakou práci.
Pokud budeš šifrovat jen to důležité, útočník se soustředí jen na to šifrované.
Když šifruješ všechno, útočník se na to vykašle, nebo má o mnoho víc práce a mnohem víc je nasraný, že mu práce byla k ničemu.Obvyklý špatný příklad.
Používejme obálky jen na posílání cenností. Zloděje nebaví číst o počasí. -
IPv6 by zjednodušoval správu, kdyby se nemusel udržovat dualstack. Největší zlo je potom když potřebujete aby měl počítat IPv6 právě když má IPv4, protože jinak to bude napůl rozbité a bude se to těžko hledat. No a v takovém případě by měl obě adresy dostat z JEDNÉ (auto)konfigurace. Takový standard jsem ale neviděl (ještě, že v serverovně si můžeme dělat i věci které nejsou součástí standardu).
-
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ý podporovatel
Pokud 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ý podporovatel
Pokud 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.
-
martin (neregistrovaný)
tls-sni-01 funguje tak, ze se hashuje token + '.' + key. token je soucasti konkretni challenge, key je udaj z uctu zadatele. Vystaveny certifikat je na pouze jedno jmeno a to je ten hash. HTTPS client se pak na jmeno dotaze a pokud mu server odpovi, je overen.
tls-sni-02 hashuje zvlast token a zvlast key. Self-signed certifikat je na dve domenove jmena a to na hash tokenu a hash key (s tim acme.invalid okolo). HTTPS client se pta na hash tokenu a nesmi nijak prozradit key. Overi tedy, ze zadatel zna key.
Z diskuse okolo vyplynulo, ze nektere web-hostingy umoznuji nahrat libovolny HTTPS certifikat pres web rozhrani. U tls-sni-01 ale musi znat dopredu key. HTTPS client sice key efektivne prozradi, ale to uz je pozde na to, aby tam utocnik nahral certifikat pres web rozhrani. Zaroven se asi key nedozvi pro dalsi pokus (key se narozdil od tokenu nemeni).
Nevsiml jsem si, ze by Lets Encrypt zakazal i tls-sni-02. Pokud ano, zrejme nejak dochazi k prozrazeni key.
-
Filip JirsákStříbrný podporovatel
Let'S Encrypt dnes vůbec
tls-sni-02nepodporuje. K prozrazeníkeypřece vůbec nemusí dojít, útočník ho zná – útočník je v tomto případě žadatel. -
Ondřej CaletkaZlatý podporovatel
Díky za pěkné shrnutí, ta verze 02 je tím pádem o něco bezpečnější, ale proti problému se sdílenými hostingy je stejně neúčinná.
Z diskuse okolo vyplynulo, ze nektere web-hostingy umoznuji nahrat libovolny HTTPS certifikat pres web rozhrani. U tls-sni-01 ale musi znat dopredu key. HTTPS client sice key efektivne prozradi, ale to uz je pozde na to, aby tam utocnik nahral certifikat pres web rozhrani. Zaroven se asi key nedozvi pro dalsi pokus (key se narozdil od tokenu nemeni).
Jaktože ne? Když vystupuji v roli žadatele o certifikát, dostanu od autority (bez ohledu na verzi 01 nebo 02) přesné zadání, jaký mám vytvořit self-signed certifikát a musím nahrát ho na hosting. Není na to žádný (zásadní) časový limit. Teprve až ho na hosting nahraju, sdělím autoritě, ať to prověří. Nemusím tedy sedět na hostingu a čekat, na co se bude autorita ptát a na základě toho vyrobit certifikát, což je útok, proti kterému verze 01 nechrání, ale verze 02 ano.
Nevsiml jsem si, ze by Lets Encrypt zakazal i tls-sni-02
To proto, že ho zatím nepodporují.
Mimochodem, metoda ověřování
http-01používá k ověření také řetězec<jméno ověřovaného souboru>.<hash klíče účtu>, což vedlo k vynálezu stateless režimu, kdy webserver pozitivně ověří jakoukoli výzvu z daného ACME účtu. Nevím, co si o tom mám myslet, na jednu stranu je to drobné zjednodušení pro administrátory, na druhou stranu to klade obrovské nároky na ochranu privátního klíče ACME účtu, protože se z něj vlastně stal zlatý klíč pro vydávání jakýchkoli certifikátů. -
Ondřej CaletkaZlatý podporovatel
Ano, týká. Certbot metodu používá ve výchozím nastavení. Můžete ho zkusit ručně přepnout pomocí nějakého přepínače, nebo počkat na update, který to udělá za vás.
