Příspěvky

1471

Vývoj / Re:JS autoclick na button s id / provedení scriptu

« kdy: 11. 02. 2021, 11:44:15 »

Stačilo přidat krátký delay, počkat než se vše načte a nyní přesměrovává automaticky.

Přidávat někam prodlevu na čekání je klasický případ kódu, který někdy fungovat bude a někdy ne. Není to dobré řešení a používá se jedině jako hotfix. Ten kód totiž nečeká, než se vše načte. Ten kód prostě jen čeká a pak se spustí. Typicky bude čekat zbytečně dlouho – 4 sekundy už uživatel zaznamená a nejspíš začne i se stránkou nějak pracovat, takže mu pak budete tlačítko mačkat „pod rukama“. A někdy se to naopak ani během těch 4 sekund načíst nestihne.

Podstatně lepší by bylo zareagovat na okamžik, kdy je tlačítko připravené k použití. Pokud je připravené hned pro načtení DOMu, dá se použít událost DOMContentLoaded na dokumentu. Pokud se tlačítko oživuje synchronním JavaScriptem, dá se požadované funkce docílit správným seřazením JavaScriptů. V ostatních případech to nejspíš také bude nějak řešitelné, záleží na konkrétním kódu.

1472

Vývoj / Re:JS autoclick na button s id / provedení scriptu

« kdy: 11. 02. 2021, 09:59:53 »

Ale jak to udělat za uživatele? Jak zajistit, aby se automaticky kliklo na ten button a přesměrovávalo na tu bránu?

To dělá ten řádek, který jste napsal (pokud to tlačítko má id payButton):

Kód: [Vybrat]

document.getElementById('payButton').click();

1473

Sítě / Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní

« kdy: 10. 02. 2021, 15:46:09 »

taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?
Triviální by samozřejmě bylo něco jako ip rule add uidrange 1010-1011 lookup 123456 - ale myslím, že pokud bychom měli dvě routy scope link do stejných IP rozsahů, ale fyzicky různých sítí, tak by to nefungovalo, minimálně pro lokální traffic v těch sítích..(?)

ip rule umožňuje to, že máte v systému víc routovacích tabulek, a pomocí pravidel určíte, která routovací tabulka se má kdy použít. Tj. v tomto případě by se kolizní rozsahy nepotkávaly v jedné routovací tabulce, takže by nevznikala ta kolize. Samozřejmě pokud by se podařilo pakety správně pomocí pravidel rozházet mezi ty tabulky.

Každopádně Ondrovo řešení pomocí jmenných prostorů je daleko elegantnější, zaměřil bych se na to.

1474

Sítě / Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní

« kdy: 09. 02. 2021, 10:40:26 »

Při použití ip rule si musím pakety značkovat ve firewallu a tu značku pak použít v ip rule pravidlech nebo pravidla na port, proces atd. umí ip rule přímo?

Podívejte se na man ip-rule. Samo ip rule umí rozhodovat na základě IP adresy nebo rozhraní. A nebo pak může používat právě značky z firewallu.

1475

Sítě / Re:Jak oddělit a nezávisle adresovat jedno Wi-Fi rozhraní

« kdy: 08. 02. 2021, 17:05:42 »

Na linuxu se dají používat pravidla (ip rule) pro výběr routovací tabulky. Pokud dokážete sestavit pravidla, která budou schopna rozlišit komunikaci pro to jedno rozhraní, můžete použít to. Nenapsal jste, čím bude ta komunikace na tom jednom rozhraní specifická – zda třeba dokážete určit zdrojovou IP adresu, proces apod.

1476

Server / Re:Různé odpovědi pro různé klienty Dnsmasq

« kdy: 06. 02. 2021, 12:01:11 »

A jaky problem se tim snazis vyresit?

Žádný. Hamparle problémy neřeší, on je vytváří.

Všimněte si ostatních jeho „dotazů“ – z větší části to vůbec nejsou dotazy a končí na smetišti, ze zbytku ho většinou řešení nezajímá, a v těch několika málo případech, kdy se o řešení zajímá, zavrhne všechny návrhy na řešení a vymyslí si několik dalších problémů.

1477

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 18:04:15 »

Tak ono postaci nejake minimum (jedna sifra, jeden rezim), a protistrana se patricne nastavi.

Co konkrétně je to minimum a jak obtížné bude implementovat to?

