Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Filip Jirsák

Stran: 1 ... 64 65 [66] 67 68 ... 375
976
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 01. 10. 2021, 21:30:43 »
Nejjednoduší je, pokud ISP zařídí filtrování na svém DNS, který defaultně poskytuje svým klientům přes DHCP.

Je to velmi jednoduché. Pokud už musím, rozhodně jako to nejhorší invasivní řešení mohu zvolit, že budu unášet provoz, abych to zkurnil co nejvíc, nebo jen ovlivňovat vlastní DNS.
Vidím, že tady mezi mnohými panuje shoda, že každý ISP má a měl vlastní DNS servery, které vždy nastavoval a nastavuje svým klientům jako výchozí DNS resolvery (ať už přes DHCP, nebo napevno).

Zajímala by mne už jenom taková drobnost: Jak jste na tohle přišli? Na základě čeho vylučujete, že by v ČR mohly existovat ISP, kteří neměly nebo nemají vlastní DNS resolvery a nemají tak kontrolu nad tím, kam posílá DNS dotazy velká část nebo dokonce všichni jejich klienti?

977
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 01. 10. 2021, 20:35:26 »
Jak se dojde k tomu, že zrovna tahle metodika je ta platná? Když si vydám svoji metodiku, nebude to rovnocenné?
Jde o metodiku Ministerstva financí. Které je příslušné k rozhodování ve správním řízení, pokud by nějaký ISP zákon nedodržoval. Takže ta metodika má určitou váhu – je to návod pro úředníky MF, jak mají postupovat v případném správním řízení. Ale není závazná, pokud by nějaký úředník postupoval v rozporu s tou metodikou, může být postižen pracovněprávně, ale na vydaném rozhodnutí to nic nezmění.

Unášení provozu je prasárna pokud to není požadováno. Akorát to může zbytečně rozbít věci co fungují.
To je sice hezký názor, ale tak nějak se míjí s realitou. Ono totiž unášení provozu opravdu není zákonem explicitně vyžadováno, zároveň to může být ten nejjednodušší a nejméně invazivní způsob, jak zákon splnit. Ale to už jsem psal několikrát a nezdá se, že byste tuhle informaci vzal na vědomí, takže opakovat ji příště znova nemá smysl.

978
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 01. 10. 2021, 15:43:24 »
Nejde o ignorování zákonů, ale ignorování Vašeho výkladu zákona. Až o tom bude někdy rozhodnuto soudy, uvidíme. Do té doby, tu jen teoretizujeme.(a Vy jste, jako vždy přesvědčen o tom, že znáte všechno nejlépe)

Unášení provozu je prasárna, za tím si stojím, ať už předhodíte sebelepší/sebeblbější argument.
Jasně. Já uvádím argumenty, vaše tvrzení je akorát „je to prostě prasárna“, ale já jsem přesvědčen, že znám všechno nejlépe…

979
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 01. 10. 2021, 11:52:25 »
A co ten zákon po ISP vladtně chce? Jedna věc je, pokud se poskytovatele zeptám, kde se nachází hazardní server, a on mi odpoví že neví. Druhá věc je, pokud se chci zeptat někoho třetího, ale poskytovatel zprávu s dotazem nenápadně zastaví a vrátí falešnou odpověď, že neví (ačkoli skutečný adresát by věděl). Není tohle náhodou porušení listovního tajemství (ISP není nic do toho, jaký je obsah paketů které odesílám/přijímám), které lze prolomit pouze v přesně definovaných případech a vždy se soudním povolením?
Zákon o hazardních hrách má v tomto případě přednost před listovním tajemstvím.

Zákon po ISP chce „zamezit v přístupu k internetovým stránkám uvedeným na seznamu“ vydávaném Ministerstvem financí. V zákoně tedy není nic o tom, že stačí, když bude ISP řešit jen jím přímo poskytované informace.

Navíc jak už jsem psal dříve, někteří malí ISP neprovozovali vlastní DNS server a zákazníkům nastavovali třeba 8.8.8.8. Těm nic jiného než unášení DNS provozu nezbývá.

