Názory k článku
Odteď jsou pro Chrome všechny HTTP stránky ne-bezpečné

Ja som sa nikdy na "Secure" a "Non Secure" nedíval, koukám se na http:// nebo na https:// a samotný certifikát pri stránkach kde odosielam citlivé dáta.

Byly časy kdy protokol Chrome schovával..

Byli časi kdy Internet byli len statické stránky bez JS a kde nekterý lidé mohli ochodovať klidne aj s bielym mäsom a problém nebol.

Byly časy, kdy IE varoval při přístupu na HTTPS web.

Nebolo to tak, že varoval, že https web obsahuje položky sťahované cez http?

To hlásenie bolo niečo v zmysle Táto stránka obsahuje zabezpečené aj nezabezpečené položky. Chcete stiahnuť aj nezabezpečené položky?

Jak řešit ale intranet? My máme produkt s webovým rozhraním, který si zákazník nasazuje do svého intranetu, případně si ho instaluje na své lokální PC. Řešit v intranetu nebo lokálně nějaký certifikát nedává vůbec žádný smysl.

Už teď nemůžeme používat HTTP2, protože Chrome vyžaduje https...

Nebo znáte způsob, jak to v intranetu a lokálně obejít (aspoň pro to HTTP2)?

pre situácie ako lokálne systémy vrátane intranetu sa chrome upozornenie nezobrazuje.

Dej si facku a nauc se trochu bezpecnosti. Kazda komunikace musi byt sifrovana. Neco jako perimetr uz roky neexistuje. Kazda sit je neduveryhodna.

Ty si dej facku. Jsou i veci kde zadna duverna data nevkladas ...

Dnes jsou na webu takové nesmysly na “seriózních” stránkách, že je mi úplně fuk, jestli ty pitominy napsal vydavatelstvím placený novinář nebo troll s podrvženým certifikátem.

Obávám se, že naprostá většina stránek, na které chodím, protokol https prostě nepotřebuje. Nevím, proč musejí být složitě šifrované třeba recenze linuxových programů tady na rootovi.

Dej si facku, pak si rozkopni prdel a rozslapni drzku ....

On totiz bude kazdej kvuli kretenum u guugla a chrozlly kazdyho 1/2 roku zahazovat veskerej HW proto, ze si nekdo z nich vzpolemene, ze pouzitej algoritmus neni bezpecnej.

Nebude nic vyhazovat. Existuje čistší řešení.

On totiž může po dodavatelích požadovat podporu třeba na pět let, zahrnující aktuální zabezpečení a bezpečnostní updaty.

Že se na to dneska hází bobek je věc jiná...

Promin, ze jsem te rozbrecel. Tak si to tak neber, ze nicemu nerozumis.

A navíc, co v tom interním webu chodí? Budu hádat:
- Docházka. Tam je nějaký webový rozhraní, kde se uživatel přihlašuje a jsou vidět osobní údaje jako jméno, příjmení, návštěvy lékaře,... Tam by zabezpečení rozhodně neublížilo.
- Zdrojáky, výrobní dokumentace, finanční plány,... Prostě firemní know-how. Zabezpečit to heslem a poslat po https je levnější, než pak řešit, že konkurence dělá to samý.
- Bug trace apod. - podmínkou fungování je znalost uživatele (= přihlášení) a https je velice vhodná prevence před tím, aby si spolu zaměstnanci vyřizovali účty fingováním průšvihů jménem někoho jinýho...
- Kamerový systém atd. - pro soukromí zaměstnanců
- ... (nějak mě nenapadá, kde by https škodilo a kde by nebylo pojistkou proti zvědavým brigádníkům od konkurence)

Ad: Docházka
Ano, mozno tam je dochadzka. Ale co ked je system jednoduchy a napriklad reporty idu priamo do mzdoveho systemu a nikto si ich primo tu (v dochadzke) nepozera? Takze ziadne osobne data (okrem prideleneho cisla zamestnanca a toho co a kolko robil) tam nechodia (aj tieto len pri zadavani).
Akeze osobne data tam su, ktore treba chranit?

Ad: Zdrojáky, výrobní dokumentace, finanční plány,... Prostě firemní know-how.
Ako mi to pomoze, ak nejake data uniknu? To potom sa mam akoze rozhadat so vsetkymi zamestnancami, ktori tam mali pristup? Alebo mam do vsetkych dat davat nejaky odtlacok, podla ktoreho by som spoznal, ktory zo zamestnancov ich vyniesol? A ako sa dostanem napriklad k zdojakom konkurencie, aby som zistil, kto to vyniesol?

Nechcem sa zastavat dalej tych, ktori HTTPS nechcu. Ale takto sa da odpovedat na vela veci (a odpovedzte im). Naozaj na niektore veci je HTTPS (skoro) zbytocne.

