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.
Dobř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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.