Názory k článku Miliony zařízení sdílí privátní klíče k HTTPS a SSH

Tady nekdo vzivote nevidel, jak se neco vyrabi ...

Milej zlatej, vazne si myslis, ze ti treba automobilka doda nastaveny a fungujici auto? Nikolivek, to dela az prodejce. Jenze u veci za 1/2M se ta prace jaksi ztrati v cene. Kdyby mel vyrobce kazdou jednu krabku i jen zapnout, tak by nestala 3 kila ale 3 litry.

Kolik % lidi je ochotno zaplatit 3k za krabku, ktera bude konfigurovatelna? (ty parodii od NICu ani nemluve). A proc by to meli delat? Aby jim pak kkti z Mozilly/googlu/... rekli, ze maj tu krabku vyhodit, protoze pouzitej algoritmus uz prej neni dost bezpecnej? lol

Ty miliardy lidi si proste koupej to nejlevnejsi co horko tezko zapojej a pokud jim to funguje, tak to menit nebudou. A ze by to mel resit provider? A proc proboha? O poskytne pripojeni a je mu jedno co si na ty svy lince zakaznik prenasi. Proc by mel vynakladat prozmenu svoje penize na to, aby resil neco, co mu nevadi?

proc by mel byt turris parodie?

Zeptej se vyrobce.

Si precti co o tom napsali ... ze to mel bej levnej konfigurovatelne router pro domacnost ... lol ... a stoji to vic, nez cisco.

Však se ten klíč může vygenerovat při prvním zapnutí u zákazníka. Stejnak je v tom různě ořezaný linux, tak napsat ten script nebude tak těžké.

Ke generovani klice potrebujete entropii. V PC se vyuziva drobny sum pro mereni casu toku dat od HDD, pohyb mysi, stisky klavesnice, a ruzna casova razitka udalosti., ktere je obtizne kontrolovat.
Co mate nartiklad na takove zasuvce ovladane pres Wifi? Sitove napeti, pokud se vubec meri, Okamzik bootu vhledem k pruchodu faze nulou (pokud se vyhodnocuje) a jinak NIC. Mala entropie v takto vygenerovanm klici zpusobi, ze hromada zarizeni si vygeneruje nezavisle na sobe stejny klic a jsme tam kde ted.

Pokud se něco ovládá přes prohlížeč, není problém přece takovou aktivitu vykonat v prohlížeči. Stejně se ta krabka musí napřed nakonfigurovat.

Kdyz je tam prohlizec, tak je to mozne. Jenze dnes je trend aby se to "nemuselo" (a casto ani nemohlo) konfigurovat vubec. proste plug&play.
A to "plug" je v pripade IoT predevsim do cloudu, dokonce ani ta zasuvka neni tak povina.

Když tam už je rádio, asi by nebyl zase takový problém do něj přidat API pro čtení šumu.

To ano, ale to jen o malo lepsi nez nic. Predpokladem totiz je, ze jde skutecne o sum a ne podvrzeny radiovy signal. A tento predpoklad nemusi byl splnen (i kdyz vetsinou je)

A co traffic na síti? Čas mezi paketama, data lítající po síti,.. Udělá se z toho nějaký pěkný dlouhý binární blob (otázka obvykle několika sekund), spočítá hash a je to...

Pro případ zapnutí několika krabiček na stejné síti současně třeba... sériový číslo FLASH/CPU/... jako sůl. Tam už výrobci čipů dávají aspoň kontinuální řadu, že je tam nějaký rozdíl.

Zrovna traffic na domaci siti se muze za specialnich okolnosti stat silne predikovatelnym. Ale jak psal nekdo vyse, znamena to utok utocnika v dobe instalace a ne az potom, takze porad vyrazne lepsi nez nic.

Zajímalo by mě, jakým způsobem se v továrně do těch zařízení flashuje firmware. Já to dělal zatím jenom v malém ručně, pár desítek kousků maximálně, a při tom není problém tam vždycky zapsat pár náhodných bajtů. Továrna to programuje nějak masově?