Docházka přece dovoluje i editaci událostí, aspoň my jsme to tak měli (zadání dovolené,...). A není žádoucí, aby se kdokoliv mohl hrabat v docházce ostatních. Takže je to zralý na přihlašování uživatele.

Kdo se přihlašuje, obvykle potřebuje heslo. A protože jich v práci potřebuješ mraky (login do systému, IS, docházka, maily, IM,...), tak pro zjednodušení se na většině z toho používá přihlášení přes LDAP.

No a teď se kvůli blbé kontrole, kolik máš přesčasů, pošle tvoje LDAPko nešifrovaně. A kolega zrovna něco očuchává s WireSharkem.

A přes LDAP se dá dostat do IS, kde je "samoobsluha" pro nastaení kontaktních údajů, bankovního účtu,... (aspoň my jsme to tak měli). Takže ví, kde se mění číslo účtu, ví jak s přihlásit jako někdo jiný, ví kdy odejdou prachy a ví i kolik. Stačí jeden bílý kůň, dva dny před výplatou se přihlásit jako kolega, jak odejde výplata to vrátit zpátky a rychle vybrat hotovost... Nebo třeba jménem kolegy, co na firemní akci flirtoval s manželkou, napsat hezký mail.

S cizím LDAP loginem se dá ve firmě dělat hodně nepěkných věcí. Kapišto?

Firemne smernice, ktore ma poznat a dodrziavat kazdy zamestanec + kalendar dovoleniek - t.j. mena ludi s ktorymi sa stretavas kazdy den na chodbe + datum nepritomnosti.

Ked niekto vynesie firemne know-how, tak isto nie preto, lebo niekto z vnutra odpocul nesifrovanu komunikaciu po sieti.

Takze si zas kazdy browser implementuje co chce a serie sa na RFC?!

Opravte mě, jestli se mýlím, ale RFC vlastně neříká "musíš udělat A i B", ale "jestli chceš A a k tomu i B, udělej to tak a tak", ne?

Nekdy ti i rika, ze to musis udelat. Nechapu, ale cim Chrome nedodrzuje RFC.

Můžeš být konkrétnější? Číslo RFC a v čem ho nedodrželi? A číslo tiketu, ve kterým jsi je na to upozornil?

Nebo jenom tak breptáš, aby řeč nestála?

No ty v***. Dekuji Filipu Jirsakovi. Kdyz jsem to zacal cist, tak mi zacala varit krev, takze dekuji ze jsem nemusel vsem odepisovat jako on.

Na Web proste patri HTTPS! Tecka! Nerozumis tomu, neptej se a delej. Pokud ti situace nevyhovuje, prejdete ve firme na jiny prohlizec, kterej tyhle bezpecnostni rizika ignoruje. To je jako dnes nahravat konfiguracni soubory webu k pripojeni do DB pres FTP. Jedinou vyjimkou je snad localhost.

A na zaver, meli jste na to 2-3 roky (prvni predzvest prisla v roce 2015). Konkretne na tuto funkcnost google upozornoval letos v unoru. Takze, misto plakani na rootu, bezte nasazovat SSL certifikaty a prestante se vymlouvat. S let's encrypt mate certifikat do 20 minut i s nactenim manualu.

> S let's encrypt mate certifikat do 20 minut i s nactenim manualu.

A se soudním sporem v USA když jim unikne soukromý klíč! A to se vyplatí!

Porad lepsi reseni nez zadne. Tohle alibismus na urovni. "Protoze by sme se museli v pripade uniku soukromeho klice, (ktery se sice zatim nestal, ale co neni muze byt) soudit na pude USA, tak se radsi na cele HTTPS vysereme, protoze delat cele kolecko kolem klasickych certifikatu se nam nechce. Zustavame u HTTP!"

Navic za let's encrypt stoji certifikacni autorita jako kazda jina. Pokud jim unikne privatni klic, neni problem vygenerovat novy. A soudit se za neco co mam zdarma?

Kdo chce hleda zpusoby, kdo nechce hleda duvody.

Stejně jako u Stena nechápu, o čem mluvíš. Jde o situaci, kdy _tobě_ unikne soukromý klíč.

Přiznejte se na rovinu, četli jste Subscriber Agreement služby, kterou používáte a doporučujete?

Pokud nějaké certifikační autoritě posíláte svůj soukromý klíč, tak si ten soudní spor zasloužíte

Nechápu, jak to souvisí s tím, co jsem napsal. LE se samozřejmě žádný soukromý klíč neposílá.

Když to zjednoduším, tak se jedná o webové rozhraní k hardwaru. Jde o to, aby když si v kanceláři napojíte hardware k jednomu počítači, abyste si tam spustili příslušný software a ostatní uživatelé ve vaší kanceláři ten hardware mohli také ovládat (právě přes tu webovou konzoli).
Ten hardware se může libovolně přepojovat mezi počítačemi.
Žádná citlivá data tam opravdu neběhají. Naopak je žádoucí, aby instalace byla co nejjednodušší a nejrychlejší.

