Vlákno názorů k článku
Chrome postupně odstraní zámeček pro HTTPS v adrese
od Josef Pavlik - misto blbosti se zmenou barvy zamku by se...
-
misto blbosti se zmenou barvy zamku by se meli zamysled nad tim, proc, kdyz napisu adresu bez specifikace protokolu, jdou default na http a ne na https. To je pak k nicemu.
priklad
mam web server a na nem nejake stranky dostupne jak pres http, tak pres https
do browseru napisu https://mujweb.com, dostanu to po https
ale pokud napisu jenom mujweb.com, dostanu to pres http
To je blby, co?
Jestli se chce nekdo ptat proc to http nenecham automaticky presmerovavat na https, tak je to kvuli klientum, co se nedokazou pripojit pres https (nemluvim o klientech lidech, ale o klientech strojich). -
Jestli se chce nekdo ptat proc to http nenecham automaticky presmerovavat na https, tak je to kvuli klientum, co se nedokazou pripojit pres https (nemluvim o klientech lidech, ale o klientech strojich).
Na to Vám zde kolegové napíší, že problém je Váš a minoritní, a abyste dokázal, že přechod na https Vás bude stát nějaké peníze.
-
Sten (neregistrovaný)
To je proto, že ne všechny HTTP servery umí HTTPS a přesměrovat z HTTP na HTTPS je triviální, obráceně to moc nejde.
Nemůžete ty klienty rozlišit pomocí
User-Agenta zbytek přesměrovat? Také můžete použít HSTS preload, Chrome pak automaticky použije HTTPS. -
> Nemůžete ty klienty rozlišit pomocí User-Agent a zbytek přesměrovat?
Jo, muzu, ale prijde mi jednodussi a spravnejsi nabizet obsah obema protokoly. Kdo chce, vezme si to pres https. Kdo nechce nebo nemuze, vezme si to pres http. Nektere stare verze nasich produktu se nedokazou spojit pres https, protoze kryptografie, ktera fungovala pred 10 lety uz dnes nefunguje. Pokud si zakaznik z jakehokoliv duvodu nechce nebo nemuze upgradnout system, neda se nic delat, pouziva 10 let stary produkt a ten se proste nedokaze spojit pres https. User-Agent je furt wget, dokonce stejna verze jako v posledni verzi produktu, ale chybi tam pravdepodobne podpora nejposlednejsich kryptovacich agoritmy, diky cemuz se to nespoji. Ono uz jenom donutit ssh aby se spojilo s temito starymi systemy byl peknej porod.Problem na ktery jsem chtel upozornit je v tom, ze i presto, ze vsichni vyrobci browseru se predhaneji v tom, aby zobrazovali warningy, ze web neni zabezpeceny, tak kdyz maji obe moznosti, vyberou si tu nezabezpecenou.
HSTS preload je uz uplne na hlavu postavena vec. -
vyrobci browseru se predhaneji v tom, aby zobrazovali warningy, ze web neni zabezpeceny, tak kdyz maji obe moznosti, vyberou si tu nezabezpecenou.
Pravda.
HSTS preload je uz uplne na hlavu postavena vec.
To si nemyslím. To je něco, co je vědomě a kontrolovaně iniciované poskytovatelem obsahu, a příjemce se tím řídi může, nebo nemusí. Zvyšuje to bezpečnost tam, kde obě strany chtějí, ale nepopírá ji tam, kde jedna ze stran nechce.
-
Filip JirsákStříbrný podporovatelNicméně prohlížeč by nezabilo, kdyby zkusil nejprve HTTPS, a když se nepodaří navázat spojení nebo v případě chyby, teprve pak by zkusil HTTP. Který protokol má prohlížeč vyzkoušet je jenom věcí tradice, navíc by se tím mírně zrychlilo načítání webů bez HSTS dostupných přes HTTPS.
-
Sten (neregistrovaný)
Jak dlouho by měl takový prohlížeč čekat? Chrome má snahu načíst obsah co nejrychleji, čekat na několikasekundový timeout (některé weby jsou velmi pomalé) při zkoušení HTTPS se k tomu moc nehodí. To přesměrování, pokud je udělané přes 301 Moved Permanently, si prohlížeč zapamatuje a příště jde rovnou na HTTPS, ale jak může vědět, že zrovna teď nefungující HTTPS neznamená, že to jen někdo někde blbě nastavil a příště ho nemá zkusit?
-
Filip JirsákStříbrný podporovatel
Pokud je server správně nakonfigurovaný, dozví se prohlížeč hned, že je port nedostupný. Jinak prohlížeč klidně může zahájit spojení na oba porty najednou, a pokud dostane odpověď na portu 443, spojení na portu 80 resetuje. Navíc Google upřednostňuje HTTPS ve vyhledávání, HTTP/2 podporuje jen s HTTPS, prodleva při čekání na timeout na portu 443 může být ze stejného ranku – pokud chcete, aby váš web fungoval co nejlépe, použijte HTTPS. Je to docela schizofrenní, že je snaha všude nasadit HTTPS, ale přitom pro provoz HTTPS potřebujete povinně HTTP – v prohlížeči pro přesměrování prvního požadavku, u ACME pro ověření vlastnictví domény přes HTTP server…
-
Ondra Satai NekolaZlatý podporovatelZkouset soucasne spojeni sifrovane i nesifrovane je recept na problemy.
-
Filip JirsákStříbrný podporovatel
Ano, bývají to ty samé servery, které neodpovídají na ping. A u kterých pokud možno správce zakáže i veškerý odchozí provoz a pak se diví, že se mu na serveru nepřekládá DNS. V drtivé většině případů má DROP jediný smysl– správce chce všechno co nejvíc omezit, a řeší jenom ideální stav ze svého úzkého pohledu, takže ho nenapadne, že by web asi měl běžet na HTTPS a už vůbec ne to, že když na něm neběží, měl by to dát server co nejrychleji najevo.
-
Také se přikláním k tomu, aby se v rozumné míře používaly rejecty.
Bohužel, je oblíbeným nešvarem, že dropy se používají na hraničních routerech vnitřní sítě při požadavcích ven. Uživatelé pak jako paka čekají na timeouty, zatímco s rejectem by šlo všechno svižně.Rejecty mají smysl u služeb, které nesouvisí nijak s běžným provozem a určením serveru. Pokud někdo chce provozovat jen https, tak by měl být na portu 80 bezpodmínečně reject a ne drop.
-
j (neregistrovaný)
Tak jasne, tupej jirsak kterej vi o vsem lautr hovno tu bude zvanit o tom jak je drop spatne ... vis ty kokote co udela ten tvuj reject kdyz ti na to poslu hromadu paketu s podvrzenym src? Nj, preposle to vseho na tu src ip ... krasa co? A protoze tohle admini narozdil o debila jirsaka vedi, tak to rovnou zahodej.
-
Filip JirsákStříbrný podporovatel
Ano, to je takzvaný „jéčkův zeslabující útok“. Normálně by útočník použil nějaký zesilující útok na cíl, nebo alespoň na cíl útočil přímo. Místo toho začne navazovat podvržená TCP/IP spojení a na každý TCP SYN paket o délce 40 bajtů vyloudí z prostředníka ICMP paket Destination port unreachable o délce 28 bajtů. To je snížení datového toku o více než čtvrtinu, takže pokud by útočník dokázal normálně útočit silou 10 Gbit/s, tento speciální jéčkův zeslabující útok mu umožní omezit sílu útoku na 7 Gbit/s.
-
K tomu je i issue v bugzille mozilly [1]. Pokud se nespojíte nebo dojde k chybě certifikátu, situace je jasná. Horší by to bylo s jiným obsahem nebo s mixed content. Tam je někdy těžké poznat, zda je stránka v pořádku. Na jednu stranu možná nebude množství takovýchto stránek malé, na druhou stranu: Pokud se admin nerozhodl přesměrovat, snad k tomu měl dobrý důvod.
Méně kontroverzní by asi bylo spekulativně navázat HTTP i HTTPS a v případě přesměrování ušetřit trochi času.
-
Připojují se ty stroje ke stejným URL jako lidi? Nebo jen k nějakému API, které možná stránka na pozadí používá, ale nejde o URL, o které by věděl uživatel (pokud si neotevře zdroják nebo developre console nebo podobně)? Pak by bylo asi nejelegantnější z přejměrování pár URL vyjmout. (Pokud vyjmete i obrázky, zavádíte duplicitní obsah, ale u obrázků by to mohlo být ještě snesitelné.)
Detekce UA se taky nabízí, jak tu někdo zmiňoval. Je to sice trochu hack, ale snad celkem akceptovatelný. Redirect u wgetu bych za moc důležitý nepovažoval.
Dal by se udělat i oportunistický upgrade pomocí JS spolu s HSTS, ale to bych bral jako poslední variantu. Přináší to některé problémy, například:
* Pomalejší první redirect.
* Duplicitní obsah pro vyhledávače.
* Když budete generovat URL třeba do e-mailu, kterou variantu zvolíte? Pokud máte aplikaci zcela ve své režii, je to ještě v pohodě (no, framework může trochu působit potíže), u hotové aplikace to může vyžadovat ošklivé hacky.(Bez HSTR budou nevýhody výraznější – jak výkonově, tak bezpečnostně.
Dvě varianty webu (HTTP a HTTPS) bez oportunistického upgrade přinášejí ještě více problémů, například:
* Duplicitní obsah i pro uživatele. Například: Dělám společnou objednávku, dám zboží do košíku (HTTPS), dostanu od někoho link (HTTP), kliknu na něj a vidím prázdný košík. (Podobný problém můžete také mít u variant s „www.“ a bez „www.“.)
* Varianta s HTTP může nastavit cookie variantě s HTTPS. Uživatel tak může být například nechtěně přihlášen útočníkem na síti. Dopad je stejný jako u https://support.detectify.com/customer/portal/articles/1969819-login-csrf , liší se jen způsob provedení. Nabízí se i vyšší náchylnost k session fixation, ale to lze ošetřit.