980
Vývoj / Re:XSLT 1.0 - Distinct
« kdy: 01. 10. 2021, 09:36:40 »
Tohle jdbc:CatalogNumber[not(preceding::jdbc:CatalogNumber = .)] vrací elementy CatalogNumber, jejichž obsah se liší od všech předchozích elementů CatalogNumber. Vy ale v podmínce nechcete seznam těch elementů, chcete zjistit, jestli takový element existuje či neexistuje. Takže byste tam měl použít count(jdbc:CatalogNumber[not(preceding::jdbc:CatalogNumber = .)]) eq 0.

981
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 01. 10. 2021, 09:32:35 »
Vždy, když vidím pana Jirsáka, jak tu fabuluje, vykouzlí mi to usměv na tváři a údiv nad tím, jakým způsobem může někdo přemýšlet.
Mně zase rozesmutní, když se přiznáte k tomu, že vás udivuje, když se někdo snaží dodržovat zákony.

Unášení provozu, je naprosto to a samé, jako regulérní podvod.
Naprosto to samé jako co? Podvod to určitě není, podvod je definován jinak.

Představte si, že chcete po pošťákovi(ISP), aby donesl balíček(packety), na předem danou adresu(IP)..
On balíček zabaví, odešle někomu naprosto jinému, shrábne prachy a ještě se tváří, že všechno udělal v pořádku...
Dostal jste někdy zásilku ze zahraničí? Všiml jste si, že pošťák tu zásilku zabaví, odešle ji na celní úřad, shrábne prachy a pak se tváří, že udělal vše v pořádku?

Holt vaše teoretické představy neodpovídají tak docela tomu, jak to funguje v reálném státě.

Prostě a jednoduše, na unášení provozu, je ze své podstaty špatně naprosto všechno.
Tím, že před svůj názor dáte slovo „prostě“, z toho neprůstřelný argument neuděláte. Máme tu nějaké zákony, kterými se ISP musí řídit, ať se mu to líbí nebo ne. Vaše okázalé ignorování těchto zákonů v diskusi na tom nic nezmění.

982
Vývoj / Re:XSLT 1.0 - Distinct
« kdy: 30. 09. 2021, 20:11:26 »
V takovémhle případě bývá užitečné si pomocí xsl:message vypsat, které elementy jsou vlastně v té kolekci.

Jinak v té podmínce asi chcete zjišťovat, zda ty elementy se stejnou hodnotou existují či neexistují. Normálně bych použil funkce exists() nebo empty(), ty jsou ale v XPath až od verze 2. Tak místo toho můžete porovnávat count() s nulou. Porovnání Parent-LU-MG s prázdným stringem je také divné, pokud chcete zjistit, zda je element prázdný, raději použijte count(jdbc:Parent-LU-MG/node()) eq 0.

983
Vývoj / Re:XSLT 1.0 - Distinct
« kdy: 30. 09. 2021, 18:59:34 »
Na spočítání počtu prvků v sekvenci slouží funkce count().

984
Vývoj / Re:XSLT 1.0 - Distinct
« kdy: 30. 09. 2021, 18:43:24 »
Funkce position() vrací pořadí prvku v aktuálně procházené sekvenci. Element for-each nastavuje aktuálně procházenou sekvenci na to, co je určené atributem select. Vy si tedy vytvoříte sekvenci unikátních řádků a zjišťujete pozici v rámci této sekvence.

985
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 30. 09. 2021, 15:16:57 »
1. třeba proč vytváří SPOF pro DNS?
To je jen vaše domněnka, že to tak je.

Unášením DNS na nějaký transparentní DNS u jednoho poskytovatele může znamenat nefunkčnost když to umře.
Může a také nemusí – když při umření vlastních DNS serverů přestane dotazy unášet.

Když budu chtít vlastní rekurzivní DNS server, tak opět zde mohou vznikat chyby.
Nemyslím si, že s tím vlastní rekurzivní server nějak souvisí.