Hodilo by se nám HTTP2 - kvůli rychlejšímu vykreslování. Jak vyřešit tedy certifikáty - na lokálním počítači a intranetu?

Prosím odpovědi typu, že si mám nafackovat, si můžete nechat od cesty..

Díky. Ano, pokud bych byl u zákazníků adminem, tak bych to udělal, ale vzhledem k tomu, že zákazníci nemají často ani IT oddělení, tak mi to připadá nereálné.. Ale díky.

Uznavam ze v tomto pripade asi neni zadne rozumne reseni, nez self-signed certifikat na hostname a vlastni CA, coz muze byt celkem opruz rozjet(pokud vubec? neznam detaily, takze jen hadam).

Nechci nikoho urazit ale zeptat se musim. To to webove rozhrani mate opravdu tak zprasene ze potrebujete HTTP/2 na primem spoji? Nedovedu si predstavit jak nekdo muze na localhost spojeni potrebovat HTTP/2 kvuli rychlosti. Z meho omezeneho pohledu(jak jsem avizoval neznam detaily) jste vy/je autor pekne prase a nebo jste perfekcionisti, kteri chteji nacteni za 14ms misto aktualnich 16ms.

Nehledě na to, že jde o "sdílený zařízení, který se přepojuje mezi komply". Kdyby bylo v LAN, tak se nepřepojuje, ale jenom na něho lezou všichni. A vzhledem k rozšíření rozhraní bych to viděl na USB... Možná flash disk nebo něco takovýho. S přístupem přes mass storage. Tam ale není ani http://www.domena.tld/dokument.html, ani https://www.domena.tld/dokument.html, ale file:///run/me­dia/user/usbde­vice/dokument­.html. A to je zase jiná situace...

Nehledě na to, že na USB disku (zařízení) není člověk omezený na web, ale může si tam plesknout jakýkoliv soubor. Takže se zase vymýšlí kosočtvercoviny, jenom aby bylo https globální problém.

V uživatelském rozhraní je potřeba paralelně nahrávat velké množství obrázků (to zařízení je produkuje). Uživatel je chce všechny najednou vidět. Aby se mohly nahrávat opravdu zároveň, je HTTP2 mnohem lepší a uživatelský zážitek mnohem lepší.

No, toto by se dalo resit, ale to lakadlo v podobe HTTP2 je pochopitelne. Diky za osvetu

Zpráva dobrá, ale čeština trpí.

"Odteď jsou pro Chrome všechny HTTP stránky ne-bezpečné"
=>
"Odteď nejsou pro Chrome všechny HTTP stránky bezpečné"

To druhé dokážu chápat i jako „existuje alespoň jedna HTTP stránka, která pro Chrome není bezpečná“ a tedy se změnil význam.

ne-bezpečné? ne-zabezpečené!

Autor se snaží pomlčkou zdůraznit co tím myslí, ale dát tam "nezabezpečené" by ho asi nikdy nenapadlo :)

A přitom stačilo si ten Chrome pustit

Myslím, že pomlčku má na starosti dementní redakční systém.

EEE v praxi, za par let jen se souhlasem Google ..

Ehm... Ono je to asi zbytečné, ale pro funkční HTTPS je potřeba důvěryhodný certifikát. Nikde není řečeno, jak ten certifikát máš dostat. Vyrob si self-signed a pak ho v prohlížeči označ jako důvěryhodný. Žádný souhlas od kohokoliv na to nepotřebuješ.

Neboj, to ti guugl brzo taky zakaze - jak jinak nez z duvodu ze prece chce tvoji bezpecnost.

> Vyrob si self-signed a pak ho v prohlížeči označ jako důvěryhodný.

FYI v Chrome to tlačítko zrušili, je potřeba si certifikát nějak vytáhnout externě (good luck dostat to z browseru, ale můžete použít řádkové openssl) a následně naimportovat hluboko do nastavení.

"kdyz to tak dela microsoft^w google tak to tak musi byt spravne".

Takovy lidi proste nemaji mozek na to pochopit ze TOFU (nemluve o vlastnim overenem certifikatu!) je mnohem bezpecneji nez kompletne verit kdejake turecke nebo americke CA, ani netusi jako funguje SSL a CA.

Hrozne me tyhle "google" opicky bavili, kdyz na naky konferenci naka zenska co delala v google rekla ze maji jen jedno repo, tak opicky hned zacali prosazovat at zrusime vsechny git repositare a sloucime do jednoho, protoze to tak ma google :-D.

Jinými slovy do toho google pořád nekecá. PS. certifikát se dá vyrazit přímo z chromu - v adresním řádku Nezabezpečeno > certifikát > podrobnosti > export.

Já už se týdny nedostanu na hijackthis.de, protože se jim nelíbí moje hodiny. Ať žijou certifikáty. V podstatě asi nejbezpečnější je, když se nikdo nikam nedostane, pak je to 100% bezpečnost.

