Jedna viditelná novinka přišla s Chrome 68 a nezmínili jsme ji. Od verze 68 už Chrome označuje všechny HTTP stránky za „Not secure“. Google tak víceméně završuje další důležitý milník poslední roky běžících snah za vymýcení ne-HTTPS spojení, což je pochopitelné: na webu už dávno nečteme jen holý text, ale také nakupujeme, nahráváme citlivé osobní informace (což je tedy trochu ošemetné, když třeba takový Facebook běží přes HTTPS už nějakou dobu).
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.
Taky, ale Martin ma taky pravdu :-) Treba v kombinaci Windows Server 2008 R2 + IE 11 to mam vyzkousene... Zobrazi se okno "Security Alert" a hlaska "You are about to view pages over a secure connection. Any information you exchange with this site cannot be viewed by anyone else on the web." A zaskrtavatko "In the future, do not show this warning" :-)
Je to jak píše Martin, ověřeno na virtuálu s Windows98 a IE5.00.2614.3500
Okno Výstraha zabezpečení:
Hodláte zobrazit stránky zabezpečeným připojením.
Veškeré informace, které si s tímto serverem vyměníte,
nebude moci zobrazit nikdo v síti WWW.
Toto upozornění již příště nezobrazovat
OK / Další informace
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)?
V intranetu certifikát smysl dává. Nejlepší řešení je nijak to neobcházet a používat všude HTTPS. Nejlépe normálně na veřejných doménách, pak nemusíte nic řešit. A nebo pokud už máte nějakou interní certifikační autoritu a nechce se vám to měnit, použijte tu.
Snad v každé diskusi o HTTPS někdo vysvětluje, že nejde jen o důvěrná data. To jste na takovou diskusi ještě nenarazil? Když se díváte na nějakou webovou stránku, tak asi proto, že chcete vidět informace, které tam vložil provozovatel toho webu. Když použijete HTTP, může informace cestou někdo změnit.
Proč to teda čtete? Nebylo by levnější odpojit se od internetu a číst si v /dev/random?
To je pořád dokola jak u j na dvorečku - m.j. aby ti někdo do té stránky nepřidával svoje věci. Reklamy, malware, captive portal...
"Nevím, proč musejí být složitě šifrované třeba recenze linuxových programů tady na rootovi."
- Administrační rozhraní CMS (nebudou přece složitě dělat dva servery - jeden šifrovaný pro správu a druhý nešifrovaný pro návštěvy, když na to stačí jeden šifrovaný)
- Diskuse s možností přihlášení = předání loginu a možnost únosu session = nutnost šifrování. Howg.
- S šifrováním není možný podstrčit něco do stránky cestou, takže do ukázkovýho skriptu ti někdo nedodá nějakou kulišárnu.
- U HTTP má kdokoliv cestou (ISPík,...) možnost změnit obsah a zobrazovat svou reklamu. Ta, ze které je server placený, se pak ani nestahuje, ani nezobrazuje. S HTTPS je zajištěno, že reklamu blokne maximálně čtenář.
Než si přidávat práci s dělením na nepřihlášenýho uživatele / zbytek, držet dva servery s rozdílem jenom v šifrování a extra přihlačovací stránku (nenůžeš ji nabídnout přímo ve stránce na http, protože nesmíš poslat login nešifrovaně), je lepší to plesknout na jeden server, který jede šifrovaně kdykoliv a výrazně se ti tak zjednoduší logika a ještě předejdeš podvržení reklam nebo zásahu do textu.
A.S. Pergill, 7:47: Všechny stránky, na které chodím, protokol HTTPS prostě potřebují. Chodím na ně proto, abych si přečetl, co na stránkách zveřejnil autor, ne co někdo po cestě změnil. Navíc na šifrování není vůbec nic složitého.
Ano, napsal jste to naprosto přesně. A pokud jste náhodou napsal něco jiného, tak už teď víte, proč je potřeba šifrovat i obyčejné diskuse tady na Rootovi. Protože komunikační kanál, který přenese něco jiného, než do něj bylo posláno, je k ničemu.
Kolik takových podvržení obsahu jste reálně viděl?
Obávám se, že daleko větším problémem internetu jsou státní mocí (v tomto kontextu míním i úroveň EU) vnucované vystavování neomarxistických blábolů na zpravodajských (a i jiných) serverech a cenzura pravdivých informací. A vůči tomu nám šifrování nijak nepomůže.
Je jasné, že e-bankovnictví a pár dalších oblastí, kde se pracuje se skutečně citlivými údaji, šifrování potřebují. Je ovšem otázka, zda protokol https zajišťuje postačující úroveň zabezpečení, IMHO spíš ne a organizátoři těchto aktivit se zpravidla zajišťují prostředky na internetu a https protokolu nezávislými.
Zcela globálně: Problém vidím v tom, že se na internet navázala řada služeb a dalších aktivit, s nimiž původní koncepce vůbec nepočítala (pamatuji doby, kdy to byla prakticky výlučně akademická záležitost) a kvůli nimž je nutno tuto původní koncepci silně křivit. Je otázka, zda by tyto aktivity neměly být spíš z internetu vykopnuty, aby si zafinancovaly vlastní a zcela separátní síť, přizpůsobenou jejich potřebám.
A proc ty prvky mate zapnute kdyz Vas do ted nikdo nehackl, proc by to mohl udelat v budoucnu? Jenom Vam to brzdi pocitac pripojeni apod.
Naraza na Vasi logiku "Jeste jsem nevidel ze by nekdo menil text na webu kvuli nepouziti HTTPS, takze se to ani v budoucnu stat nebude a ted ani nikdy predtim se to nedelo"
Kolik takových podvržení obsahu jste reálně viděl?
Spoustu. Třeba každý captive portál.
Svata prostoto! 5 let? To plati mozna o pocitacich, ale pres browser je dnes pristupne kde co. Vcetne dohledu stroju za desitky a stovky mega. Co tam s tim, kdyz se bezne provozuji 20 a vice let? To ten stoj nechate kazdych X let predelat, vymenit mu rizeni? Nebo se vratite do dob, kdy kazdy takovy HW mel ovladaci SW fungujici zpravidla v jedine verzi Woken?
Bezpecnost takoveho stroje lze resit napriklad tim, ze neni nikam pripojen a pripoji se k nemu az servisni technik.
Proč je nutné stroj za desítky a stovky mega spravovat stejným webovým prohlížečem, který dotyčný uživatel používá k běžné práci a zábavě? Opravdu vám připadá jako nejlepší nápad, aby se ten stroj spravoval tak, že si někdo otevře v prohlížeči Facebook, Youtube, banku, e-shop, Root a na další záložce bude spravovat ten stroj? Opravdu se v té ceně desítek a stovek mega nenajde pár tisíc na vyřešení ovládání toho stroje – třeba LTS verzi prohlížeče?
Jinak je hezké, že vám vadí ovládací SW ke stroji, který vyžaduje jedinou verzi Windows – tak byste kvůli tomu zmrazil na jediné verzi prohlížeče celý svět.
Tieto dokola opakovane "argumenty" o stomilionovych masinach co musia vydrzat desatrocia su uplne scestne.
Ak mam taky stroj a naozaj ho potrebujem pripojit na net, tak ho predsa hodim za firewall (ak treba, tak aj na oddeleny sietovy segment) a ten stroj bude dostupny len z jedineho reverzneho proxy servera (na ktory sa da pripojit len cez https, prihlasenie je zabezpecene podla potreby napriklad heslom, atd). A ten reverzny proxy nie je problem priebezne udrzovat na aktualnej urovni bezpecnosti (ziaden vendor lock-in, ako v pripade toho priemyselneho stroja). Ked sa tu hadze stovkami mega a dvadsiatimi rokmi, tak to predsa financne nebude problem.
To vam reknu uplne presne. Ta krabicka vyjde na cca 50 tis a ani za ty penize nesplnuje nase pozadavky. Konkretne zapnout pri -50°C. Je prakticky nemozne najit vyrobce, ktery zaruci funkci pod -40. Dokonce i samotne soucastky jsou problem.
Pridejte k tomu zivotnostni testy, zejmena vibrace a az uvidite vyskakovat soucastky z plosnaku on vas prejde humor s "nejakou" deskou s WRT.
Buďte rád, že jste toho výrobce nesehnal. Shánět lidi, kteří budou v -50 °C pracovat s webovým prohlížečem, by bylo ještě mnohem obtížnější. Ve skutečnosti ale ti lidé budou někde v teple, a ten proxy server tam mlže být s nimi.
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?
Nikde, ale
- můžu LDAP username + heslo použít i na intranetu, to už jsem viděl několikrát.
- uživatel často použije stejný heslo v práci i v případě, že to není natvrdo svázaný
- pokud ten intranet pojede na http místo https, pojede přihlášení tím webem a browserem uživatele nešifrovaně v plain textu.
- podívat se do komunikace v plain textu je úkol pomalu pod úrovní script kiddies.
Takže (LDAP | login) na intranetu + HTTP = potenciální únik hesel k doméně. A je při tom úplně šumák, že si přihlášený uživatel čte veřejný dokument, dostupný na oficiálním webu firmy...
Akeze osobne data tam su, ktore treba chranit?
Ta, která jste napsal – osobní číslo, příchody, odchody… A když komunikace není šifrovaná, neznamená to jenom možnost odposlechu, ale také možnost změny.
Ako mi to pomoze, ak nejake data uniknu?
Není trochu rozdíl, jestli to vynese konkrétní zaměstnanec, nebo jestli to prostě odposlechne někdo z venku? A když komunikace není šifrovaná, neznamená to jenom možnost odposlechu, ale také možnost změny.
Naozaj na niektore veci je HTTPS (skoro) zbytocne.
HTTPS je zbytečné na zbytečné věci. Ale pak je možné ten server klidně vypnout a nic se nestane, takže HTTP potřeba není. Navíc pořád platí, že největší bezpečnostní riziko pro HTTPS je podpora HTTP v klientech.
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.
Ne. Nebo vy snad znáte nějaké RFC, které by říkalo, že prohlížeč musí implementovat HTTP/2 bez šifrování?
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.
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.
> když jim unikne soukromý klíč
> Jde o situaci, kdy _tobě_ unikne soukromý klíč.
Tak se rozhodnete, me nebo jim? Podle toho muzeme dale pokracovat v teto absolutne bezvyznamne debate.
Cilem meho puvodniho prispevku bylo to ze maji HTTPS nasadit. A pokud to neberou tak vazne jak se tvari tak by jim LE mohlo stacit. Navic je zadarmo a muzu si nechat vygenerovat soukromy klic novy, navic se stejne musi delat renew kazdych 90 dnu. Tak co tu sakra jeste resime. Google to rekl dostatecne dopredu, vsichni co se aktualne probudili jsou ignoranti a SSL si meli zaridit jak chteli. O cem je potreba se dal bavit a vymlouvat se?
"jim" odkazovalo na firmu, ke které jste mluvil v příspěvku z 8:21. Uznávám, že to mohlo být matoucí, takže ještě jednou pro vyjasnění: Pepa si pro svou stránku udělá LE, unikne mu klíč, a každý teď na něj má legální kladivo (bod 3.10.iii podmínek LE).
> Tak co tu sakra jeste resime.
Já jsem chtěl jenom podotknout, že současný systém CA má nějaké chyby, o kterých se moc neví (například proto, že si lidé nepřečtou právní podmínky CA, kterou používají, nebo proto, že si něco prostě neuvědomí (mě třeba trápí, že provozovatel CA nebo správce povinného Certificate Transparency logu se můžou snadno stát cenzory)).
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..
Jak vyřešit tedy certifikáty - na lokálním počítači a intranetu?
Používat doménové názvy z veřejných domén (ty samotné názvy nemusí být veřejné) a používat normální certifikáty od důvěryhodných certifikačních autorit, například Let's Encrypt. Používám ověřování přes DNS, takže ve veřejném DNS je pouze příslušný ověřovací TXT záznam a ve vnitřním DNS je pak i A záznam vedoucí na dané zařízení. Obnovu certifikátů řeším na centrálním počítači. Pro tyhle případy používám stálý privátní klíč pro zařízení, takže ten centrální systém na vydávání následných certifikátů nemá privátní klíče jednotlivých zařízení, ale jenom jejich CSR, zařídí obnovu certifikátu a ten pak vystaví. Zařízení, které certifikát potřebuje, si ho pak jenom může stáhnout (takže ani není potřeba přístup do administrace toho zařízení z centrálního serveru). Samozřejmě se to dá udělat i tak, že si ono zařízení bude generovat CSR třeba každý měsíc a předávat ho na centrální server – akorát je pak potřeba ošetřit synchronizaci mezi tím zařízením a centrálním serverem (aby se nepopletlo, ke ketrému privátnímu klíči patří který certifikát).
Chápu, že někde to třeba znamená i zásah do architektury řešení, třeba přidat podporu pro ACME. A třeba se bude od domácích routerů vyžadovat, aby uměly zprostředkovat vystavení certifikátů pro zařízení v síti. Ostatně prohlížeče pořád HTTP podporují a není žádný termín pro ukončení podpory, takže teď je doba na to, aby se tahle podpůrná řešení vyvíjela a nasazovala. Ale nemůžeme zůstávat u problémového HTTP jenom proto, že s jeho nedostatky v některých případech počítáme.
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/media/user/usbdevice/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.
> 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í.
Myslim Jendo, ze je to marny, jim neco vysvetlovat. Proste Gugl je nejlepsi, jak to pekne resi s tim zabezpecenim, jasny?
V nasem Docker setupu mame uz preci Lets Encrypt nalepene, tak pohoda, zatleskame Guglu a cekame na dalsi naval dobra!
Hlavne abychom si mohli za co nejkratsi dobu potlapkat po zadech, jak jsme ty strasne slozity veci zvladli za kratko a jak to krasne rychle bootuje!
A ani to nebolelo! (cti: nikde na zadnym kroku nebylo potreba myslet, stacilo konat)
Zarna budoucnost Internetu s takovouhle hipparty na, ehm, “popredi vyvoje”.
"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.
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...
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?
Tak jinak. Kdyz prijde sefovi email ze je kkt, muzes skontrolovat odesilatele (ip, pocitac v lokalni siti treba). U spoofnuteho emailu budes minimalne vedet ze pochazi z jineho pocitace (pokud ti ho nehackne kolega). U emailu pres http bude odesilatel sedet, akorat obsah bude jiny.
Predsa nie vsade a vzdy potrebujem vsetko zabezpecene a skryte pred druhymi.
Akorát zbytečně musíte u každé věci rozhodovat, jetstli má být šifrovaná nebo nemá.
A pak je tu ještě jedna důležitější věc – pokud příslušný klient podporuje i nešifrovanou variantu protokolu, je nejjednodušší vektor na ty šifrované protokoly právě downgrade protokolu na nešifrovanou verzi.
To je akoby si chcel nutit davat napriklad vsade bezpecnostne dvere.
To není moc dobrý příklad. Za prvé by ty bezpečnostní dveře musely být jen asi tak o korunu dražší, než papundeklové dveře. A hlavně tam chybí ten aspekt, že vaše použití papundeklových dveří by znamenalo, že jakékoli bezpečnostní dveře by bylo nejsnazší obejít tak, že by útočník místo nich vsadil dveře obyčejné a přesvědčil by příchozí, že ty dveře vedou na t osprávné místo.
Pohladnice su zastarale ale co je na nich zle, ked jednu poslem z dovolenky alebo ako gratulaciu k vyrociu?
To, že pošta podporuje pohlednice, nemá za následek, že by bylo možné stopit dopis a poslat místo něj pohlednici.
Nesmysl. Certifikát si můžete vybrat, jaký chcete. Stejně tak si můžete jako uživatel prohlížeče vybrat, jakým certifikačním autoritám budete důvěřovat. Google ten předvolený seznam naplňuje akorát pro ChromeOS a pro Android. Google Chrome používá systémové úložiště certifikátů, takže na Windows, MacOS nebo na Linuxu o tom Google nerozhoduje vůbec nijak.
> Nesmysl. Certifikát si můžete vybrat, jaký chcete. Stejně tak si můžete jako uživatel prohlížeče vybrat, jakým certifikačním autoritám budete důvěřovat
Nesmysl. Jak pises to funguje mozna teoreticky, praxe je sakra jina, protoze tvoje (no tvoje ocividne ne) sluzby pouzivaj i jiny uzivatele nez ty sam.
„A klidně z druhé strany“ je jiný způsob, jak říci „poprvé jsem si vymyslel něco, co nebyla pravda, tak teď zkusím něco úplně jiného“?
Svázání jedné domény s konkrétním certifikátem v prohlížeči Chrome neumí a nejspíš nikdy umět nebude. Svět webových prohlížečů se orientuje na důvěryhodné certifikační autority, takže je normální, že pro jeden doménový název prohlížeč během krátké doby potká několik různých certifikátů. Protože certifikáty mohou mít krátkou platnost, protože server nemusí být jeden ale může to být cluster nebo cloud, kde má každé zařízení svůj vlastní certifikát. Důvod, proč se web orientuje na důvěryhodné certifikační autority, je ten, že většina uživatelů certifikátům nerozumí a neví, jak je mají ověřit.
Můžete namítnout, že vy to víte – Chrome je ale prohlížeč pro většinu uživatelů, takže nebude implementovat funkce pro pár uživatelů, které by navíc snižovaly bezpečnost té většiny.
Tolik z pohledu uživatele. Na straně správce webového serveru se naopak předpokládá někdo, kdo problematice rozumí. Tam máte několik možností, jak specifikovat důvěryhodné certifikáty. Můžete použít CAA záznam, kterým určíte, která certifikační autorita může certifikát pro vaší doménu vydat. Dále můžete kontrolovat seznam Certificate Transparency a můžete posílat prohlížeči zprávu, že certifikát má být na seznamu CT.
> Svázání jedné domény s konkrétním certifikátem v prohlížeči Chrome neumí a nejspíš nikdy umět nebude. Svět webových prohlížečů se orientuje na důvěryhodné certifikační autority, takže je normální, že pro jeden doménový název prohlížeč během krátké doby potká několik různých certifikátů
goto "
> 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).
"
Dal nezajem se s tebou bavit. Mimochodem, taky jsem vsude nasadil LE, priradil domeny k IPeckam, ktery ani domenu nepotrebujou apod., takze me by to mohlo byt jednou, ale je dobre pripomenout kdyz se nekdo silou snazi prosadit nesmysly.
Co bude priste? Jen IPv6? :-D
Svázání jedné domény s konkrétním certifikátem v prohlížeči se týká koncových uživatelů, HTTP klienta. Rozhodování o tom, zda se HTTPS nasadit má nebo nemá, dělá správce webového serveru. Až si přestanete plést klienta a server, možná leccos pochopíte.
Že je HTTPS nesmysl tvrdíte vy. Já zase tvrdím, že nesmysl je webový prohlížeč s podporou HTTP. Google podle vás má zřejmě takové postavení, že cokoli udělá či neudělá, jde o „prosazování silou“. V jednom prohlížeči podporovat i nepodporovat HTTP nejde. Takže Googlu nezbývá nic jiného, než něco (vašimi slovy) prosazovat silou – a mohou se rozhodnout akorát zda budou prosazovat váš nebo můj nesmysl.
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.
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,nagelovanej 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.
Nemám nic proti jednoduchým broukům, kde je jejich aplikace adekvátní, ale musím vědět, kde si ten luxus můžu dovolit.
"Napriklad spotreba v radech pikoamper max jednotky miliamper."
Potom tam automaticky nedávám Ethernet ani WiFi. Ani nic od Atmela.
"Jednoduchost ladeni,..."
U jednoduché předpotopní x51 jsi v ASM, standard je ladění osciloskopem a šmrdlání pinem. Nadstandard je výpis na UARTu, pokud je volný. U normálních MCU máš nějaký emulátor apod., kde si můžeš krokovat kód. Zcela překvapivě je to další modul na čipu, který s jednoduchostí nejde moc dohromady. A teď si představ, že jsou embedded systémy, kde ani ten JTAG nepotřebuješ, jenom připojíš Ethernet a spustíš GDB (většinou desky s ARM9, ARM11, Cortex-A, SH3, SH4, SH4A, MIPsy, PowerPC,...) Takže tenhle argument hodně pajdá. Čím složitější, tím líp se ladí.
"... potreba nizke intregrace(napr kvuli radiaci), ..."
To je jiná kategorie, tam napříkla dnesmíš mít FLASH paměti nebo (E)EPROM,... Takže tam jsou na to speciální brouci. A Ethernet PHY s nějakým bufferem a IP stack ve velké paměti programu je taky docela problém. Takže hádám, že tohle taky nebude ten případ.
"... nizky teplotni sum a tim padem nizsi naklady na izolaci/chlazeni kvuli presnosti mereni, ..."
Přesný měření se nedělá na MCU, ale mimo něj. S galvanickým oddělením, nezávislým zdrojem, systematicky oddělenou zemí atd. A AVRko má ADC ve stavu, že si nedokáže změřit ani to, jestli má na vstupu do desky 18 nebo 25V. Z vlastní zkušenosti. Takže zase argument mimo.
"... levne nahradni dily,..."
Aha. Od kdy že se zase mění procesory v paticích u embedded věcí? Ona práce je prakticky vždycky dražší, než měněná součástka (a pro info, v kusovce máš 200MHz 32b procesor pod 300, to je cena za hodinu práce zaměstnance, který ho má otestovat, vyměnit, vypálit program a ověřit funkčnost).
"...predikovatelnost chovani na urovni signalu."
Pokud chci, aby se digitalizovaný signál choval predikovatelně (malý jitter, minimální zpoždění,...), tak to není o jednočipu, ale o kombinaci ADC-FPGA-DAC. Případně ADC-DSP-DAC. Když je nejhůř, tak ADC-MCU-DAC, ale MCU s takovým výkonem, že přes 80% času tráví v IDLE, aby byla rezerva pro případ, že se třeba potkají tři přerušení. A iap k je to bez garance čehokoliv. Dát do takové aplikace mrchu, která při přerušení od tlačítka bude mít 10ms výpadek, je pěkně na pytel.
"Mezi soft kriteria muze patrit i treba zkusenost vyvojoveho tymu, ..."
Měl jsem jako FAE jednoho zákazníka. 20 let dělal s x51. Všechno v ASM, docela komplexní software. Jedna iterace ladění znamenala vyškubnout brouka ze zařízení, smazat, naprogramovat, zapojit do desky, připojit logický analyzátor, spustit program, prohrabat se výsledkama, upravit program, zbuildovat a repete (cca 35 minut). Jednou jsme mu ukázali jinou řadu MCU, s programováním v Cčku a laděním pomocí emulátoru. Koukal jak žaba z křa a hned ten den jsme měli objednávku.
"overena konstrukce daneho modulu"
Ověřená konstrukce je modulární konstrukce, na novým projektu používáš moduly ze starýho. To s výběrem CPU nijak nesouvisí - pokud je analogový front end na SPI, je jedno, jestli tam dáš AVRko, Cortex-A nebo FPGA. MCU je jenom jeden z modulů, nic víc.
"a funkcni dodavatelsky retezec."
Víš, proč AMD a Cyrix mají licence na x86? Proto, aby tehdá IBM neviselo jenom na jednom dodavateli.
Kdo ti zaručí 2nd source pro PIC16, PIC18, AVR, S3Fxxxx, RC8, H8 nebo třeba MSP430?
A o co jsi lepsi, ze mas pravo mu mluvit do toho, na cem implementuje otevrene standardy?
Kdyby posilal odpovedi na dernych stitkach, tak ma porad velmi validni pointu, ze ho nejaci frajeri nuti svym monopolem k necemu, co by vubec vubec nemusel hrotit.
Nejste trosku padli na hlavu, jeste monopolu takhle tleskat za jednostranny rozhodnuti?
Borci, co tu melou neco o meneni obsahu a jak je HTTP nebezpecne maji sami jiste davno uplne vsechna svoje spojeni ven sifrovana a do netu nejdou jinak, nez pres Tor nebo neco podobneho, ze?
Jinak jste totiz pokrytci a ja jsem na vas nasrany za to, ze davate Googlu dalsi a dalsi mandat, chovat se, jak se mu zlibi.
K*rvite svym pristupem netovy prostredi i mne a tim mne fakt tocite.
Pokrytci.
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ě.
Nezapomínají. Akorát neexistuje žádný důvod, proč by se o tahle zařízení musel starat zrovna standardní webový prohlížeč.
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.
Protože se tím zásadně snižuje bezpečnost celého webu. Pokud to opravdu někdo takhle potřebuje, ať si to zařídí pro svou potřebu, ale nemusí tím obtěžovat celý internet. Aspoň to třeb akonečně povede k tomu, že to samotné zařízení bude komunikovat nějakým jednoduchým protokolem, který ten čip v něm v pohodě zvládne, a vedle toho bude normální web server s pěknou obslužnou webovou stránkou, který bude se zařízením komunikovat tím jednoduchým protokolem.
Ten váš dotaz, proč by měl někdo něco instalovat, je totiž stejný, jako dotaz, proč by měl vrátnej při pravidelných obchůzkách zadávat PIN k trezoru a čekat na časový zámek, když mu můžeme do trezoru udělat boční vchod jenom pro něj normálně na FABku. Ano, udělat to jde, ale pak jaksi celý ten trezor ztrácí smysl. Takže asi bude potřeba to udělat opačně – zachovat funkci trezoru, a vymyslet, co s tím okrajovým případem v podobě vrátného. Jestli třeba na těch obchůzkách opravdu musí do trezoru lézt.
On ten současný stav, kdy do toho kotle nějaký topenář spíchne něco-jako-http-server, kde se spouští nějaké šílené CGI skripty děravé od začátku do konce, které vytvářejí šílené webové rozhraní, které stejně funguje v jediné verzi prohlížeče v jendé lokalizaci, má k ideálu taky hodně daleko. Říká se, že nejnebezpečnější člověk je programátor s pájkou, ono to ale o elektro inženýrech s kompilátorem platí úplně stejně.
Mimochodem, tu bydlenku s dětma doma a Lojzu pražáka ze Žižkova, kteří mají doma důvěryhodnou síť, kterou mají plně pod kontrolou, to jste myslel vážně?
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.
Jenomže zlýmu hochovi je jedno, jestli je tam Lojza nebo Pepa. On vidí IP adresu a chce prachy.
- zkusí to zašifrovat a žádat výkupný
- zkusí z toho dostat nějaký zpeněžitelný informace typu login k PayPalu
- zkusí to zasadit do botnetu a prodávat DDoS as a service
- zkusí na tom rozjet těžbu bitcoinů
Pokud je dnu z těch věcí splní (a minimálně třetí a čtvrtou odrážku splní určitě), tak je zajímavý cíl. A ta čtvrtá věc, ta jde mimochodem udělat i tak, že někde cestou přibalí do nezabezpečené http stránky kousek JavaScriptu... Ani se nemusí lámat do sítě. Blblý, co?
To ze jses paranoidni neznamena za po tobe nejdou. Kazdy se da vydirat... je jen otazka jak obtizne a co s toho ziskam. Statni instituce s tim maji velke zkusenosti.
Ale ne pres kotel nebo ovladani klimatizace... Koneckoncu vzdycky je mozne vytrhnout kabel, dat manual override a dat si par facek za nezabezpecenou sit.
Tohle neni spinani rozvodny pro pul mesta. Tam ty facky fakt boli. A dost lidi...
Opet pro natvrdle. Zabezpeceni adekvatni reseni. Pokud vim ze me nekdo realne muze vydirat tak zmenim zabezpeceni na vyssi.
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+firewall 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.
To je hezké, že byste pomalu ke kabelu postavil chlápka se samopalem, ale pak do téhle super-bezpečné sítě pustíte starý webový prohlížeč, který bude přes HTTP něco stahovat z internetu. Víte, největší bezpečnostní riziko není ten kabel mezi počítačem a kotlem. Největší bezpečnostní riziko je ten webový prohlížeč.
Pokud jde o bezpecnostni riziko prohlizece, tak po jeho napadeni uzivateli zadne HTTPS nepomuze uz tuplem. Po jeho napadeni muzes s prohlizecem delat vsechno a analyzovat i rozsifrovanou komunikaci nebo ti muze nekde skodit jinde. A to i pres to ze budes mit HTTPS jen s certifikaty kterym duverujes.
To uz pak muzeme prestat verit operacnimu systemu,vsem dalsim knihovnam atd.
A rozejit se muzeme s tim ze kotel by vubec nemel mit zadny pristup a uzivatel-bezny lojza by mel ovladat jen zapnuto/vypnuto protoze ani HTTPS nic neresi. Na vsechno ostatni by mel prijit technik se specialne certifikovanym notebookem ministerstva vnitra a nastavit vse specialne certifikovanym softwarem na upravenych certifikovanych windows. Kotel by se musel zapojit pres specialni trafo aby nemohl treba leakovat udaje pres rozvodnou sit nekam ven a nedej boze abys posilal jeho seriove cislo smskou protoze to by mohlo ohrozit zajmy tohoto statu a narodni bezpecnost... Kotel by musel byt plne odstineny od komunikace s vnejsim prostredim aby nedejboze nemohl nekdo zjistit na kolik topim a jake jsou otacky cerpadla.
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.
Holt když se někdo rozhodl používat hack a k nastavování kotle nebo něčeho takového používat webový prohlížeč, je na něm, aby si ten hack udržoval v chodu, použil jiný hack a nebo použil nastavovátko kotle. Já nechápu, kde vy berete odvahu tvrdit, že autoři webových prohlížečů mají kašlat na to, jak se s nimi prohlíží web, a mají se starat hlavně o to, jak se s nimi nastavuje kotel.
Prohlížeč zabezpečení vašeho prostředí nijak nehodnotí. Prohlížeč poskytují autoři proto, aby lidé měli čím prohlížet web. Pokud vy prohlížeč používáte k něčemu jinému, je to váš problém, ne problém autorů prohlížečů.
Že autoři webových prohlížečů způsobí problémy uživatelům nastavovátek kotlů, to je nemusí moc zajímat, protože pro ně jsou důležití uživatelé webového prohlížeče.
Aby ne... Mate tam malo javascriptu, malo gigahertzu/gigabajtu/terabajtu v kazdym ohledu a jeste ke vsemu nechapete, jak to Google se vsema mysli dobre ;)
Neni dostatecne moderni nad vecma premejslet a ptat se, jestli jakykoliv akce zrovna tyhle firmy nahodou nejsou ke skode cely veci, nez ku prospechu.
Juchu, bude se siftovat, parada, mas mit nasazenej Let's Encrypt, taky neni vubec na miste se zamyslet, jestli nahodou neco nesmrdi, kdyz je to v podstate jediny reseni na tyhle Guglovsky vymysly - protoze se nikdo ani nezamyslel a natoz, aby se ozval, ze jiny reseni nezbejva.
Pak tu mame HTTP Public Key Pinning, co je zase navrh z Googlu, aneb pokracujeme na vlne nekritickyho tleskani, juchu. Ze to cely vede do radne smrdici brecky, si tleskaci vsimnou, az bude prilis pozde.
Ale to je v klidu, ve svete, kde je vetsina techhle super vymyslu deployovana one-click ready-made resenima, se neni vubec ceho bat. Hlavne, ze zbejva cas na scrollovani Faceboocku - sviti tam zelenej zamecek, tak pohoda, ne? ;)
Že ostatní nad věcma nepřemýšlí, to tak soudíte podle sebe? Protože jste napsal, že je něco ke škodě věci, že jediné řešení je Let's Encrypt, že HPKP vede do řádně smrdící břečky – ale u ničeho jste nenapsal důvod, proč je to špatně. Přemýšlel jste nad tím tedy vůbec? A zvažoval jste variantu, že nad tím lidé na rozdíl od vás přemýšlí, a dospějí k závěru, že je to lepší (třeba používat HTTPS všude), proto to podporují?
Napsal jste, že HTTPS všude je spíš ke škodě věci než k užitku. O tom, že to Google tlačí jak to tlačí, jste nic nepsal. A opět, ani tentokrát jste neuvedl nic konkrétního. Že to všechny poslalo do náručí jedné CA jste taky nijak nedoložil, a vzhledem k tomu, že na webu běžně potkávám certifikáty od jiných certifikačních autorit, řekl bych, že to není pravda.
Ale hlavně se vyhýbáte tomu hlavnímu, že ostatní obviňujete z toho, že nepřemýšlí, jenom proto, že mají jiný názor, než vy – a vy sám pak svá tvrzení nedokládáte, prostě napíšete, že je něco špatně, a vůbec neřešíte, proč.
Kde přesně se v téhle větě píše o nějakém tlačení?
ptat se, jestli jakykoliv akce zrovna tyhle firmy nahodou nejsou ke skode cely veci, nez ku prospechu.
Když se důsledně vyhýbáte čemukoli konkrétnímu a jen tak mlžíte okolo, nedivte se, že pak ostatní musejí hádat, co jste vlastně myslel. A že se občas stane, že to, co jste myslel, v tom mlžení vůbec není.
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).
