Názory k článku
Mozilla jde do boje proti nešifrovanému webu
-
To je nebezpečné. Vytvoří to totiž závislost na certifikačních autoritách. Dnes je možné publikovat informace svobodně, ale už bude zakázáno HTTP, tak pouze když vám autorita vydá klíč. Dnes sice existuje pár autorit, co to dělají zdarma každému, ale nijak není zaručeno, že to bude být navždy.
Mělo by být postačující public klíč dát do DNS (TLSA), ale není !
-
Ľubomír Mlích (neregistrovaný)
Zaujala mně fráze
for universal use of encryption by Internet applications, which in the case of the web means HTTPS
Je rozdíl provozovat webovou aplikaci (například hru nebo facebook) nebo blog či statický web, který využívá pouze html a css.
U html a css mi vůbec nevadí, že můj web nemůže zapnout webkam nebo mikrofon. Naopak jako klient statického webu ocením, že můj prohlížeč je dostatečně chytrý a ví, že na těchto stránkách mikrofon zapínat opravdu nemá.
-
Trident (neregistrovaný)
Otazkou je, jestli je implementace weboveho serveru na 8mi bitovem MCU to prave. Ale flagelantum a kakademikum aspirujicim na unudene zamrzle inzenyry na prumce nechci ovlivnovat jejich obskurni cestu k umeleckemu vytvoru za kterou by se nemusel stydet ani picasso.
Misto tehle vopicaren jsem treba senzorovy prijimac navrhl tak ze to byl tandem ARM procesoru na kterem bezel hlinux. Atmel se staral o low level veci a posilal to armkove casti po uartu kde uz to zvejkal skript a byl tam naky xy ch t. Slo by pouzit i spi ale nebyl duvod a byl jsem linej.
-
ondro (neregistrovaný)
To, co je za sprostost?
Je kopa webov, kde je sifrovanie zbytocnost. Naco by si napriklad niekto mal davat sifrovanie na svoj blog, kde nema dokopy nic To iste aj stranky, ktore publikuju verejne pristupne data.A ako tu uz bolo spominane, na HTTPS potrebujem certifikat a kto mi zaruci jeho doveryhodnost?
HTTPS stoji len na doveryhodnosti a to je pre mna dost tenky lad. -
Filip JirsákStříbrný podporovatelDobře, dejme tomu, že je někde šifrování zbytečné. Ale vadí tam něčemu? Je potřeba kvůli tomu blogu udržovat druhý protokol, jeho implementaci v prohlížečích a serverech? Je potřeba kvůli tomu blogu neustále řešit bezpečnostní rizika vyplývající z toho, že se útočníkovi může podařit přepnout klienta na nezabezpečený protokol?
Důvěryhodnost certifikátu vám zaručí například certifikační autorita nebo DNSSEC. Nechápu, jak můžete v jednom komentáři napsat, že "HTTPS stojí jen na důvěryhodnosti" (to každá bezpečnostní technologie), a zároveň, že HTTPS často není potřeba. Nešifrované HTTP nikdy nebude důvěryhodnější, než HTTPS.
-
ondro (neregistrovaný)
Za mna vadi. Naco mam pouzivat nieco navyse, co nepotrebujem? Mne nevadi, ze HTTP je menej doveryhodne ako HTTPS. Tu vecsiu doveryhodnost v urcitych pripadoch jednoducho nepotrebujem.
Riesis, ze klasicka posta alebo prepravne spolocnosti ti nijako negarantuju, ze tvoj list laebo balik nikto neotvori, neupravi,...? Ja nie a som rad ze je to tak, lebo pre moje vianocne pohladnice a baliky z bazosu, takuto sluzbu nepotrebujem a zbytocne by to predrazovalo ich sluzby.
Dolezite veci ale postou alebo prepravnou spolocnostou neposielam a na to pouzivam ine sposoby, ktore su tak doveryhodne ako je dolezita zasielka.
Som si toho vedomy, ze kazda bezpecnostna technologia stoji na doveryhodnoti a prave preto som to spomenul(na to upozornil). HTTPS, DNSSEC,... stoja na doveryhodnoti, ktoru bezny clovek nieje schopny zhodnotit a ziadna technologia nieje 100%.
p.s. To, ze utocnikovi sa moze podarit prepnut klienta na nezabezpecny protokol nieje problem protokolu ale problem klienta.
-
Filip JirsákStříbrný podporovatel
To, že něco nepotřebujete, pro mne ani náhodou není dostatečný důvod, proč udržovat implementace dvou protokolů a proč vytvářet spoustu bezpečnostních rizik pro HTTPS.
Pokud by klasická pošta uměla zabezpečené zásilky posílat za stejnou cenu, jako pohlednice, a pokud by možnost posílání pohlednic vytvářela spoustu rizik pro zasílání těch zabezpečených zásilek, samozřejmě bych chtěl, aby posílala pouze ty zabezpečené zásilky.
To, ze utocnikovi sa moze podarit prepnut klienta na nezabezpecny protokol nieje problem protokolu ale problem klienta.
On taky nikdo nechce zrušit ten protokol, ale chce změnit klienta, aby protokol přepnout nešlo - někdy v budoucnosti. -
ondro (neregistrovaný)
O akych bezpecnostnych rizikach pre HTTPS tu rozpravas? Nema byt HTTPS bezpecne?
Ja nepovazujem za problem zaimplementovat do prehliadaca pravidla -
-ak som naviazal nesifrovane spojenie, tak pocas takehoto spojenia mozem prejst na sifrovane alebo nie.
-ak som naviazal sifrovane spojenie, tak pocas takehoto spojenia nemozem prejst na nesifrovane.Co sa tyka inych aplikacii ako v prehliadacoch, tak tam to je otazka na danych vyvojarov a uzivatelov ako je/bude implementacia urobena.
Samzorjeme, ze keby to posta vedela posielat za rovnaku cenu, tak by s tym nikto nemal problem, ale to tak nieje.
To iste plati aj vo svete internetu/intranetu. Ak by to slo rovnako urobit s rovnakymi nakladmi a nebol problem s uz existujucimi projektami, tak proti tomu nemam nic. Bohuzial to tak nieje. To je ten problem. Impementacia HTTPS je a asi aj stale bude nakladnejsia.Mozilla to moze urobit, nikto jej v tom nebrani a ani ja nie. Ja som vyjadril svoj nazor, ze to povazujem za nezmysel.
-
Filip JirsákStříbrný podporovatel
Ano, HTTPS má být bezpečné. Jenže existuje mnoho různých způsobů, jak tam, kde by mělo být HTTPS, protlačit HTTP. A HTTP už bezpečné není. Takže potřebujete nějaký způsob, jak tomu přepnutí na HTTP zabránit. A nepodporovat vůbec HTTP je nejbezpečnější možný způsob.
ak som naviazal sifrovane spojenie, tak pocas takehoto spojenia nemozem prejst na nesifrovane
Záleží na tom, čemu říkáte „spojení“. Pokud TCP/IP spojení, pak to takhle funguje – ale je to prakticky k ničemu. Představte si takový příklad, že vám přijde e-mail, který se tváří, že je od vaší banky – a v něm je odkaz na web banky. Na to žádné kejkle se spojením nepomohou, tam je jediná možná obrana – že prohlížeč nešifrované spojení vůbec nenaváže.Impementacia HTTPS je a asi aj stale bude nakladnejsia.
V čem je nákladnější? Že musí správce do konfiguračního souboru uvést cestu k privátnímu klíči? To je pořád míň práce, než když musí konfigurovat HTTPS a vedle toho ještě HTTP. -
ondro (neregistrovaný)
Prilis si neviem predstavit, ze by mal byt velky problem osetrit prepinanie medzi HTTPS a HTTP. Zrusenie podory HTTP je asi najbezpecnesji sposob ale asi aj nahorsi. Keby som chcel pouzivat aj HTTP, tak by som potreboval iny prehliadac, co je dalsia nevyhoda.
Ako som spominal to, ze HTTP nieje bezpecne, nieje problem. To je jeho vlastnost,ktoru ja nepovazujem za problem.Na ten tvoj priklad s odkazom na web banky nepomoze nic. Ludska hlupost je nekonecna a urobit nieco blbovzdorne je nemozne.
Ako by vlastne v tomto pripade pomohlo nenaviazat nesifrovane spojenie? Utocnik mi podvrhne svoju sifrovanu stranku a veselo sa ide dalej. BFU aj tak nekontroluje odkaz alebo stranku, na ktoru sa pripaja.Je nakladnejsia, nielen o tu cestu. Je predsa minimalne potrebne si ten certifikat zabezpecit a pravidlene obnovovat. Sifrovanie bude asi trochu narocnejsie na HW ale dnes to asi nieje prilis dolezite.
Tipujem ze self signed certifikaty tiez chcu uplne blokovat.U https(certifikatov) moze byt aj iny problem. Uz par krat sa stalo, ze do obehu sa dostali ukradnute certfikaty, ktore sa tvarili ako prave a aj to, ze prehliadac vyhlasil platny certfikat za neplatny(nedoveryhodny). Niekto sa dostane k privatnym klucom a mame tu dalsi problem. Len HTTPS neriesi nic. Pri potrebe poriadne zabezpecit sluzbu sa aj tak musi riesit este dodatocne opatrenia.
Opakujem je kopa stranok a pouziti, kde toto vsetko je zbytocne. Naco si pri davat komplikaciu, ked to nemam potrebne.HTTPS nieje vseliek ale mam pocit, ze Mozilla to ma snahu tak prezentovat.
-
Filip JirsákStříbrný podporovatel
Uživatel si spíš všimne, že mu v adresním řádku místo zeleného „Banka a. s.“ svítí „Hacker s. r. o.“, než že tam není vůbec nic.
Vytvoření a obnovování certifikátů pro DNSSEC zvládají skripty, není žádný důvod, proč by to nemohly zvládnout i pro HTTPS.
Nikdo netvrdí, že HTTPS je všelék. Ale já považuju za komplikaci používat dva protokoly tam, kde jeden protokol umí všechno, co ten druhý, a podstatné věci navíc. Už v případě standardizace HTTP/2 se původně uvažovalo o tom, že nebude existovat nešifrovaná varianta. Nakonec autoři vyměkli a doplnili i nešifrovanou variantu – z mého pohledu je to dobře, protože na přijetí nové verze protokolu panovala všeobecná shoda, opuštěním HTTP bude pomalejší, takže HTTPS nebude bránit nasazení HTTP/2. Na druhou stranu, Google i Mozilla deklarovali, že nešifrované HTTP/2 nebudou implementovat, takže podle mne opuštění HTTP a nasazení HTTP/2 půjdou ruku v ruce. A není proč to protahovat, nešifrované protokoly jsou přežitek a jediný reálný důvod pro jejich podporu je zpětná kompatibilita. Jako zbytečný zanikl např. Gopher, stejně zanikne i nešifrované HTTP.
-
ondro (neregistrovaný)
Prehanas to paradne. Pracujem denne s BFU a garantujem ti, ze minimalne 90% ludom je jedno, co maju v adresnom riadku a akou farbou.
Ako mi skript objedna a zaplati cerfikat na moj web?
Ja zase nepovazujem za komplikaciu pouzivat obidva protokoly a nepovazujem HTTP za prezitok. V tejto diskusii uz bolo uvedenych viacero prikladov, kde je sifrovanie zbytocne(pouzitie nesifrovaneho protokolu za dostacujuce).
Uz len do toho mnozstva zariadeni s webovym rozhranim by bolo zbytocne davat sifrovanie. Naco by bolo dobre aby moja Epson tlaciaren pouzivala sifrovanie?
Je len dobre, ze do HTTP/2 doplnili aj nesifrovanu verziu. Urcite nevymekli ale pochopili, ze len sifrovana verzia nieje dobra(prave na taketo pouzitia). Predpokladam, ze ak by to neurobili, tak zivotnost HTTP by sa ovela predlzila alebo by vznikli alternativne nesifrovane protokoly pre pouzitie napriklad v tych tlaciarnach. -
Filip JirsákStříbrný podporovatel
Skript neobjedná a nezaplatí certifikát. Skript vygeneruje certifikát a umístí ho do DNS.
To, že je někde šifrování zbytečné, není důvod k nešifrování. Navíc to šifrování je zbytečné mnohem méně často, než si myslíte - třeba ta vaše tiskárna je asi připojená přes WiFi, a asi nechcete, aby si mohl každý odposlechnout heslo k té tiskárně, odposlechnout, co na ní tisknete, a případně si díky heslu něco vytisknout sám.
-
Stefan (neregistrovaný)
Dobrý den,
můžu se zeptat jaký " Je potřeba kvůli tomu blogu udržovat druhý protokol, jeho implementaci v prohlížečích a serverech?" se udržuje navíc pro spojení HTTP ?? HTTP protokol se používá i při HTTPS pouze je obalen SSL tunelem.
A co se týká důvěryhodnosti, ta je opravdu důležitá na stránkách místního sboru dobrovolných hasičů u šachového kroužku základní školy v Horní dolní, nebo například při projektech kroužku "programování" na základní škole.Stefan
-
Filip JirsákStříbrný podporovatel
Nikoli, HTTPS není jen HTTP obalené SSL tunelem. Je to dost podobné, ale jsou tam rozdíly – a postupem času těch rozdílů přibývá. Např. pro HTTP/2 bylo potřeba vymyslet mechanismus, jak se obě strany dohodnou na podpoře HTTP/2 – pro šifrovanou variantu ten mechanismus není potřeba, protože se použije metoda, která je v SSL dávno.
-
Je vidět, že jste odborník na všechno.
Pokud dneska útočník bude chtít cestou od web serveru do prohlížeče vložit do stránky nějaký škodlivý kód, nic mu v tom nezabrání a Vy, ať už jste laik nebo expert, nemáte šanci nic takového poznat. HTTPS tento problém řeší.
Co se týče kontroly certifikátů (útok přes MIM), tak vzhledem k rozšířenosti EV certifikátů u důležitých institucí (zejména banky, atd.), tak pokročilý uživatel i poučený laik si zkontroluje "zelenou lištu", takže tady lze MIM útokům zabránit. Nepoučený laik nebo laik-ignorant se chytne i na MIM útok, ale to je jejich problém. Poslední dvě skupiny se nachytají na cokoliv, nicméně to nesnižuje hodnotu snažení zabezpečit komunikaci mezi klientem a serverem.
Nasazením HTTPS jednoduše snižujete rozsah typů útoků na klienta. -
Nerikam, ze nasazeni HTTPS nema smysl. Ale take rikam, ze slepe verit certifikatum se neda. A nevim, jestli vynuceni HTTPS a jednou naproste opusteni HTTP je inteligentni volba. Aby treba muj domaci router jednou nestal dvakrat tolik jen proto, ze do nej nekdo nacpal vic pameti a tlustsi CPU proto, aby to utahlo HTTPS server pro webove rozhrani, na ktere se koukam parkrat do roka.
-
j (neregistrovaný)
No je videt ze ty nerozumus vubec nicemu.
Https vubec nijak neresi, jestli nekdo neco nekam vlozi. Staci vlozit nejaky ten iframe. Ziskat "duveryhodny" certifikat je pak taktez otazka lusknuti prsty, nehlede na to, ze primet uzivatele k importu zcela libovolnyho certifikatu je snad jeste trivialnejsi.
A existuji dalsi tisice zpusobu ... viz linky.
Https resi jeden z tisicu vektoru utoku, ale to jen a pouze za predpokladu, ze !!! obe strany !!! striktne dodrzuji nejaka pravidla. Coz zaroven znamena, ze v realnym internetu https neresi vubec nic. A naopak, pri zpusobu jakym s nim nakladaji soudobe prohlizece je to mnohem horsi, nez http. Prave proto, ze uzivateli tvrdi, ze jakysi zeleny radek === je v bezpeci, coz neni pravda a to ani z promile.
-
Filip JirsákStříbrný podporovatel
Tak nám to předveďte tady na Rootu, jak „vložíte nějaký iframe“. A to získání důvěryhodného certifikátu lusknutím prsty bych také rád viděl. Jinde v diskusi si někdo stěžuje, jak je získání certifikátu pracné…
Jinak změnit HTTP komunikaci může třeba každý router po cestě – a může si vybrat, zda změní DNS odpověď, nebo přesměruje HTTP spojení na svůj server (běžně to dělají třeba WiFi sítě pro hosty). Mít certifikát, který uživatelův prohlížeč akceptuje, oproti tomu vyžaduje alespoň nějakou snahu na straně útočníka.
-
Filip JirsákStříbrný podporovatel
Zrovna v dnešní době žere na mobilních zařízeních HTTPS baterku méně, protože se spolu s HTTPS používají efektivnější protokoly SPDY nebo HTTP/2.
HTTPS není závislé na prodávaných certifikátech, takže těžko může zvyšovat tlak na prodej certifikátů. Naopak prosazování HTTPS bude zvyšovat tlak na používání bezplatných certifikátů. A ten tlak bude o to účinnější, že HTTPS prosazují autoři prohlížečů - tím snazší bude přijít za nimi a říct "OK, vy prosazujete HTTPS, tak ale nejprve implementujte do prohlížeče DANE".
Před neověřeným certifikátem varují prohlížeče odjakživa, to není žádná novinka.
-
Kolemjdoucí (neregistrovaný)
Jsi tak hloupej nebo jenom navedenej ? Protokol se netýká energeticky náročného dešifrování, to zůstává. HTTP/2 snižuje čas nutný k přenesení dat, nikoliv energetické nároky.
Certifikáty zadarmo dneska jsou, ale zítra být nemusí, snadno se může stát že prohlížeč bude akceptovat jenom svoje CA.
Dříve prohlížeče před neověřeným certifikátem pouze varovaly grafickým symbolem, dneska se musí aktivně kliknout, zítra to nemusí jít vůbec.
-
Filip JirsákStříbrný podporovatel
Přenos dat je také energeticky náročný. Mnohem víc, než dešifrování.
To, že certifikáty zítra nemusí být zadarmo, není žádný argument proti HTTPS. Úplně stejně bych mohl tvrdit, že zítra zadarmo nemusí být webové servery, a že je tedy špatně celý protokol HTTP. Navíc jsem psal, že s rozšiřováním HTTPS bude tlak na to, aby domain validated certifikáty nevydávaly certifikační autority, které na DV certifikátu neověří nic, co nemůže ověřit automaticky prohlížeč z DNS.
Neověřený certifikát musel uživatel odkliknout už v dobách MSIE 4.0 a NN 4.0. Že to zítra nemusí jít vůbec opět není žádný argument, stejně tak zítra nemusí jít vůbec přistoupit k webu přes HTTP (a na rozdíl od neodklikávatelných certifikátů to tak opravdu bude, čím dřív, tím lépe).
-
Filip JirsákStříbrný podporovatel
Traffic sice zůstává stejný, ale komunikace trvá delší dobu, takže mobil musí delší dobu aktivně komunikovat se sítí a delší dobu něco zpracovává, takže se nemůže přepnout do úspornějšího režimu.
Hádat se nemá cenu, úplně stačí najít screenshot té hlášky o nevalidním certifikátu. Což je otázka pár vteřin. Takže tady jeden takový screenshot máte, je z MSIE nejspíš verze 6.0, určitě ne novější: http://www.differentpla.net/content/system/files/images/cdef0389431e23bd8b18660d7948718a-182.png
-
Filip JirsákStříbrný podporovatel
HTTP komunikace může trvat třeba dvakrát nebo pětkrát déle, než HTTPS (SPDY nebo HTTP/2) - vyzkoušejte si to. Ano, na spotřebě to při běžném používání nepoznáte, ale to ani to šifrování.
-
Rozdíl v čase komunikace v http a https může být dost zásadní. Vyzkoušejte si v mobilu např. tento test:
http://www.httpvshttps.com -
Ondra Satai NekolaZlatý podporovatelAle s http2 jde dolů.
Navíc vážně to šifrování sežere na současných mobilních strojích nějaký smysluplný zlomek toho, co pak zabere renderování html s css a hlavně svícení displaye? Notabene když AES je prakticky zadarmo a týká se to jenom asymetrické části komunikace? -
Ondra Satai NekolaZlatý podporovatel
Vzhledem k AES-NI te realne stoji praci jenom ta asymetricka cast. A to je porad zanedbatelne vzhledem k renderovani a sviceni displaye a prenosum po siti.
-
muf (neregistrovaný)
Až bude všechno rozjásané a sluníčkové a já si budu doma nebo ve firmě na privátní síti chtít rozjet webovou službu, budu se kvůli podobným blbům muset zabývat ověřeným certifikátem nebo mně Komise pro Totální Blaho a Dobro milostivě dovolí si pomocí starých knihoven napsat HTTP browser?
-
Ondra Satai NekolaZlatý podporovatel
Argumentujes proti nejake podivne verzi budoucnosti a tak svuj argument proti Mozille, ktera se nemuze branit, vyhravas. Gratuliki!
-
Ondra Satai NekolaZlatý podporovatel
Ale zase to "j" napsal hodne agresivne, takze urcite bude mit, bez ohledu ne najake dukazy o opaku, pravdu. Jinak by prece takhle nepsal, ze ne?
-
Filip JirsákStříbrný podporovatel
V současných nejpoužívanějších prohlížečích (Firefox, Chrome, Internet Explorer, Safari) nic takového udělat nejde, protože síťovou komunikaci zajišťuje vždy jádro prohlížeče a neexistuje žádné rozhraní, přes které by to mohl nějaký plugin ovlivnit. Externí program by to udělat mohl, pokud by se prohlížeč připojil k němu (např. by to byl proxy server) a tento program by měl privátní klíč k důvěryhodnému certifikátu cílového webu. Někdy se to takhle dělá ve firemních sítích - proxy server pošle prohlížeči vygenerovaný certifikát pro cílový web podepsaný firemní certifikační autoritou, která je ve všech prohlížečích ve firmě předinstalovaná jako důvěryhodná. Tím pádem se ten proxy server dostane dovnitř té HTTPS komunikace - je to klasický Man-in-the-middle útok s podvrženým certifikátem.
ČLÁNKY DO MAILU