Autor webu odpovida najiteli webu za bezpeci informaci tam vystavenych. Pokud je cilem webu inzerce a reklama, nema smysl https VYNUCOVAT

Autor browseru muze citit odpovednost k uzivateli, a musi ctit a implementovat zamer majitele browseru.

Autor prispevku nema zadnou duveru v CA, tudiz tam, kde citi potrebu sifrovat, nevidi duvod k tomu pouzivat certifikaty dnestnich CA, navic menene ob 2 mesice. Rovnez tak pochybuje o skutecnych marketingovych a obchodnich cilech let's encrypt, takze jeji soucasnou formu a zpusob fungovani nebere jako argument.

Soukroma firma ma plne pravo a zodpovednost provozovat sve systemy v mezich legislativy dle svych predstav, ale mozna si k tomu musi take sama vyvinout a nasadit vhodne klientske i serverove prostredi.

Zbytek je zbytecny flame

Tu reklamu nekdo plati, plati za jeji zobrazovani. Pokud jde traffic pres http, kdokoliv ho po ceste muze zmenit a misto reklamy na produkt A treba dostane uzivatel reklamu na konkurencni produkt B. Pokud to inzerentovi nevadi ze plati za zobrazovani reklamy na konkurencni produkt je vse vporadku. Vitejte ve skutecnem svete kde nejsou skritci, jednorozci a elfove...

Zase další zbytečný problém. Nejvíc mě vadí, že dělají problémy i se self-signed a pípadně vlastní certifikační autoritou...

Nesouhlasim s tim ze je to problem. Problem je naopak HTTP, FTP, STMP, IMAP/POP3, Telnet a dalsi.

Souhlasim ale s tim ze by meli zjednodusit import self-signed certifikatu i vlastni autority treba pro pripady zminene vyse jako jsou interni informacni system nepristupne z vnejsi site. Na to by stacil jednoduchy import self-signed ceritifikatu, vetsi firmy by tam mrskli rovnou autoritu a je vystarano.

Problem nieje s HTTP, FTP, STMP, IMAP/POP3, Telnet a dalsimi. Problem moze byt max. s ich sposobom pouzivania. Tieto protokoly stale maju svoj vyznam a pouzitie.
Predsa nie vsade a vzdy potrebujem vsetko zabezpecene a skryte pred druhymi.
To je akoby si chcel nutit davat napriklad vsade bezpecnostne dvere. Davat ich na zahradu, kde mas par ovocnych stromov a preskocit plot nieje ziaden extra problem, je nezmysel.
Alebo ako by si chcel zakazat posielat pohladnice, ktore si moze kazdy precitat a aj pozmenit na nich text.
Pohladnice su zastarale ale co je na nich zle, ked jednu poslem z dovolenky alebo ako gratulaciu k vyrociu?

U pohledu mas nejaky rukopis, ktery muzes potvrdit nebo vyvratit. Pokud posles sefovi e-mail pres nesifrovane spojeni, muze tvemu sefovi dorazit treba zprava ze je totalni kkt a ze mu pichas jeho zenu a dceru a davas to na net.... Zneuzit se da vse.

protoze SSL fakt zabrani podvrhnuti odesilatele

Akorát zbytečně musíte u každé věci rozhodovat, jetstli má být šifrovaná nebo nemá.

Jestli ma byt sifrovana s pouzitim certifikatu, ktery muze vydat POUZE jedna z (ne)duveryhodnych CA (ktere si vybere google).

Na kampusu máme kvalitní dveře se sofistifikovanými bezpečnostními zámky. Vedle těch dveří je ovšem zeď, složená ze dvou vrstev papundeklu ("ani poctivý sádrokarton to není", komentoval jeden kolega situaci, kdy se mu to podařilo při stěhování nábytku po kanceláři prorazit nohou od židle) a mezi nimi je střídavě pěnový polystyrén a minerální vata. Když se proti takové zdi rozběhnu, tak si se svými 90 kily ani nevšimnu, kdy jsem jí prošel (pokud se náhodou netrefím do trubky nebo drátu).

Pro méně chápavé: "papundeklové" dveře, stojící něco mezi 1/5 a 1/10 těch bezpečnostních, by nijak bezpečnost nezhoršily.

Jasne soudruhu, az budes konfigurovat swuj swist za 1/2M+, nezapomen si nejdriv (telepaticky) naconfit nejaky ty "duveryhodny" certifikaty, protoze konfigurace po seriaku telnetem neni dost khull.

Stejne tak az budes neco takovyho po ftpku flashovat ...

Ono je totiz dycinky nejlepsejsi udelat ty veci co nejslozitejsi, aby se toho mohlo posrat co nejvic, a v tomhle pripadne s bonusem, ze ti po 1/2 rocne tvuj .... cokoli ... na tvym PC vynada, ze pouzitej algoritmus uz neni podporovanej, a nazdar bazar.