Ohledne zbytku - bohuzel mam prakticke zkusenosti a onu hru na kocku a mys, kdy se bezpecnost zvysovala vsemoznym teoretickym zpusobem (padlo zde ve vlakne mnoho tipu a nic z toho opravdu nebyla prekazka), zastavilo az nasazeni specialniho biosu a sifrovanych medii, ktere pri jakemkoliv naznaku naruseni tripnou a vymazou klice. Proto kazdy, kdo to mysli s bezpecnosti vazne, nespoleha jen na sifry a metody, ale resi se to systemem bezpecnych enklav (to je ta moje pozadovana fyzicka bezpecnost) - HSM a pod.

Dokud si budete myslet, že je problém, když někdo získá veřejný klíč, jsou vaše pohádky o bezpečnosti k ničemu.

Jasně, k nějakému termostatu nebo dvířkům do kurníku ovládaným z mobilu si budou lidi pořizovat HSM.

Nejde o to, ze prolomeni muzete provest jednorazove na miste cinu - ale o to, ze po obfuskaci ("sifrovani") spojeni, bude dalsi nejslabsi clanek onen fyzicky endpoint. A kdo bude mit zajem.. si pro nej fakt prijde. Pak vam prijde treba reklamace, ze "sory, ono se z toho zakourilo", tak to vymenite. Ale po teto udalosti, treba uz ta bezpecna sit neni jenom vase.. protoze je v ni nekdo dalsi.

O žádné bezpečné síti ale nebyla řeč. To jste si zase jen vymyslel další nesmysl.

Prosím vás, představte si třeba krabičku u bojleru, která je schopná mi do mobilu hlásit aktuální teplotu vody a spotřebu elektřiny. A také umí na povel z mobilu ten bojler zapnout nebo vypnout – abych si mohl ohřát vodu před tím, než přijedu na chatu, a bojler mohl zase vypnout z domova, když zjistím, že jsem na to na chatě zapomněl. To je podle dosavadního popisu zhruba úroveň zařízení, o kterém se tu bavíme (možná bude ve skutečnosti o málo závažnější). Takže jde o to, aby mi hacker ten bojler nezapnul v listopadu a neohřívala se tam voda zbytečně několik měsíců, když tam nebudu. A aby mi zlomyslný soused nevypnul bojler půl hodiny po té, co jsem si ho zapnul před odjezdem na chatu. Pokud se někdo do té chaty vloupá, tak bojler zapne normálně knoflíkem na té krabičce, a nebude z té krabičky získávat šifrovací klíč, aby mohl hacknout komunikaci a zapnut ten bojler přes mobil. A určitě k tomu bojleru nebudu budovat vyhrazenou síť, pronajímat černé vlákno a klíč ukládat do HSM.

Myslim ze resit protokol samo o sobe je malo - jestli to chce mit autor bezpecnejsi, mel by o tom premyslet jako o celku.

Nemyslím si, že by to chtěl mít autor bezpečnější. Autor akorát nechce, aby si s tím zařízením mohl hrát každý desetiletý kluk z Číny.

1478

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 15:55:30 »

Pokud je si autor 100% jisty ze mu klice a kod neunikne, plus server i ta spousta zarizeni odola fyzickemu utoku (coz je v realnem nasazeni opravdu nemozne splnit), tak bude cesta nejmensiho odporu nasadit symetrickou sifru nad daty ve formatu  "pocitadlo+payload+checksum". Jestli to presune z aplikacni urovne nekam hloub do IP, tak z toho mame co? Zcela klasicky IPsec.

Takze nevymyslejte lamersky TLS ohejbak, kdyz to jde udelat zcela standardne, dokonce i s omezenymi zdroji ktere ta aplikace pry ma.

Vy tu pořád trousíte obecná rádoby moudra, ovšem vždy se prozradíte tím, že do toho zamontujete nějaký nesmysl. Já jsem původně rozporoval vaše tvrzení, že v případě asymetrické kryptografie je problém, pokud unikne kterýkoli klíč (tedy privátní nebo veřejný).

Teď zase plácáte nesmysly o úniku kódu – ne, ani já, ani _Jenda ani hazardrok jsme opravdu nikdy nenapsali nic v tom smyslu, že bude zabezpečení založené na tom, že bude utajená implementace bezpečnostních algoritmů. A také nesmysly o fyzické bezpečnosti klientů – každý klient bude mít svůj unikátní klíč, takže pokud unikne klíč jednoho klienta, budou použitelný pouze pro ovládání toho jednoho klienta. A pokud už někdo fyzicky ovládá toho klienta, nepotřebuje na něj útočit vzdáleně. To už vám tu ale vysvětlovalo opakovaně několik lidí.

