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 ... 18 19 [20] 21 22 ... 375
286
ISP nemusí být vůbec žádný šmudla, protože provoz ve vlastní síti není potřeba zbytečně komplikovat, což se týká hlavně lokálních ISP. A sotva někdo z ISP předpokládá, že se na straně usera s veřejnou IP najde správce, který se jen tak rozhodne blokovat přístup z neveřejných adres, což je podstatou celého problému.
Ne, není to podstatou problému. Podstatou problému je to, že ISP nedělá u DNATu veřejných adres také SNAT pro své klienty. Kdyby to dělal, bude uživatel s „veřejnou“ IP adresou (ona je to ve skutečnosti veřejná IP adresa DNATovaná na zákazníkovu privátní adresu) dostávat provoz od ostatních klientů téhož ISP s IP adresou NATu ISP – což klidně může být veřejná IP adresa.

Mimochodem, to, že ten ISP neroutuje veřejné IP adresy, ale NATuje je, dělá právě proto, že si nechce síť zbytečně komplikovat a mít v síti s privátním IP adresami rozházená zařízení s veřejnými adresami.

To, že uživatel blokuje privátní IP adresy přicházející z WAN je naprosto v pořádku. Vždyť může mít ty samé adresy i na straně LAN, tak jak by pak poznal, kam má tu adresu routovat?

287
Banka řeší nesmysl, místo toho aby se zaměřila na vzdělávání uživatelů
Naopak, banka se zaměřuje na vzdělávání uživatelů. Nejdůležitější bod vzdělávání uživatelů je: Používejte aktualizovaný a podporovaný software. To je to naprosto nejdůležitější, bez toho to nejde.

288
Zkuste, milý pane Jirsáku, konečně přestat vytrhávat z kontextu to, co se vám hodí a reagovat na všechno, co člověk napsal a ne jen na to, co vám vyhovuje.
A vy zkuste nepoučovat ostatní o věcech, které nechápete. Já jsme nic z kontextu nevytrhl.

na bance je, aby si určila, že chce TLS 1.3 ale nic jí není po tom z jak nebezpečného stroje budu k jejich bankovnictví přistupovat. Z principu nic. Ona si má říci, jaké technologie pro zabezpečení vyžaduje a pokud je neschopná to udělat, je důvod ji změnit.
Bance do toho je samozřejmě hodně, za prvé ze zákona, za druhé proto, že když klientovi vyluxuje účet útočník, bude klient samozřejmě nadávat na banku a bude chtít peníze zpět po bance. Banka si říká, jaké technologie pro zabezpečení vyžaduje – první věc je používat aktualizovaný a podporovaný software.

Ale rozhodně vy nejste od toho, abyste říkal co je lepší pro něj a ani se na to neptal. Neste od toho ani vy, ani vám podobní, co tak rádi v některých institucích dělají blbce z ostatních.
Vy rozhodně nejste od toho, abyste mi psal, co mám a nemám psát.

A psal jsem vám to už mnohokrát, napíšu vám to znova – zkuste před tím, než něco napíšete, přemýšlet. A nevytýkat ostatním něco, co sám tím vytýkáním děláte.

"My víme, co je pro vás lepší". Ne, nevíte to, Jirsáku. Vy tak maximálně můžete vědět, že TLS 1.3 je lepší než TLS 1.0. To je v pořádku.
Neposuzujte ostatní podle sebe. Vy to vědět nemůžete, to je pravda. Což ovšem neznamená, že to nemůže vědět někdo jiný, třeba já (a mnozí další).

289
Našel jsem na našem firewalu pravidlo zákazu přístupu na WAN port z privátních adres. To by asi mohlo klientům na privátních adresách služby zpřístupnit.
Ne, tohle by nestačilo. Abyste klientům na privátních adresách služby zpřístupnil, musel byste zprovoznit split-horizon DNS – tj. těmhle klientům byste musel poskytovat privátní adresu vašeho serveru, ne veřejnou. Pak by komunikovali přímo s vaším serverem v rámci privátní sítě toho ISP (pokud to ISP dovolí). Tj. provoz by nešel přes NAT vašeho ISP, takže by nemohl k…azit provoz.

(Další možnost by byla natvrdo u vás přepisovat privátní adresy klientů na IP adresu NATu ISP, ale to to už by byla tak hrozná prasárna, že si to ani nechci představovat.)

Správné řešení je, ať si ISP spraví svůj DNAT, kterým vám přiděluje veřejné IP adresy – tj. ať počítá s tím, že s tou veřejnou IP adresou chtějí komunikovat i ostatní klienti jeho sítě a udělá pro ně i SNAT.