Me se libi, jak lide co jsou proti akorat vytrhavaji veci z kontextu a pouzivaji jako argument 1% situace, kdy se absolutne nejsou schopni zamyslet.

Takze aby me ti pomalejsi pochopili. Ty protokoly jsou bez SSL problem, pokud jsou na jakekoliv siti (vnitrni, vnejsi). Je asi jasne ze kdyz se fyzicky pripojuji pres seriak, tak asi sakra nepotrebuje ochranu proti MitM ... jakoze WTF to jste opravdu tak tupej? ... Dale pak kdyz uz jsem v tom zarizeni pres telnet bez SSL pomoci seriaku, tak uz tam kvuli tomu FTP mohu hodit certifikat, jestlize chcete pouzit FTP pres sit, pokud opet jen pres seriak, tak to OPET to neni treba.

Take jsem nerekl ze by ty protokoly meli vymizet. Rekl jsem ze jsou problem. Lidi si za 20 let zvykli absolutne neresit bezpecnost a v dnesni dobe kdy se nas snazi ovlivnovat media jak muzou, je problem i pitomej clanek na blogu Ladi Hrusky bez SSL.

Gratuluji ke skvělýmu rozhodnutí implementovat web server do něčeho s pár kilama RAM a pár desítkama kilo ROM bez crypto modulu, ale zato s 8b int aritmetikou a bez FPU/VPU. Ve kterým století že to rozhodnutí bylo učiněno?

V 21 století. 16 Mhz (zhruba 16 000 000 instrukcí za sekundu) na webový server i v roce bohatě 2018 stačí. Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví. Nakonec třeba za 10 let zjistí (AVR je dostatečně spolehlivý na to aby dokázal fungovat více než 10 let), že jeho vlastnoruční implementace HTTP(S) je už z principu bezpečnější než implementace pomocí crypto modulů vašeho procesoru ve kterých se tou dobou objeví nějaká bezpečnostní díra o které třeba nikdo zatím neví. Byť to samozřejmě není zrovna efektivní.

Jednoduché a přímočaré čipy budou mít vždy svoje místo, ať je libovolné století.

// P.S. pár kil RAM je luxus, dodnes se vyrábějí a vydávají AVR se stovkami nebo i desítkami bajtů RAM. Třeba nové ATtiny204

"16 Mhz (zhruba 16 000 000 instrukcí za sekundu) na webový server i v roce bohatě 2018 stačí."

Motor ze sekačky na trávu taky stačí na to, aby utáhl auto. Že to auto bude muset mít kastli z balzy a cestující půjdou vedle auta, nebude tam topení a startovat budeš taháním za špagát je přece detail.

První věc, 16MHz != 16MIPS, ale v reálu uvažuj tak 12 MIPS. Nemá to díky jednoduchosti predikci skoků a zahazuje tak pipeline.

"Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví."

Další výborná vlastnost je to, že je to Harvard, tj. instrukční sběrnice (16b) oddělená od datové sběrnice (8b). Jakýkoliv výstup na LAN (nebo displej, sériovku,...), pokud je složený z konstantních dat a proměnných, tak máš dvě možnosti. Buďto výstupní funkci mít 2x (SendFromRam(), SendFromFlash() ), nebo bufferovat komplet data v RAMce. Kolik že jí má? Max. 16kB? Good luck.

Vem si, že MTU je na Ethernetu 1500B. + hlavičky + režie ve stacku (stavový proměnný,...). Pokud budeš chtít pro jedno spojení mít buffer na dva pakety pro každý směr, pod 6kB RAM se nedostaneš. K tomu povinný protokoly jako ICMP, DHCP,... Počítej tak minimálně 4kB RAM na IP adresu, MAC aderesu, parsovaný data requestu. Pro připojení jednoho klienta, konfiguraci atd. Dva sokety nedáš, kdyby ses na ptáka stavěl. Resp. dáš, 4+2*6=16kB, akorát jaksi nebudeš míst stack. Blbý, co? A to je zatím jenom HTTP.

Pak je tady šifrování. Základem jsou operace sčítání, násobení, modulo a lookup tabulky. U sšítání s prací po bytech by to asi nějak šlo. Násobení, tam už jde výkon exponenciálně dolů (8bx8b=16b, 4x operace násobení + 4x sčítání; 16bx16b=32b, 16x násobení + 16x sčítání,...). To platí i pro modulo. Tabulky nedáš do RAMky ani do FLASH

"Navíc tento jednoduchý a přímočarý čip není náchylný na chyby typu meltdown, specter a obdobné chyby, které se v komplexních procesorech ještě objeví."

Ne, tam jsou totiž úplně jiný chyby, ale o těch se moc nepíše... Meltdown ani Spectre by mě v takové aplikaci opravdu asi netrápilo, ani kdyby byly HW dispozice, protože tam stejně není MPU, MMU, cache a další blbiny, tak bych si pro to mohl sáhnout přímo.