Použití TLS jsem navrhoval hned od začátku, ale hazardrok nemá zařízení, na kterém by mohl použít existující knihovnu – a implementovat celé TLS od nuly by byla sebevražda.

No a to řešení cestou nejmenšího odporu s šifrováním symetrickou šifrou a zajištěním integrity pomocí HMAC se tu snažíme popsat.

Nápad použít IPsec je zajímavý (pokud jste tedy svým zašmodrchaným komentářem myslel tohle), nicméně implementovat IPsec není nic jednoduchého.

1479

Server / Re:Lze pomocí bluetooth přenosu a přemostění na server udělat provizorní JIP?

« kdy: 05. 02. 2021, 15:49:35 »

Dokázal bych si představit použití paragrafu o krajní nouzi v situaci "Itálie na jaře", a budu pevně doufat, že tak daleko to u nás nedojde.

Závidím vám váš optimismus, že to u nás v takovém stavu ještě není.

1480

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 13:21:37 »

Tomu se říká mac-then-encrypt a umožňuje to například padding oracle útoky.

Jejich podmínkou je, že útočník může ovlivnit obsah otevřeného textu (zprávy před zašifrováním), ne?

Jinak ale platí to, co jsem psal výše – všeobecně používaná schémata (jako třeba TLS 1.3) mají spoustu ochran proti různým útokům postranním kanálem. Jakmile se někdo rozhodne z jednotlivých komponent poskládat vlastní schéma (jako teď děláme), určitě tam bude spousta děr umožňujících útok postranním kanálem. V podstatě jde jen o tom, nepřehlédnout nějakou opravdu základní chybu (což my dva neuděláme, kdyby nic jiného, tak proto, že neznáme přesný scénář použití – že útočník nemůže v tomto případě ovlivnit otevřený text zprávy je jen moje domněnka, nemám to potvrzené od tazatele) a pak doufat, že ty díry, které tam určitě jsou, nebudou v tomhle případě nikomu stát za zkoumání. Je v tom holt kus security through obscurity.

1481

Server / Re:Lze pomocí bluetooth přenosu a přemostění na server udělat provizorní JIP?

« kdy: 05. 02. 2021, 12:25:02 »

A to se řešit dá i jinak. Například stavební úpravou pokoje (okno..), kamerou, neustálou přítomností sestry, vytvořením dohledového pracoviště blíže (aby alespoň slyšeli, že něco pípá), atd..

Chápu, takže netušíte, co se kolem děje. V nemocnicích teď podle vás mají spoustu volného místa, takže je ideální čas na to něco tam bourat a zdít. A nebo tam aspoň mají spoustu sestřiček, které se nudí. Já teda mám úplně jiné zprávy.

Ale máte pravdu v tom, že pokud pacient zemře, protože už pro něj nebylo místo na JIP, nehrozí už u něj to, že by došlo k úrazu elektrickým proudem nebo ke komplikacím způsobeným infekcí.

Něco tam bastlit s Raspberry Pi a podobně je opravdu nemožné. Pořád je to nemocnice.

Svým způsobem vám to závidím, že si myslíte, že nemocnice zvládají všechno v pohodě a ještě mají rezervy, aby zvládly další covid případy, vše naprosto podle norem, bez přetěžování zdravotnického personálu.

Jedna vec je podomacku udelana rouska z bavlny nebo z kusu plexiskla udelanej stit, druha vec je elektricke zarizeni primo pripojene na pacienta nebo zivotni funkce monitorujici.

A třetí věc je, že máte pacienta, u kterého by bylo monitorování životních funkcí vhodné nebo dokonce nutné – a máte na výběr, zda je nemonitorovat vůbec, protože další zařízení podle norem už není k dispozici, nebo je monitorovat alespoň něčím, co nesplní normy, ale jakž takž to funguje.

Všimněte si, že jsem hned na začátku psal, že pokud by takové zařízení víc nefungovalo než fungovalo, napáchá víc škody než užitku. Ale pokud by nějak rozumně fungovalo, dává smysl ho použít, pokud profesionální zařízení splňující všechny normy nebudou k dispozici.

1482

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 11:25:38 »