290
Ten dotaz je nějaký divný... Proč by se user s neveřejnou IP nemohl dostat na IP veřejnou? To jde úplně normálně (opačně pochopitelně nikoliv)
Dotaz není divný. Pokud je ISP nějaký šmudla, který prostě schová své zákazníky za NAT a veřejenou IP adresu svým zákazníkům udělá DNATem, chová se to přesně takhle. Aby to fungovalo, musí vedle DNATu veřejné IP adresy dělat i SNAT zákaznických adres, aby se paket s odpovědí dostal zpět na router/NAT. Bez toho de paket s odpovědí snaží jít přímou cestou (protože cílová adresa je ve stejné síti, jako zdrojová – obě jsou to privátní adresy za NATem), tudíž neproběhne „odNATování“ paketu a počítač klienta dostane „odpověď“ od serveru, kam nic neposílal – bude tam privátní adresa serveru a ne veřejná.

291
Spíš bych doporučoval změnit banku.
Jak přesně změna banky způsobí to, že bude bezpečné používat počítač připojený k internetu s dávno nepodporovaným OS, nepodporovanou verzí prohlížeče – a to celé používat pro přístup do banky?

I kdyby neřešil nový OS na starém počítači ale opravdu kupoval nový počítač – záleží na tom, kolik má na tom účtu peněz. Pokud je tam na nový počítač a něco zbyde, je lepší pořídit nový počítač, než přijít o všechny peníze při nějakém útoku a nemít nic. A pokud je tam méně, než na nový počítač, je pořád lepší ten zůstatek darovat nějaké neziskovce a účet zavřít než darovat zůstatek útočníkům a účet zavřít.

292
Změnil bych banku.
Já bych teda na místě tazatele změnil verzi operačního systému a také přístup k bezpečnosti. Přístup do banky je podle mne dost riziková operace a lézt tam z dávno neaktualizovaného operačního systému je dost velké riziko.

293
Vývoj / Re:Eventualna konzistencia CQRS aplikacii a UI
« kdy: 06. 01. 2023, 10:46:40 »
Řešení je spousta, záleží na vašem technologickém stacku. Třeba u SPA aplikací je běžné, že má aplikace v prohlížeči cache, kde má seznam článků. Při odeslání článku se článek přidá i do té lokální cache, třeba i s příznakem, že jde o provizorní záznam. Při přechodu na stránku se seznamem článků se pak použijí údaje z cache a na pozadí se dotáhnou aktualizovaná data. I s tím můžete pracovat a ten provizorní záznam v cache ponechat do té doby, dokud nepřijde jeho aktualizace ze serveru.

Pokud byste v prohlížeči neměl takovouhle cache, můžete seznam článků vracet rovnou v odpovědi na přidání článku – a do toho seznamu můžete opět uměle přidat ten nový článek.

To, jestli uživatel má nebo nemá vidět nový článek ve výpisu, když nesplňuje podmínky filtru, je věc UX a je to nezávislé na technologii – smysl dávají obě možnosti, záleží na konkrétním způsobu použití.

Já bych to začal řešit nejdřív na straně UX. To, že trvá tak dlouho, než se nový záznam objeví v DB pro čtení, se děje často? Pokud ano, neměl by uživatel spíš vidět, že se záznam teprve ukládá? Tj. že by měl někde na stránce notifikaci nebo seznam běžících úloh a tam by viděl, že se článek teprve ukládá? Protože jedna věc je, že se dá článek podvrhnout do následujícího výpisu, ale pokud to ukládání může trvat déle, může uživatel přejít někam dál, kde už mu to podvrhnout nedokážete. Nebo dokonce může stihnout informovat o tom jiného uživatele, který ten článek neuvidí. Pokud něco takového hrozí, dává smysl spíš to uživateli přiznat, že ukládání trvá déle a ještě probíhá.

294
Vývoj / Re:Automatizovaná pravidelná platba kartou
« kdy: 22. 12. 2022, 18:55:22 »
Založit si Revolut, propojit s kartou, nastavit auto top-up a zadat v Revolut trvalý příkaz (ideálně na účet, se kterým je svázaná karta - pak budou penize chodit automaticky dokola a zadarmo).
Určitě, ať to banka nemá zbytečně komplikované při dokazování, že jsou to fiktivní výběry.

Ale autorův postup je mazaný. Spočítal si, že kdyby to řešil sám, vyjde ho to dráž, než kolik těmi opakovanými platbami ušetří. Tak řešení problému ousourcoval do diskuse, a zkouší, jestli to někdo zadarmo vyřeší za něj.