"Nakonec třeba za 10 let zjistí (AVR je dostatečně spolehlivý na to aby dokázal fungovat více než 10 let), že jeho vlastnoruční implementace HTTP(S) je už z principu bezpečnější než implementace pomocí crypto modulů vašeho procesoru ve kterých se tou dobou objeví nějaká bezpečnostní díra o které třeba nikdo zatím neví."

Security by obscurity? A kdo zajistí, že to nebude naopak? Navrhnout to na první dobrou líp, než u Linuxu s desítkama let vývoje a stovkama párů očí je opravdu majstrštyk. Až to uvidím, uvěřím.

"Jednoduché a přímočaré čipy budou mít vždy svoje místo, ať je libovolné století."

Jistě, ale ten si můžu dovolit třeba na generování PWM v LED svítidle, nebo časový relé nastavený poťákem, ... Nemůžu designovat na něčem, kde už dneska musím dělat brutální kompromisy a optimalizace na hranici možnýho a pak počítat, že za 10 let to ještě bude vyhovovat.

Nekdy neni duvodem jednoduchosti omezenost vyvojare, ale omezene pozadavky. Napriklad spotreba v radech pikoamper max jednotky miliamper. Jednoduchost ladeni, potreba nizke intregrace(napr kvuli radiaci), nizky teplotni sum a tim padem nizsi naklady na izolaci/chlazeni kvuli presnosti mereni, levne nahradni dily, predikovatelnost chovani na urovni signalu.
Mezi soft kriteria muze patrit i treba zkusenost vyvojoveho tymu, overena konstrukce daneho modulu a funkcni dodavatelsky retezec.

Ja uz jsem starej. Oficialne studovanej nejsem, ruzovou kosili nenosim, teplej nejsem, do posilovny nechodim,nage­lovanej nechodum a na tzv. "startup meetingy" v nasi firme se koukam s despektem ( i presto ze jeden neco jako startup vedu ale to je jina story... ). Cili jak vidite ze nejsem zcela kvalifikovan se v teto oblasti vyjadrovat takze berte me vyjadreni s rezervou.

Nicmene...

Nicmene obvykly setup je ze mam hloupy podrazeny system ktery splnuje me naroky na omezeni dana zdroji/prostredim a nad to napojim treba pres UART/RS485/CAN/­SPI... nebo jine rozhrani nejakou inteligentnejsi krabici ktera v pohode da TCP/IP i s SSH/HTTPS .
Hierarchie systemu dle slozitosti...

Pripadne si k tomu dokoupim terminal koncentrator ktery to s vice skatulemi udela za mne.

Pripadne si k tem hloupym HTTP vecem poridim nejaky VPN koncentrator ktery mi to cestu zabezpeci.

Tak jasně, má právo dělat předpověď počasí na měsíc dopředu na jednom Am80386SX/33MHz, ale pak se nesmí divit, že tu předpověď dostane 10 let po konci období, na který ji dělá. Stejně tak má právo řezat dřevo na zimu pilníkem, zatloukat hřebíky skleněným těžítkem, dát si na kovadlinu gumovou podložku, nechat si ho vykouřit od hladové kanibalky,... Blbosti se meze nekladou.

Ostatní zase mají právo jeho snahu ocenit smíchem.

"Nejste trosku padli na hlavu, jeste monopolu takhle tleskat za jednostranny rozhodnuti?"

Ne, není to o monopolu. Pořád je mezi prohlížeči volba.

A pokud jde o jednostranný rozhodnutí, pokud se komerční firma rozhodne upravit nějak část jejich programu, kterou neupravuje žádný standard, tak je to jejich právo a je za zákazníkovi, jestli to bude používat. O úpravách komerčního SW se hlasuje peněženkou.

Btw, rád bych viděl aktuálně platný RFC pro podobu adresního řádku prohlížeče v GUI...

Ano, protoze toto upozorneni jsem si v chrome://flags zapl uz v roce 2015. Moje API jedou pres HTTPS + Auth hlavicka -> Base64(Autorizacni kod + HOTP kod) + domain spoofing.

Tor pouzivam jen omezene.

Ted uz jsem zapl finalni podobu kde Not secured sviti cervene s vykricnikem.

Resite kraviny a pritom jde jen o blby text v URL = uzivatel vaseho SW je informovan ze jste ignorati, ale aplikaci muze nadale pouzivat.

"monopolu takhle tleskat za jednostranny rozhodnuti"
Ze jste nenadaval na Google ze si vubec v Chrome dovoli pouzivat HTTP, ja jsem treba chtel zobrazovat stranky pres postovni holuby, ale ten velky zly google, ktery z nasazeni HTTPS nema absolutne nic protoze ani nevlastni certifikacni autoritu se proto rozhodl a ja utrel.

