Vlákno názorů k článku HTTPS by mělo být všude od Rahno - Na tlaceni https mi vadi, ze driv, nez...
-
Rahno (neregistrovaný)
Na tlaceni https mi vadi, ze driv, nez se zaclo vsude tlacit se clovek mohl v nouzi na web pripojit i s telnetem, ale zkuste si se s nim pripojit na web ktery vynucuje jen https... Rozumnym kompromisem by mozna bylo, kdyby weby napriklad s domenou 3. stupne nohttps na https nepresmerovavaly, ale ze by se neco takoveho rozsirilo je asi jen sci-fi.
-
Ondřej CaletkaZlatý podporovatelNehledě na to, že v opravdové nouzi, tedy bez elektřiny, nefunguje ani telnet :)
Ale dobře, uznávám, třeba na embedded systému, kde je jen BusyBox, bude šifrování trochu problém.
-
Rahno (neregistrovaný)
S tim, ze by na nejake distribuci nebyl telnet jsem se jeste nesetkal, ale verim vam. Ze se takhle da pouzit openssl jsem nevedel, diky. I tak se mi ale zda zbytecne tlacit https za kazdou cenu vsude a to jsem v jadru paranoik, ktery nepouziva sociallni site a na bezpecnost si docela potrpi.
-
Ondra Satai NekolaZlatý podporovatelVazne nevidim duvod, proc resit "pripojeni se telnetem" jako use case. To je ocividny non-goal - pokud to nahodou funguje, tak OK, ale vyvijet jakoukoli cinnost za tim ucelem nema smysl.
-
j (neregistrovaný)
O telnet vubec nejde, ale mas hromady vsemoznych krabek, ktery proste pouzivaj http jako komunikacni nastroj, a nic jinyho nikdy umet nebudou, protoze je to nejakej picmic a i to http umi jen v nejminimalnejsi variante.
Takze az se idioti v Mozille a spol rozhodnou, ze http zrusej, prestanou lidem fungovat miliardy veci. Ostatne presne stejne, jako vyhodili "nebezpecne" sifrovani, a kazdej admin kvuli tomu pouziva jednoduse starsi verze, protoze jeho za stovky tisic nakoupeny krabice nic novejsiho uz nikdy umet nebudou, a vymenovat se budou za mozna 10 let.
-
DannyStříbrný podporovatelA jaky puvod ma poplasna zprava, ze Mozilla ci kdokoliv jiny podporu HTTP zrusi? :-) Eliminuje se podpora pro nebezpecne SSLv2, SSLv3, nebezpecne "sifry" typu RC4... ale HTTP stale chodi. A i ta "legacy" sifrovani pri trose snahy jde zapnout, pokud pro to ma clovek fakt specificky duvod.
Otazkou je, zda cloveku maji trhat zily ty vselimozne krabky, kde autor SW moc na bezpecnost nedba. To neni jen o HTTPS :-) Teda pokud se nebavime o jejich vyhrnuti buldozerem.
-
Trident (neregistrovaný)
Žíly to netrha. Ono je to úplně jedno. K těm krabkam se stejně přistupuje přes Vpn nebo web server v proxy režimu který https obstará. Vnitřní síť se dá udělat duveryhodna. Jo ano. Je tu problém s těmi cloudovymi tydyty... kde vnitřní síť jaksi není moje. Opravdu bezpečnostně důležité věci jedou po oddělené infrastrukture a tyhle krabky si tam nepustis.
-
DannyStříbrný podporovatel
A vazne mi chcete namlouvat, ze tu vnitrni (dnes zpravidla ethernetovou) sit mate postavenou s 802.1AE/MACSEC, a pak tam pripojujete ty krabky za par haliru... co MACSEC urcite taky neumi, a vysoce pravdepodobne nepodporuji ani 802.1X/PNAC? :-) Jakym skutecne verohodnym zpusobem zajistujete integritu komunikace v te takzvane duveryhodne siti? :-)
-
Ondra Satai NekolaZlatý podporovatel
to je velmi odvazne pouziti "az" (na nesmyslne idiotovani jsme uz od tebe zvykli...)
-
Starous (neregistrovaný)
uvědomujete si že mluvíte o velké většině krabiček pro internet od things ? a co zdravotnictká a automoto zařízení? tam http taky stačí? já teda doma nic s http nechci a v situaci kdy má můj telefon výkon superpocitace pred x lety mi to prijde opravdu úsměvné. Btw jaký myslíte že je způsob jak donutit výrobce těch krabiček přestat používat sslv2 sslv3 a RC4 ? Jedině tím že se to prostě natvrdo vypne. Btw certifikáty se generují i v zařízeních tipu simkarta nebo platební karta kde žádné prostředky taky nemáte. A jaká je životnost krabiček ? Když udělám certifikát na 10 let do předu tak a) značně prevysim jejich životnost b) krátký certifikát může sloužit jako kurvitko a podporovat prodej nových krabiček - ty staré alespoň nebudou šířit malware a půjdou do šrotu. Já vidím samá pozitiva
-
Petr M (neregistrovaný)
Jééé, 8bit s pár kB RAM :D Pod 16kB pořádně TCP/IP stack nerozchodíš a nad 16kB 8b jednočip s interní RAM pořádně neseženeš, takže smůla.
Řešil jsem to před sedmi lety. Skončilo to na AT91SAM7XE256 (ARM7TDMI@55MHz) + PHY za pár korun. Cenově vyšel líp jak ten osmibit s externí RAM a ETH. Jeden čip s 256kB FLASH a tuším 64kB RAM, navíc s hardwarovým encryption akcelerátorem a MAC+DMA na čipu. Kdo by se crcal s externí RAMkou, externí FLASHkou, externí MAC,... a optimalizoval kód na velikost i rychlost, když nemusí a dostane navíc HW šifrování? Asi jenom omezenci, co neznají sortiemtn součástek na trhu...
-
hmmm (neregistrovaný)
Copak telnet, ale dalo se to snadno debugovat. Navic v takove vecicce stacilo mit pamet tak na dva pakety (jednotky kilobajtu). V jednom byl dotaz z klienta (napr. "GET teplota1") a v druhem odpoved serveru (napr. "<html>11.5</html>"). Vlastne nejslozitejsi na HTTP/0.9 bylo navazat a ukoncit TCP spojeni. Jak byl ten svet jednoduchy.
Off-topic: Ted koukam na net, ze odstoupil Winterkorn. Taky neustal tlak modernich zachrancu planety.
-
DannyStříbrný podporovatel
A ted si predstavte, ze na zaklade takto zjisteneho udaje ridite nejaky kriticky provoz, ktery na zaklade podobneho odectu rozhoduje, co se stane :-) Co kdyz Vam tim jednoduchym protokolem zacnu podvrhavat jine hodnoty, tak aby na oko bylo vse v poradku s cilem takovy provoz poskodit? To je ostatne problem cele rady dnesnich SCADA systemu, autori v davne minulosti k tomu pristupovali podobne "jednoduse". Jenze s timhle pristupem slo pracovat mozna v dobe, kdy vsichni kolem meli ciste umysly - a to dnes fakt neplati :-)
-
Starous (neregistrovaný)
konkrétní příklad pro IoT. Jak se mluví o self-driving cars tak soudruzi v americe dostali skvělý nápad připojit všechny semafory k internetu že budou autům hlásit zelená červená... to jsou také jednoduché krabičky a vymešlí jak zbastardizovat TLS aby mohli použít jen něco jednoduchého... tenhle přístup je cesta do pekel a doba kdy se můžete odvolávat na hw nároky je dávno pasé. Je nutné zvednout standart zabezpečení i u těchto zařízení...není přeci možné říct že před 20 lety to stačilo a tak to tak bude navždy. Navíc u čipů už se dávno cena neodvíjí pouze od výkonu ale především množství ve kterém se vyrábí...
-
DannyStříbrný podporovatel
Tak samozrejme :D Treba takova Raspberry Pi je strasne zrave zarizeni. A ze podobnych je. Je zajimave, ze jsou vyrobci, co vam do 15W na 802.3af vmacknou kdejakou funkcionalitu kolem, i vcetne toho sifrovani. A co teprve luxus power budgetu 802.3at. Nevim, odkud berete tech 50W :-)
-
DannyStříbrný podporovatel
Kdo hleda, najde - chce si to rozsirovat obzory a nezustavat u toho, na cem jsem zacal pred 10 lety. Vyvoj jde kupredu.
-
Petr M (neregistrovaný)
Jasně, a teď tu o Sněhurce.
Doporučil bych mrknout na http://www.atmel.com/Images/Atmel-8067-8-and-16-bit-AVR-Microcontrollers-ATxmega64A1-ATxmega128A1_Datasheet.pdf
Konkrétně stránky 46 a 74. AES/DES se 196uA ( ani ne 0, 000 65W při 3,3V). Na RF modul u teploměru, nebo na RS-485, to bohatě stačí. I UDP pakety se s tím dají přechroupat, když na věc přijde. A když neprobíhá zpracování dat, dá se to vypnout.
HTTPS z toho může udělat nějaká gateway, která jich bude obsluhovat třeba 20, bude mít dost výkonu na solidní web server, logování a vizualizaci,.. Pokud teda bude mít web server smysl a nebude jednodušší u uživatele zpracovat rovnou UDP s DES v aplikaci. On přenos dat po síti totiž není jenom o http(s) a zrovna u teploměru je to jak lovit motýly bazukou.
To o žravosti šifrování a nemožnosti šifrování na 8b jsou jenom pověry. Kdo chce, hledá způsoby, kdo ne, hledá důvody.
-
Petr M (neregistrovaný)
Ono už při návrhu se musí - promiňte to sprostý slovo - myslet!
Zvažovat všechny alternativy, pro a proti. Jaká je cena přenášených dat? Jaký jsou rizika, že se něco podělá? Jak je eliminovat? Je levnější, jednodušší a poslehlivější použít RF moduly, RS-485, CAN, nebo LAN? LAN vychází nejdráž, je opravdu důvod ho použít? Je nutnost komunikovat s čidlem po HTTP(S)?
Potřebuju ty data šifrovat? Pokud jo, tak na šifrování je i u AVR hardware, viz výše. Když schovám 2B do paketu a přihodím hodně soli (např. šum z ADC) a proženu AES/DES modulem, hodně odposlouchávačů to odradí.
I kdyby HTTP zaniklo, tak v embedded světě je to to poslední, co by mě trápilo. Jenom to na krabičce nebude TCP:80, ale třeba UDP:2369.
A ven to může jít z web serveru na routeru apod. - cena za HW nula, jenom malej démonek v C, rozsahově menší, než web server v jednočipu. Web, TCP a UDP stacky už jsou ve WRT hotový... A sloučí to klidně víc čidel do jedné stránky, takže to schová do jednoho paketu a nemusím se furt dokola ptát deseti krabiček, démon to udělá za mě :D
-
lojza (neregistrovaný)
U toho teploměru nebudu ztrácet ani čas ani peníze zajištěním nějakého šifrování, protože by to byla naprostá hovadina bez reálného přínosu. Přihlásit se k tomu nedá, že to někdo odposlechne ji mi buřt, že má někdo obskurního ISP co mu cpe do stránek reklamu je jeho problém. Ještě si to komplikovat nějakým routerem a psát do něj démonky v C, muset si ho koupit když ho nemám a nepotřebuju. Atomovka na vrabce sice funguje dobře, ale je to řešení s mizerným poměrem přínos/náklady. Ale jo, jinak máte pravdu, při návrhu je potřeba myslet.
-
Ray (neregistrovaný)
To nemá s HTTPS nic společného. Taky děláme i krabky, na všechno možný, žádná nemá HTTPS a přesto přeju při snifování a změnu dat hodně štěstí (o: A jsem si relativně jist, neb návrh šel přez mr. Klímu, tož z kryptologického hlediska asi dobrý. Všechy změny co udělal byly pěkné, ikdyž některé (na první pohled !) nedávaly smysl :)
To je další mor post Snowdenovské doby. Na všechno by se nejradši dalo na HTTPS. Speciálně na krabky (buzzově IoT). Tam je to absolutně nepraktické, ať už z hlediská nároku na RAM/CPU (speciálně asymetrické části), řešení problému slepice a vajíčka (aneb komu důvěřovat napoprvé) atp.. (stejně jako nutnost IPv6 btw :)
Na kvalitní, zabezpečenou komunikaci, kde jsou obě strany vzájemně autentifikovány, není potřeba HTTPS ani asymetrická kryptografie. Speciálně ne u krabiček... Každý slušný dnešní SoC umí slušně chránit některé části svý flešky. Preshared secret, halda náhodných bajtů, je naprosto skvělé zabezpečení i autentifikace zároveň. Jen se s tím musí rozumně "nakládat".
Tlak na HTTPS je podle mne zjevný. HTTPS je mnohem snáze "prolomitelný" (a to neberu v potaz protokol jako takový, jen systém certifikátů), než jakýkoliv "rozumně" napsaný systém ve smyslu prvního odstavce. A spotřebovavá nesrovnatelně menší zdroje CPU... A RAM ? Na urovní pár desitek bajtů... Směšně s porovnání s async crypto (která je nedílnou současí HTTPS, potažmo SSL/TLS).
R.
-
DannyStříbrný podporovatel
Tak samozrejme HTTPS nezbavuje nutnosti navrhovat bezpecne aplikace. Sifrovani samotneho transportu je jen dalsi bezpecnostni vrstva - nic vic, nic min. Riziko prolomeni tu je vzdy a u vseho - a namachrovanych borcu mluvici o neprolomitelnosti toho sveho je v historii IT k nalezeni taky plno :-) Cim vetsi kombinace ochrannych faktoru prunik komplikuje, tim lepe. A o tom to cele je.
Pokud je u specificke (paranoidni) aplikace duverujovano vyhradne vlastni CA (a zadne jine; cemuz vubec nic nebrani) a samotna CA je sama o sobe pricetne provozovana, pak i tyhle zmineny rizika jsou znacne eliminovane.
CPU/RAM v dnesni dobe? I u embedded veci jsou bezne procesory a pametove moznosti natolik dostacujici, ze to daji s prstem v nose pri minimalni spotrebe. S pouzivanim modernich kryptografickych technik jde ty naroky na vykon jeste snizit, aniz by se snizila bezpecnost komunikace.