Routery většinou při bootu pokoušejí stáhnout firmware z TFTP, divil bych se, kdyby se to v továrnách dělalo jinak.

Dela se to uplne jednoduse, mas zhruba nasledujici varianty
1) nechas si vyrobit chip, na kterym je soft napalenej rovnou z vyroby natvrdo
2) naladujes vsechny chipy do nejaky masiny, ktera ti tam proste (jeste pred osazenim) napali soft
3) mas na desce nejakej pinout, na kterej se po osazeni pripojis a napalis to na uz hotovou desku

Poradi odpovida taky cena - cim pozdejs, tim vyssi.

Problem (s jakoukoli) odlisnosti mas predevsim v tom, ze pri aspon trochu normalnim postupu se dela verifikace - ovsem binarni pochopitelne, a vadny chipy/desky se rovnou vyhodej. Pokud bys tam tudiz napalil pokazdy neco jinyho, mas problem, protoze ten primitivni test ti nebude fungovat. Navic by to misto opakovanyho zapisu stale stejny matrice znamenalo pokazdy spocitat cosi ... a pokud se bavime o milionech kusech a potreby rozumny entropie, tak ses v riti.

Nezapne? A jak se tam dostane bootloader. firmware a MAC adresa?

Když jde nahrát MAC, proč nejde klíč? Protože výrobce je <<autocenzura>>.

Tady by mělo platit nejsem tak bohatý, abych kupoval levné věci...
Nějaký switch který není vystavenej ven je v pohodě, takže laciná krabička může bejt, ale router musí být bezpodmínečně zabezpečenej tak, aby zvnějšku nebyla šance. Člověk musí před pořízením zařízení myslet a když to nedokáže nebo se mu nechce, dobře mu tak!

Myslíte, že je dostatečné mít tato zařízení za firewall, tzn. přístupné pouze v rámci intranet?

Dnes uz ne, specielne, kdyz IoT hracky nefunguji bez pripojeni na ovladaci cloud. Nelze je tedy izolovat do intranetu.

"nefunguji bez pripojeni na ovladaci cloud"
Takové bych likvidoval už na hranicích EU.

Tak to bez podpalit Jablotron.

Zaujimalo by ma ci je toto osetrene na DD-WRT, Open-WRT, Tomato a podobnych 3rd party FW pre routre.

Jo, tam ty to osefovany, na ty se uz neprihlasis... Error code: ssl_error_unsup­ported_version - ddwrt na wrt54g. Proti http to kupodivu nic nenamita, co na tom ze si pak to heslo muze pres wifi chytit kazdej jouda, zejo.

Error code: ssl_error_unsup­ported_version - ddwrt na wrt54g.

Na tom 4MB šrotu používá webserver jakýsi microssl, kde TLS není vůbec podporovaný. Měnit to kvůli milovníkům starožitností nikdo nebude.

Zaujimalo by ma ci je toto osetrene na DD-WRT, Open-WRT, Tomato a podobnych 3rd party FW pre routre.

V DD-WRT je to "ošetřené" tak, že si certifikát a klíč nacpeš do startup skriptu, GUI ani nic jiného nevedeme.

echo "-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE KEY-----" > /tmp/ssl/key.pem
echo "-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----" > /tmp/ssl/cert.pem
chmod 0600 /tmp/ssl/key.pem
grep -q -e "/etc/cert.pem" /proc/mounts || mount -o bind /tmp/ssl/cert.pem /etc/cert.pem
grep -q -e "/etc/key.pem" /proc/mounts || mount -o bind /tmp/ssl/key.pem /etc/key.pem
stopservice httpd
startservice httpd

V OpenWrt si tam buď nainstaluješ px5g a ten ti vyflusne klíč a self-signed certifikát podle nastavení v /etc/config/uhttpd, nebo si tam nacpeš certifikát a klíč vlastní.

config uhttpd 'main'
...
        option cert '/etc/uhttpd.crt'
        option key '/etc/uhttpd.key'