Tvůrci informačních systémů úplně zapomínají na MaR. Mohou existovat např. embedded zařízení na HVAC LAN. Ne všude je možné dostat HTTPS server a pravidelně generovat nové certifikáty. Nemusí tam být přístup ani na web, neexistuje doménové jméno atd. Ne všechno je na netu. Ale internetový prohlížeč si bude stále stěžovat a časem možná zahodí podporu HTTP úplně.

A proc ne? Vzdyt monitoring delaji hloupi uzivatele(vratnej, bydlenka s detma doma, lojza prazak ze zizkova...). I na spoustu prumyslovych aplikaci to staci jako zalozni pristup vedle tlusteho pro nejakou SCADA centralu. Proc by mel user instalovat nejakyho dementniho tlustyho platformne zavislyho klienta na to aby zjistil ze kotel nema tlak a ktery cislo chyby+konfigurace kotle rict technikovi aby vzal nahradni dil ? Nebo ze prijede o trochu driv a tak poupravi vytapeci schema ci nastaveni mistnosti. Proc resit HTTPS ve sve duveryhodne siti kterou mam plne pod kontrolou nebo kdyz potrebuji diagnostiku? Kdyz tam se mi nekdo napichne tak mam mnohem vetsi pruser.

Tohle se do jisté míry vztahuje k tomu, co jsem napsal výše: Pokud bude net bydlenek s dětma a Lojzů pražáků ze Žižkova oddělený a bude se všeobecně vědět, že na něm nejsou žádné bankovní a jiné choulostivé weby, tak bude také silně neatraktivní pro kohokoli, kdo by se do něj chtěl vloupat. Hackeři, co se do sítí vloupávali ze sportu, už buď vymřeli nebo zmoudřeli a ti zbývající vám to dělat nebudou, když z toho nebude prakticky žádný zisk.

No ITak napichnuty ke statni sprave s ultimativni moznosti skodit to taky koukam nema jednoduchy...

Duveryhodnou sit jsem myslel vazne. Jde o to zda-li je mira zabezpeceni a asociovana udrzba adekvatni aplikaci. Ono jde o tom jak clovek nastavi cely system.
Nikdo nerika ze ten kotel se pripoji primo do internetu idealne s verejnym odkazem na facebooku aby mel shodan mene prace... Samozrejmosti je pripojeni dratem+ pokud chci z venci pristup tak VPN koncentrator+fi­rewall a idealne vyhrazena VLAN. Tj. to co ma kdejaky lepsi domaci routerkrap te bydlenky nebo toho lojzy.

A pokud jsem paranoidni tak pouziju stineny kabel,hlidani naruseni/zkratu zil (umi uz dnes kdejaky PHY interface) nebo optiku kde je napichnuti neni nemozne lec slozitejsi.

Proč nejde ta "HVAC LAN" nasadit za https proxy? Aha, HVAC v ceně dvou nových bavoráků a router za 300 z Kauflandu... Komu není rady...

Jde. Ale to by nekdo musel umet cist neb to je uvedeno vyse. Nemuzes tahat TCP/IP az nekam ke stykaci nebo k na rameno jerabu presovajiciho palivove tyce.. A porad to jde tezko primo k nejakemu PLC. Ale je jasne ze nad tim udelas nejakou takovou proxy.
Nicmene nezapomen na to ze ti ji porad musi nekdo spravovat, updatovat tls/ssl stack (tim spis pokud je tam u jeje bejby openssl), updatovat certifikaty, menit nastaveni sifrovani...

Pokud budes potrebovat neco opravit za tou proxy jak to opravis kdyz te prohlizec posle do kopru? I presto ze mas jistotu ze cesta je bezpecna? Fakt bych chtel vedet jak nekdo vleze do bunkru ministerstva obrany a mezi serverama v racku tam bude poslouchat http komunikaci nebo zacne uvnitr natlakovanyho plynovodu cachrovat s optickym kabelem...
To je fakt problem kterej na te urovni podpory resit nebudes a nechces. Nehlede na to ze nektere podniky / statni instituce typicky duveruji jen svym internim certifikacnim autoritam takze k tomu mas dalsi administrativni opruz.

Nerikam ze se to nehodi - sam mam https kde to jde a nema to jine neblahe dusledky, jen, rikam ze direktivni narizeni neceho vsem je spatne.

Sorry, já nevěděl, že u proxiny musí 24/7 sedět chlápek, co se co 10 minut připojí po SSH, napíše "update" a zmáčkne Enter. A mezi tím bude 3x denně měnit šifrovací protokol a 5x denně klíče.

Klíče od LE se mění samy a neplatiš za ně (zázrak!). Protokol má nějaký životní cyklus a typicky je to třeba 10 let bezpečný, pak se oznámí, že bezpečný není, ale vzhledem k update cyklům SW se to začne řešit za rok a dřív jak za tři roky to nikdo nevyhodí. Bepečnostní update stačí (v případě možnosti lokálního ovládání) 1x týdně a pokud tam je závislost, tak při servisní odstávce.