2. proč dělají něco navíc než se po nich chce dle mtodiky
Chápu argument, že vyhovují i takto zákonu. Ale tento po nich navyžaduje.
Metodika říká, filtrovat na svých DNS rekurzorech či svého nadřízeného poskytovatele.
A není třeba řešit obchazení uživatelem, např. přes VPN apod. To samé chápu pro jiné DNS servery.
Jak píše _jenda, v ČR jsou závazné zákony, ne metodiky. Jestli to po nich zákon vyžaduje nebo nevyžaduje zatím s jistotou nevíme, ještě o tom nerozhodoval soud (a ani pak to nebude 100% jisté). To, že vy něco preferujete, neznamená, že to musí preferovat všichni. Třeba je to takhle pro toho ISP jednodušší. Třeba ISP dříve nastavoval svým klientům jako DNS servery nějaké otevřené resolvery, třeba ty od Googlu, a teď jim nezbývá, než to řešit takhle.

No, nepoužívám. Nějak jsem žil v představě, že ISP nebudou dělat něco, co po nich metodika nechce. I vzhledem
k tomu, že ten požadavek je technicky blbost a dá se lehce obejít. Chyba.
Metodika se dá obejít ještě snáz, spousta klientů ji může obcházet vlastně nechtěně. Proto je otázka, zda postup podle té metodiky vůbec vyhovuje zákonu.

Pokud mám DNS jako 8.8.8.8 a vidím něco jiného, tak je pravděpodobné, že do DNS něco šahá.
Zrovna muticastové adresy používat jako zdroj DNS dotazů není dobrý nápad, protože odpověď může dostat někdo úplně jiný, než kdo se ptal. Takže to, že dotaz vyřizuje jiná IP adresa, než které jste se původně ptal, nemusí znamenat nic divného.

Od té specifikace jak to dělat je metodika.
Ne, metodika je jenom nezávazné doporučení. Mělo by se jí řídit samotné Ministerstvo financí, které je v této věci správním orgánem, takže je dost pravděpodobné, že v případném správním řízení by postup podle té metodiky prošel. Ale zaručené to není. A i tak se to může dostat před sou, který tou metodikou nebude vázán vůbec. Pak už by zbýval jenom argument, že jste v dobré víře postupoval podle té metodiky, což by pravděpodobně mělo vliv na to, jak by soud jednání hodnotil. Ale závazné to není.

986
Odkladiště / Re:Unášení DNS provozu a hazard
« kdy: 28. 09. 2021, 18:19:02 »
Co byste na tom s nimi chtěl řešit? To jejich řešení odpovídá zákonu, z pohledu zákona dává dokonce větší smysl, než řešení podle metodického pokynu. Navíc ten metodický pokyn není právně závazný, tj. ISP postupující podle něj by teoreticky nemusel ve správním řízení uspět.

987
Sítě / Re:Domain fronting - vysvětlení rozdílu dvou typů
« kdy: 24. 09. 2021, 16:22:57 »
V obou případech klient komunikuje za sítě, kde je cenzura, s CDN, a v SNI hlavičce pošle název nějakého zdroje umístěného v dané CDN, který je z pohledu cenzora v pořádku. Zároveň klient spoléhá na to, že CDN nebude kontrolovat shodu SNI názvu a domény uvedené v HTTP hlavičce Host.

Typ popsaný v prvním odstavci funguje tak, že v hlavičce Host pošle rovnou doménové jméno cílového (cenzurovaného) serveru. Takže třeba v SNI je název encyklopedie-marxismu-leninismu.cn, ale v Host je hk.wikipeida.org. Pokud CDN nekontroluje, zda má obsluhovat doménu hk.wikipeida.org (funguje vlastně jako otevřená proxy – zajímalo by mne, zda tak nějaká používaná CDN opravdu funguje), pošle sama dotaz na webserver hk.wikipeida.org, nakešuje výsledek a vrátí ho klientovi.

Reflektor v tomhle případě není potřeba proto, že CDN neověřuje, jestli doména požadovaná klientem v hlavičce Host je zákazník dané CDN. Pravděpodobně spoléhá na to, že k tomuhle ověření došlo už na základě SNI – pokud doména v SNI není zákazníkem CDN, nemá pro ni CDN certifikát a tím pádem normální HTTPS klient nenaváže spojení.