...

config cert 'px5g'
        option days '730'
        option bits '2048'
        option country 'CZ'
        option state 'Czech Republic'
        option location 'Vidlakov'
        option commonname 'router.example.com'

Tak to je vtipný dotaz. Spíš bych se ptal jesli to má ošetřené Tenda, D-Link, TP-link a podobné, ještě obskurnější značky. A jestli na tom jsou podobně i UBNT tak potěš koště. Naposled kvůli jejich ignorační chybě popadala půlka wifi sítí ve světe i v této malé republice. Bohužel i já jsem byl postižen přes mého ISP (zaplaťpánbůh že jsem měl založní připojení).

TP-Link to měl před dvěma lety ošetřené tak, že komunikaci nešifroval vůbec, takže se na slabý šifrovací klíč narazit nedalo :-).

Ono v pripade ubnt jde taky trochu o to, ze novejsi firmware sice opravi nejaky bezpecnostni problem, ale velmi casto uvede sit do nepouzitelneho stavu. Diky povinne zaplemu DFS a falesnym detekcim radaru je pak zarizeni prakticky nepouzitelne.

Takze ne vzdy ma na hlave maslo jen ISP. Reseni (zatim) existuje, ale je stale komplikovanejsi a je otazkou, zda je zcela koser. A je take nejspis mimo schopnosti klikacich adminu.

Pouziti starsich firmwaru koser zcela jiste je a problemy s DFS netrpi.

Primarnim problemem je neschopnost tech zarizeni odlisit radarovy puls od interferenci vzniklych hustym provozem v CR. Otazkou muze byt i to, zda EU regulatorni pozadavky na dfs jsou rozumne. Treba takove naslouchaci zpozdeni 10 minut mezi zapnutim boxu s provozem je take chutovka. Ve starsich firmwarech neni.

Jaky firmware byste pouzil Vy v roli ISP?

Tak a teď by to chtělo nějaké návrhy řešení, protože to je celkem vážný problém...

Takze vlastne navazujeme na predchozi diskuzi.

Krome nekolika evangelistu na rootu, v googlu, atd. bezneho bfu vlastne https nezajima (jako stredne pokrocileho bfu me to zajima fakt jenom, kdyz jde o penize), takze aby se vlk nazral, tak tam proste je nejaky certifikat a nejake to https.

Je to podobne jako s IPv6. Pro nektere typy uloh to je proste zbytecne komplikovane a v takovych pripadech IPv4 nebo HTTP proste staci. Proto se taky tyhle dva protokoly staly tak popularni. Jenze tenkrat to byla jina generace inzenyru/progra­matoru, od kterych se i ja obcas neco rad priucim.

Můžeš nastínit pár věcí, ve kterých je IPv6 komplikovanější než IPv4? Já naopak narážím na IPv4 na strašně moc komplikací způsobených maškarádou a privátními adresami.

Predevsim to, ze se samotnym IPv6 si nevystacis (pokud nezaradis nejakou 6to4 branu). Co ale v pripade kdy system pozaduje obe adresy, a dostane jen jednu? Vetsinou totiz konfigurace sitove karty (network manager) nevi, jestli system bude pouzitelny, kdyz dostane rekneme ipv4 a nedostane ipv6. (Co kdyz je tam namountovany sitovy filesystem, vyzadujici prave jeden z tech protokolu?)

Dale pak bylo docela dobre odladeno DHCP. Nove musi univerzalni zarizeni umet RA i DHCPv6 (nebo jak se ty autokonfigurace vlastne jmenujou). Spravce "verejne" site (treba univerzitni) pak musi zamezit aby klient nemohl hrat roli serveru/routeru a posilat podvrzene DHCPv6 nebo RA odpovedi. To dokonce musi udelat i v IPv4 only siti, protoze jinak nejaky zly klient se bude tvarit jako IPv6 router a obet ktera si prinese notebook nebo telefon se zapnutym IPv6 bude do internetu pristupovat na IPv6 adresy pres tohoto utocnika. (A naopak musi blokovat DHCP(v4) v IPv6 only siti.)