zkusim to tedy jeste jednou bodove (neresim replay attack ani korektnost zdrojaku, ktere hodlam pouzit):
1. vygeneruju nahodny IV, mam klic '256bit', zasifruju zpravu metodou CTR(je pro me pohodlnejsi nez CBC), vznikne ciphertext (https://github.com/kokke/tiny-AES-c)
2. pres IV a ciphertext provedu hash SHA-256, vznikne HMAC (https://github.com/B-Con/crypto-algorithms)
3. ciphertext + IV + HMAC odeslu pres TCP

4. prijmu paket rozdelim ho na ciphertext + IV a HMAC
5. opet provedu hash SHA-256 a overim tim integritu dat...nyni muzu predpokladat, ze utocnik data nezmenil, nebo je zahodim protoze overeni se nepodarilo
6. z ciphertext a IV ziskam desifrovanim pomoci klice '256bit' plaintext
7. otevru dvere, protoze nastal utok typu replay attack...a zacinam odznova

Uteklo mi principielne jeste neco? Mozna je na to pozde, ale moc diky klukum co do tohodle vlakna prispivaj hlavne Filip Jirsák a _Jenda. To co jste tu zatim popsali, tak na to bych urcite sam nikdy neprisel. A ani bych se to nikde nedocetl, protoze takhle velkej rozsah rozhodne nemam a kdyz si to nemuzu osahat sroubovakem, tak mi to spise prijde abstraktni, jak obrazky od dcery

Připadá mi zbytečné hashovat tu zašifrovanou zprávu, protože to samé může udělat i útočník – má k tomu všechny potřebné informace. Raději bych hashoval přímo zprávu (spolu s klíčem) a teprve zprávu+hash bych šifroval. HMAC má smysl používat tehdy, pokud do hashované zprávy můžete přidat něco, co útočník nezná. Když pak hash ověříte, máte jistotu, že ho musel vytvořit odesílatel a ne útočník.

1483

Server / Re:Lze pomocí bluetooth přenosu a přemostění na server udělat provizorní JIP?

« kdy: 05. 02. 2021, 11:10:58 »

Na důležité JIP / ARO si telefon do zásuvky opravdu nedá. Telefon navíc nepřipojíte dlouhodobě přímo k tělu.

Na důležité JIP/ARO ovšem dávno potřebné přístroje jsou. Tady se bavíme o provizorní JIP vybudované z běžných oddělení.

A samozřejmě se to ještě liší tím, kdo za to nese zodpovědnost.

Ano.

Nevyhraje. Žádné informace znamenají, že musí kontrolovat přímo přístroj (třeba sedět blíže, nebo změnit organizaci práce na oddělení). Špatné informace mohou způsobit, že si bude myslet, že je vše v pohodě a něco se stane.

Jasně, přijmou další lékaře a sestry. Protože jich je všude spousta volných. Prosím vás, sledujete alespoň trochu, co se kolem děje? Zaznamenal jste, že existuje cosi jako covid-19?

Pokud je přístrojů málo, může dojít k nouzovému schválení něčeho nového (jako třeba CoroVent https://cs.wikipedia.org/wiki/CoroVent). Ale to schválení k provozu je nutné.

Mimochodem jste úplně ignoroval problematiku čištění a infekcí. A u pacientů na JIP / ARO se sakra snažíte, aby nechytili ještě něco navíc.

Vy zase úplně ignorujete situaci, v jaké se nacházíme.

1484

Vývoj / Re:TCP bezpečnost

« kdy: 05. 02. 2021, 10:56:36 »

A tohle je to obri zdani bezpecnosti. Vy falesne duverujete necemu, co vam klient rekne - klidne muzete mit nejaky malware (ci antivirak), ktery se vam vlozi do sitove komunikace, prebali to SSL na jinak podepsany, podvrhne CA.

Tak ještě jednou a pomaleji. Když mám v ruce krabičku, ze které vedou dráty pro ovládání otevírání a zavírání dveří, nebudu složitě hackovat software v té krabičce, ale prostě se připojím přímo na ty dráty a tu krabičku úplně obejdu.

Pořád řešíte problémy, které nikdo řešit nechce.

1485

Server / Re:Lze pomocí bluetooth přenosu a přemostění na server udělat provizorní JIP?

« kdy: 05. 02. 2021, 08:33:26 »

- Připojit rPi drátem k senzorům u pacienta je dost dobře nemožné, nemá to žádný atest na elektrickou bezpečnost a je to vlastně připojené přímo do sítě (to rPi potřebuje zdroj).

Čím se to liší od situace, kdy si do té zásuvky pacient dá nabíječku na svůj mobil?

Navíc když už jsme v situaci, kdy se někde rozhoduje, kterému pacientovi věnovat potřebnou péči a kterému ne, to rozhodování je jiné. Pokud se rozhoduje o tom, zda lékař nebude mít žádné informace nebo alespoň ne příliš nespolehlivé informace, vyhraje ta druhá volba.