295
Vývoj / Re:Designing Domain specific language
« kdy: 21. 12. 2022, 20:13:41 »
Practical API Design od Jardy Tulacha. Případně API Design Patterns.

296
Windows a jiné systémy / Re:SSL certfikát pro provoz PLM
« kdy: 20. 12. 2022, 17:39:48 »
Trochu se v tom ztrácím. Máte PLM terminály, na kterých běží prohlížeč Chrome, který se připojuje k ERP jako k běžné webové aplikaci přes HTTPS (resp. teď tam asi máte HTTP a potřebujete přejít na HTTPS). Je to tak?

Pak je nejjednodušší před ten ERP systém dát reverzní proxy, která zajistí HTTPS a provoz bude dál směrovat na to ERP (nešifrovaným HTTP). Takže komunikace z Chrome k reverzní proxy bude šifrovaná, Chrome bude spokojen, a na ERP nemusíte vůbec sahat.

Programů, které budou fungovat jako reverzní proxy, je na výběr více. Osobně doporučuju Caddy server – HTTPS tam máte už ve výchozím nastavení bez jakékoli konfigurace (pokud máte veřejnou IP adresu), bude automazticky vydávat certifikáty od Let's Encrypt. Přesměrování provozu zařídí asi tak jeden řádek konfigurace, nebo dokonce jen parametry při spuštění: Caddy reverse proxy.

Pokud tam nemáte veřejnou IP adresu, bude potřeba trochu konfigurace, aby měl Let's Encrypt možnost ověřit doménu – dá se to udělat dvěma způsoby, buď dokážete někam ven vytáhnout server pro příchozí komunikaci na portu 80, a přesměrovat ji na Caddy, nebo se to dá řešit ověřováním přes DNS.

297
Server / Re:Provoz po HTTPS v produkci
« kdy: 15. 12. 2022, 20:27:07 »
A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.
Zapomněl jsem napsat, že tohle odpovídá situaci, když se certifikát certifikační autority dostane na seznamy všeobecně uznávaných certifikačních autorit.

298
Server / Re:Provoz po HTTPS v produkci
« kdy: 15. 12. 2022, 20:17:05 »
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
To, co jste popsal, odpovídá tomu, když si Let's Encrypt vystaví certifikát třeba pro svůj web letsencrypt.org – a když se podíváte, opravdu je certifikát certifikát s předmětem CN = lencr.org, který má v SAN i letsencrypt.org, vydaný (zprostředkovaně) autoritou LE, tj. ověřovací cesta vede až k ISRG Root X1. To je ale jiný certifikát, můžete si porovnat jejich veřejné klíče. Existují tedy dva certifikáty (ve skutečnosti jich je podstatně víc), jeden je certifikát certifikační autority Let's Encrypt (který je self-signed, ale zároveň ke stejnému klíči existuje křížově podepsaný certifikát od „Digital Signature Trust Co.“, ale to radši neřešte), druhý je certifikát webu letsencrypt.org, který je shodou okolností podepsaný certifikační autoritou Let's Encrypt.

Když to popíšeme na tom vašem příkladu, bavíme se o situaci, kdy Franta ještě není předseda. Může si klidně sám sobě podepsat papír, že je předseda a může podepisovat průkazky, ale ten papír nebude mít žádnou váhu, nikdo mu nebude věřit. Teprve když to odhlasují Pepa a Lojza, začnou mu oni dva věřit, že je opravdu předseda a budou věřit jím podepsaným průkazkám. To je jako když si vyrobíte svou soukromou CA. A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.

A proti tomu stojí situace, když si budete vydávat self-signed certifikáty. To je jako kdyby si Franta podepsal průkazku sám a oběhl všechny okolo, že tohle je platná průkazka a mají jí věřit. Pak si Pepa podepíše sám svou průkazku a zase oběhne všechny okolo, že mají té průkazce věřit. A pak si podepíše svou průkazku i Lojza, a zase oběhne všechny okolo, že mají té průkazce věřit.

Pokud vás problematika certifikátů a PKI (public key infrastructure) zajímá, doporučuju např. knížku Velký průvodce protokoly TCP/IP: Bezpečnost. Na Rootu na ní kdysi vyšla recenze: recenze. Sice je starší, ale tam popsané principy jsou stále platné.