Routery po ceste musi znat _vsechny_ rozsirene hlavicky IPv6, protoze jaksi delka danne hlavicky (tedy to, kolik ma to zarizeni preskocit aby naslo rozsireni, ktere potrebuje inerpretovat) je v kazdem rozsireni na jinem miste.

A fundovani by ti jiste byli schopni dat seznam mnohem delsi.

http://www.root.cz/clanky/bezpecne-ipv6-trable-s-hlavickami/

> Predevsim to, ze se samotnym IPv6 si nevystacis

Aha, takže až za nějakou dobu budeš potřebovat služby dostupné jen po IPv4, tak najednou bude „zbytečně komplikované“ IPv4?

> Co ale v pripade kdy system pozaduje obe adresy, a dostane jen jednu?

Taková situace nastává naprosto běžně, pokud v síti není RA nebo naopak DHCPv4 server.

> Spravce "verejne" site (treba univerzitni) pak musi zamezit aby klient nemohl hrat roli serveru/routeru a posilat podvrzene DHCPv6 nebo RA odpovedi.

Ale to přece nesouvisí s IPvX, ale s tím, že máte nezabezpečenou nižší vrstvu. Někdo jiný by zase mohl tvrdit, že IPv4 je „komplikované“, protože správce veřejné sítě musí zabezpečit proti rogue DHCPv4 a ARP floodům.

"Co kdyz je tam namountovany sitovy filesystem, vyzadujici prave jeden z tech protokolu?"

Konektivita není zaručena a file systém musí se ztrátou konektivity počítat už z principu. Nemůžeš garantovat, že se nerestartuje WiFi AP, nějaký moula nepřekopne kabel, když jedeš po VPN, server nebude pod DDOS,... Nehledě na prostou skutečnost, že takový file systém bez IP adresy namontovaný nebude.

V boxu ktery mel jen jeden protokol, se mohlo prohlasit, ze ucelem toho boxu je byt pripojeny k internetu a tedy boot zastavit do doby nez se dostane adresa. Proste je stale dost problem mit spolehlive vedle sebe oba protokoly na jedne masine, zvlast kdyz tam nejaky moula (cast prace odvede spravce distribuce, dilo zkazy pak dokonci spravce systemu) naskriptuje update /etc/resolv.conf z obou autokonfiguraci a nenastavi ze ty dva mechanismy jsou spolu v konfliktu (budou si navzajem prepisovat /etc/resolv.conf).

Pokud budete mit na obojetnem boxu nakonfigurovany server ktery posloucha nejak na ipv6 a nejak jinak na ipv4 (ano to neni prilis standardni konfigurace, ale varovan v zadne dokumentaci nebudete), tak po bootu, kdy bude jen jeden protokol, bud nenastartuje vubec, nebo nastartuje jen v tom jednom protokolu a ten druhy az do restartu nezapne.

Kdy už se konečně všemožní pisálci naučí mluvit česky a nechají si vysvětlit, jakou koncovku má přítomný čas 3. osoby množného čísla...

Viky nejspíš netuší, že 3. osoba množného čísla od sdílet je nejen sdílejí, ale i sdílí

na router bych nechtěl nic jiného než OpenWRT.

Souhlas, ale bohužel na špičkové FSP routery s mega propustností nejde dát (typicky Mikrotik). Uvítal bych, kdyby výrobce nabízel třeba dual boot, když už za to chce dost velký peníze. Na nějakou licenci level 5 nebo kolik mu celkem kašlu. Existují starší, výkonově slabší typy, kam OpenWRT jde, ale pak to všechno samozřejmě ztrácí smysl.

Je to asi tak podobné jako si nechat W10 od výrobce na novém stroji třeba s i7 atd. (včetně všeho toho bloatwaru, který tam musí bejt). Zaplatpánbůh tady to jde řešit radikálně hned (výměna za nový, obvykle lepší disk) a instalace oblíbeného systému dle preferencí :)