A pokud je nejhůř a potřebuješ se píchnout kabelem za proxinu, jsi fyzicky na místě toho stroje. Co ti brání dojít k němu a pořešit to lokálně na jeho ovládacím terminálu?

Je takove reseni s minimalni obsluhou na cca 15-30 let? Tj do dalsi rekonstrukce? Nebot takova je zhruba zivotnost TZB kterym se ta proxyna automaticky taky stava.

Udrzba je cca 1x do roka pri navsteve na cisteni/revizi. Casto je bez plneho pripojeni k internetu.
Realne management se na to vykasle 10 let a poveri tondu cistenim. Pak se bude divit proc ma "proxynu" napadenou... Mezitim vyrobek ani firma uz existovat nebudou.

A s tim chlapkem 24/7 mas v podstate pravdu.
Musi tam byt aspon dohled(pokud je mozny a neni to uzavrena sit) a zarucena vymena dilu. Protoze to dodavas jako reseni a ne jako "lojza z budky s business planem trhni a zdrhni".

LE a navazana reseni nemusi byt z hlediska firmy poskytujici udrzbu duveryhodna takze si to musi oskriptovat sami. Jak vis ze LE bude existovat za 20 let?

Fyzicky uz se nikam nepichnu, protoze v te dobe chromajzl a mozna i dalsi prohlizece nebudou umet HTTP vubec. Takze budu muset drzet nejakou historickou obludu. O tom to je. Takze mi zas zbyde tam pripojit seriovy kabel...

> Fakt bych chtel vedet jak nekdo vleze do bunkru ministerstva obrany a mezi serverama v racku tam bude poslouchat http komunikaci nebo zacne uvnitr natlakovanyho plynovodu cachrovat s optickym kabelem...

A tohle jsou typické scénáře, ve kterých se hodí používat běžný webový prohlížeč určený pro prohlížení Roota, ebankingu, Alzy a Fejsbůku.

// wtf. Tahle diskuze není o tom, že by ti někdo zakazoval používat HTTP. Prostě stejně jako dneska máš SSH pro správu velkých a bezpečných serverů a telnet pro totéž u věcí co nic jiného neumí, tak budeš mít browser pro web a jiný program pro plynovody.

1. Testovani prohlizecem je uplne bezne. Tim spis pokud potrebuju odladit problem pred SSL/TLS boxem nebo balancerem. Holt aby browser mohl vubec technik pouzivat bude si ho muset v budoucnu predtim poradne ohackovat:(

2. Ta diskuse JE o tom ze by mi v budoucnu nekdo direktivne bez znalosti prostredi zakazoval pouzivat HTTP k cemuz to touto politikou speje. Tez to ze lezu pres HTTP neznamena nutne ze kazde spojeni je ne-zabezpecene. Jen ze je s nejvetsi pravdepodobnosti neni zabezpeceno na spojeni z prohlizece. Kde ale bere prohlizec odvahu hodnotit zabezpeceni meho prostredi?

HTTP uplne zakaze chrome,zakaze firefox,zakaze mrkev a pak uz mi zbyde jen ohackovat si to do doby kdy to pujde. To neni boj za bezpecnost. To je boj proti uzivatelum.

Je zvlastni ze my dva zrejme z pribuzneho oboru zde dostavame prevazne palce dolu... Mozna to o necem svedci.

Pak tu mame HTTP Public Key Pinning, co je zase navrh z Googlu, aneb pokracujeme na vlne nekritickyho tleskani, juchu.

To už odpískali, klid...

Problém není to, kde se šifruje nebo ne.

Problém je v tom, že:
- Původně se ke konfiguraci používal Telnet.
- Jenomže se rozšiřovat internet a CLI bylo pro lamy složitý, tak se zneužilo HTTP a udělala se klikací web stránka.
- Pak se zjistilo, že Telnet je nezabezpečený a přešlo se 1:1 na SSH, přibylo jenom generování klíče.
- Pak se přišlo na to, že HTTP se taky nezabezpečený a přišlo HTTPS.
- Jenomže na rozdíl od SSH, kde dával přístup do uzavřenýho systému admin a nebyl pro něho všechno nastavit, pomocí HTTPS se musela dostat k datoům veřejnost bez toho, aby správce generoval každýmu klíč, tak se vymyslela hierarchie klíčů a CA.
- A teď se zjistilo, že v neveřejné síti jsou veřejný CA nepoužitelný.

Řešení není vynucovat podporu nebezpečnýho protokolu, ani cpát za každou cenu HTTPS do krabiček, ale zapracovat na "secure management protokolu", který vyplní mezeru mezi SSH a HTTPS (= interaktivní nastavování + šifrování + omezení přístupu).

Jestli to chapu dobre tak mate na mysli neco jako HTTP via SSH?