299
Vývoj / Re:Ako na notifikacie mobilneho klienta z webu?
« kdy: 15. 12. 2022, 15:01:51 »
Teraz som cital nieco o tom ze na adroide idu tieto notifikacie iba s pouzitim google firebase a teda nutnost pouzitia gogole cloudu. Je to naozaj tak?
Nikoli. Google Firebase je jedna ze služeb, která poskytuje notifikace nativním aplikacím. Push API je obecné API v prohlížeči, které implementuje tvůrce prohlížeče. Ono to pro Chrome nakonec přes Google půjde, ale pro autora webové stránky je to transparentní, ten používá to obecné API.

300
Server / Re:Provoz po HTTPS v produkci
« kdy: 15. 12. 2022, 11:40:35 »
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
Vše X.509 certifikáty se dají rozdělit do dvou disjunktních skupin – certifikáty podepsané certifikační autoritou a self-signed certifikáty. To označení „self-signed certifikát“ vzniklo právě proto, aby existovalo jednoduché označení pro „certifikát nepodepsaný certifikační autoritou“.

Kořenový certifikát certifikační autority logicky nemůže být podepsaný certifikační autoritou, protože v době, kdy ten certifikát vzniká, neexistuje ještě ten certifikát certifikační autority (protože právě vzniká).

Možná vás mate to, že certifikační autoritu považujete za nějakou instituci. Ve skutečnosti se pojmem „certifikační autorita“ v tomhle kontextu myslí konkrétní certifikát (nebo certifikáty), jejichž veřejné klíče jsou někým považovány za veřejné klíče důvěryhodné certifikační autority. Protože třeba Let's Encrypt si může vydat kolik certifikátů chce, ale jako certifikační autorita vydává jenom ty certifikáty, které jsou (třeba zprostředkovaně) podepsané buď čtyřkilovým RSA klíčem LE začínajícím na 00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c nebo 384bitovým EC klíčem LE začínajícím na 04:cd:9b:d5:9f:80:83:0a:ec:09:4a:f3:16:4a:3e.

V položce Issuer self-signed certifikátu jsou jen zkopírované položky ze Subject toho certifikátu – právě proto, že je self-signed, je tedy podepsaný sám sebou, tedy vydavatel je ten samý jako držitel certifikátu. Ovšem ten text nevypovídá vůbec o ničem, self-signed certifikátů, které budou mít v Issuer uvedeno „Internet Security Research Group“, vám klidně vyrobím sto. A dalších sto certifikátů může mít jako Issuer uvedeno „Root CA of Root CA of Root CA“, a stejně to nebude znamenat, že je to ten nejkořenovější kořenový certifikát na světě.

Upravujete si realitu, aby seděla k vašim argumentům.
Nikoli, popisuju realitu tak, jak se to doopravdy používá. Jaký je rozdíl mezi vlastní CA a self-signed certifikáty si dobře uvědomíte, až byste těch self-signed certifikátů vyrobil 150 a těch 150 certifikátů byste musel instalovat na všechna zařízení, která jim mají důvěřovat. A každý týden by vznikaly další self-signed certifikáty a vy byste je musel pořád distribuovat a instalovat. Pak by vám asi došlo, že jste měl raději vytvořit jednu certifikační autoritu, jejíž certifikát nainstalujete jednou.

Když už, tak certifikační autorita nepodepisuje certifikáty, ale na základě CSR (Certificate Signing Request) nebo obdobné žádosti vystavuje NOVÝ certifikát. Z CSR si bere pouze veřejný klíč a zbytek obvykle ignoruje. Ostatní informace pak do certifikátu doplňuje dle sebe a dle toho, co uvedete v nějakém doplňkovém formuláři.
Certifikační autorita podepisuje certifikáty. Technicky není CSR vůbec potřeba, když si budete provozovat vlastní CA, klidně můžete certifikáty vydávat jen na základě dodaného veřejného klíče, nebo dokonce můžete klíčovou dvojici vyrobit sám a předat držiteli certifikátu jeho certifikát i s privátním klíčem. Z hlediska bezpečnosti to není dobré, ale technicky to jde.

Důležitý je ale právě ten podpis autority na certifikátu, kterým autorita stvrzuje, že údaje na certifikátu jsou pravdivé. Podpis zároveň zajistí neměnnost těch údajů (abyste jim opravdu mohl věřit), a díky podpisu můžete hledat, zda ten certifikát podepsala nějaká autorita, které důvěřujete. Tím, že je vše standardizované, dá se to algoritmizovat – takže dodáte seznam certifikátů certifikačních autorit, kterým důvěřujete, dodáte ověřovaný certifikát a případně s ním dodané  mezilehlé certifikáty, a algoritmus rozhodne, zda ten dodaný certifikát byl podepsán (i zprostředkovaně) autoritou, které důvěřujete.

Stran: 1 ... 18 19 [20] 21 22 ... 375