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)?
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.
"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"
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.
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.
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.