Pokud CDN nefunguje jako otevřená proxy, tohle by nefungovalo – CDN by na dotaz na doménu hk.wikipeida.org odpověděla, že takovou adresu nezná. Pak se může použít druhá varianta, že se do komunikace přidá ještě reflektor. Ten obsluhuje nějakou doménu, která je regulérně hostovaná v té CDN, takže třeba my-hk-wikipedia.eu. Klient pak v Host hlavičce musí poslat tuhle speciální doménu, CDN se dotáže reflektoru na příslušnou stránku – a reflektor se zeptá na stejnou cestu ale v doméně hk.wikipeida.org. Tj. reflektor vlastně vytvoří duplikát webu na jiné webové adrese. Kdyby se používala přímo tahle adresa, cenzor ji také zablokuje, ale tím, že to jde přes CDN a v SNI je jiná doména, cenzor nezjistí, o jaký požadavek se jedná. A ta speciální adresa naopak zajistí, že si ji můžete „povolit“ na CDN. Reflektor je tam tedy potřeba z toho důvodu, pokud CDN kontroluje, že stahuje obsah jenom od svých zákazníků, a zároveň nemůžete zařídit, aby cílový web byl (třeba alespoň na oko) zákazníkem dané CDN.

988
Máte tušení, čím ten kabel asi může vést? Pokud by se dalo očekávat, že nebude někde držet, nebylo by nejlepší použít ho jako lanko a zatáhnout pomocí něj normální ethernetové lanko?

989
Software / Re:Komunikace se čtečkou karet z webu
« kdy: 20. 09. 2021, 09:47:52 »
Ta vaše aplikace obsahuje jenom obsah, kterému můžete 100% věřit? Nestahuje externí skripty, styly, obrázky, fonty? Nemohou tam uživatelé nahrávat vlastní obsah? Nedokáže ji nikdo přes DNS přesměrovat jinam? Nebude ověřovat HTTPS certifikáty? Nebudou tam žádné odkazy na externí weby?

Z uživatelského hlediska tam uživatelé nebudou chtít používat záložky, taby, nebudou chtít tisknout? To všechno byste totiž musel naimplementovat.

Pokud nechcete dělat rozšíření do prohlížeče, protože máte špatnou zkušenost s aktualizacemi prohlížeče, připadá mi použití embeddovaného jádra prohlížeče jako z deště pod okap.

Ohledně způsobu implementace toho serveru – aplikaci můžete nastartovat i z prohlížeče, akorát to uživatel musí tlačítkem potvrdit. Takže pokud uživatelům nebude vadit, že musí při prvním použití karty v rámci přihlášení k Windows odkliknout spuštění, není služba potřeba. Osobně bych se spíš snažil službě vyhnout – běžná služba ve Windows nemá přístup k sezení aktuálně přihlášeného uživatele, takže by se např. nezobrazil dialog pro zadání PINu k certifikátu.

990
Software / Re:Komunikace se čtečkou karet z webu
« kdy: 19. 09. 2021, 21:16:21 »
Nejmenší zlo asi je mít vlastní aplikaci, které komunikuje se čtečkou a zobrazuje nějakou webovou stránku.
(Tj. uvnitř aplikace běží jádro prohlížeče.)
Tak mi to "teď" připadá.
Nebo se pletu  :(  ???
To ovšem budete muset to jádro prohlížeče v aplikaci neustále aktualizovat, aby v něm nebyly bezpečnostní chyby. Připadá mi zbytečné tahat do aplikace jádro prohlížeče, když jenom potřebujete v prohlížeči něco zobrazit. Jednodušší je standalone prohlížeči jenom poskytnout z té aplikace data – buď přímo (že ta aplikace bude zároveň web serverem), nebo nepřímo (aplikace data pošle web serveru, který je pošle prohlížeči).

Stran: 1 ... 64 65 [66] 67 68 ... 375