Příspěvky

106

Vývoj / Re:Spring boot - autentizace/autorizace endpointu

« kdy: 26. 04. 2023, 13:02:50 »

Muzu se zeptat o jake anotace jde?

Nebo v tom tutorialu, podle kterého asi postupujete, je to o kousek dál: Method Security. Na Web Security bych se úplně vykašlal, protože jak říká drobná poznámka na konci celé kapitoly, je to aktuálně svázáno jen se Servlet API. Takže je to založené na divném a nespolehlivém principu a ještě na technologii, která je (dokonce i ve Springu) pomalu nahrazována modernějšími variantami (které jsou založené na reaktivním programování).

107

/dev/null / Re:Chat GPT

« kdy: 25. 04. 2023, 21:24:23 »

Asi proto, že je to nezajímavé. ChatGPT nemá přístup na internet a nemůže komunikovat s žádným jiným softwarem. A je všeobecně známo, že je to jen jazykový model, který jen odhaduje, jak by nejpravděpodobněji pokračovala daná konverzace. Tudíž často odpovídá tak, co bychom jinak nazvali lží. Ovšem ChatGPT nezná žádná fakta a jeho texty se nijak nevztahují k realitě – jenom tím, že jsou to nejpravděpodobnější pokračování dané konverzace, dokážeme je my interpretovat, jako by se k realitě vztahovaly (a často pak zjistíme, že se s realitou neshodují).

108

Server / Re:Vzdálená komunikace s Linuxem

« kdy: 25. 04. 2023, 21:12:54 »

Jen info pro odpovídající – ten plink, který zmiňuje tazatel, je právě neinteraktivní terminál a je součástí balíčku putty.

Jinak obecné API, které se používá pro zjišťování informací o systému, je SNMP. Ale nevím, zda přes něj budou vystavené informace, které potřebujete – a řekl bych, že je jednodušší použít ten plink. Jinak už myslím nic obecného neexistuje. Jsou různé systémy sbírající data, jako třeba Nagios, ty mohou mít různé pluginy pro sběr dat. Nějaký takový plugin byste možná mohl použít – ale to API je postavené opačně, než vy byste potřeboval. Tj. musel byste se tvářit, že vaše aplikace je ten „Nagios“ – to ale nemusí být úplně jednoduché. A nebo si můžete napsat něco vlastního a ta data zpřístupnit třeba přes HTTPS – z hlediska konzumace to bude asi to nejjednodušší, a jsou různé způsoby, jak z webového serveru spustit třeba shell skript a data jím vygenerovaná poslat klientovi.

"moderni windows" uz maji ssh klienta primo v sobe.

Majú, ale nie som si istý, či ho majú nainštalovaný by default, alebo ho treba pridať ako voliteľný komponent. V každom prípade, aj keď už je nainštalovaný, tak ssh agent je stále zakázaný, povoliť spúšťanie tejto služby je extra krok.

Windows 11 mají OpenSSH klienta hned od instalace a není potřeba ho povolovat (teď jsem to zkoušel), Windows 10 mají OpenSSH předinstalované od buildu 1809 (lze nalézt na internetu a odpovídá to tomu, co si pamatuju – že od nějakého buildu je OpenSSH už normální a použitelnou součástí Windows 10). Dokonce Git for Windows už nějakou dobu nabízí používání windowsovského OpenSSH a mám pocit, že dnes už je to dokonce výchozí volba.

109

Vývoj / Re:Spring boot - autentizace/autorizace endpointu

« kdy: 25. 04. 2023, 19:27:57 »

Za mne je lepší použít anotace na servisních metodách. SecurityFilterChain a podobné věci založené na textovém zadání URL se snažím nepoužívat a považuju je za nebezpečné. Mezi stringem popisujícím URL, které zabezpečuju, a URL, které vzniká definicí controlleru, není vůbec žádná vazba. Takže stačí překlep, a „zabezpečuju“ špatné URL. V lepším případě, kdy je přístup všude zakázán a povoluje se, jenom znepřístupním nějaké URL. V horším případě, kdy je výchozí stav „vše povoleno“ a přístup na vybrané adresy zakazuju stačí jeden hloupý překlep k tomu, abych dal přístup někam, kam být nemá.

110

Vývoj / Re:Spring boot - autentizace/autorizace endpointu

« kdy: 25. 04. 2023, 17:59:22 »

Autorizaci obvykle musí řešit koncová aplikace, protože jenom ona ví, kdo má k čemu přístup. Např. v e-mailu asi nechcete, aby vaše e-maily mohl číst někdo jiný, v e-shopu aby mohl vaše objednávky zobrazovat, vytvářet či stornovat někdo jiný, v bance aby někdo jiný mohl vidět váš stav účtu, minulé transakce a mohl provádět odchozí platby z vašeho účtu.

111

Windows a jiné systémy / Re:Notifikace nového emailu

« kdy: 25. 04. 2023, 09:37:25 »

Necti Jirsakoviny ... a vymen klienta. Imap to samozrejme umi, pokud to umi server.

Kdybyste připojil odkaz do Google Play na konkrétní aplikaci, nevyzněla by vaše odpověď tak hloupě.

112

Windows a jiné systémy / Re:Notifikace nového emailu

« kdy: 24. 04. 2023, 16:36:40 »

Funguje to tak. Já jsem nikde nepsal, že ta „data“ je nějaká speciální vlastnost mobilní sítě. Z hlediska aplikace je to obyčejný TCP/IP paket – ale mobilní síť musí mobilu signalizovat, že s ním bude komunikovat, a je jedno, jestli mu bude předávat TCP/IP paket z navázaného spojení, nebo UDP paket, nebo sestavovat telefonní hovor, nebo posílat SMS. Podstatné je to, že to trvale otevřené TCP/IP spojení neznamená trvalou rádiovou komunikaci s mobilní sítí.

Mobilní notifikace fungují tak, že si mobil drží trvale otevřené TCP/IP spojení k notifikačnímu serveru. Takže když notifikační server potřebuje mobilu poslat zprávu, pošle ji do tohoto otevřeného spojení. (Kdybychom měli všude IPv6, nebylo by to potřeba – prostě by se navázalo spojení zvenku. Bohužel všude možně je IPv4 a NATy, takže to spojení musí otvírat klient.) Tohle spojení je vyladěné tak, aby se jím přenášelo co nejméně neužitečných dat, ale zároveň aby pokud možno vydrželo otevřené, i když různé zařízení po cestě budou mít pocit, že už se tam dlouho nic nedělo a budou mít tendenci spojení zapomínat.

Nicméně to, že má mobil otevřené TCP/IP spojení, ho nenutí zůstávat ve stavu největší aktivity a neustále být v rádiovém spojení se sítí, což by mu výrazně ubíralo kapacitu baterky. Takže mobil se klidně uspí na nižší úroveň spotřeby. Protože ví, že až notifikační server pošle do toho stále otevřeného TCP/IP spojení další paket, ten se doručí do mobilní sítě, mobilní síť se bude snažit ten paket doručit na mobil, takže mu pošle zprávu, že pro něj má nějaká data, takže s ním potřebuje komunikovat. A v rámci komunikace mu pak pošle ten paket (a mobil ho vzápětí potvrdí, aby to server neposílal znova).

Takže ano, je to na aplikační úrovni na L7, ale mobilní síť s tím má společného to, že ty internetové služby běží přes mobilní síť.

Pokud mobil není k internetu připojen přes mobilní síť ale přes WiFi, je to totéž v bledě modrém.

To samé by se dalo udělat i s IMAP, ovšem musel byste vyladit klienta i server tak, aby si drželi co nejdéle otevřené spojení s co nejmenším provozem. A do toho se asi nikdo nepouští, protože velká část lidí používá nativní aplikace s nativními protokoly, jen menšina používá IMAP. A ti, kdo používají IMAP, mají různé klienty a různé servery, takže by bylo těžké vyladit to kombinaci klienta a serveru tak, aby to fungovalo stejně dobře, jako u těch nativních aplikací. Navíc mobilní operační systémy nemají rády aplikace, které na pozadí pořád někam komunikují – protože to prostě vysává baterku.

113

Windows a jiné systémy / Re:Notifikace nového emailu

« kdy: 24. 04. 2023, 15:21:28 »

Ten primární účet posílá notifikace do mobilu speciálním kanálem pro notifikace. Tj. mobil může být částečně uspaný, server pošle notifikaci o novém e-mailu, mobilní síť pošle mobilu signál, že pro něj má data, mobil se probudí do plného běhu, přijme komunikaci a zobrazí notifikaci.

Pro IMAP ten kanál pro notifikace neexistuje. Server neví nic o nějakém kanálu pro notifikace, který vede na klienta. Je tam jenom komunikace přes IMAP – takže kdybyste chtěl dostávat notifikace přes IMAP, musel by mít klient trvale otevřené spojení na IMAP server, průběžně ho oživovat a tím držet otevřený kanál, kterým by bylo možné informaci o nové zprávě poslat. To by se vám asi nelíbilo, protože by vám to pravděpodobně vycuclo baterku mobilu za pár hodin.

114

Odkladiště / Re:Webshare

« kdy: 23. 04. 2023, 13:45:15 »

Řeší se to tak, že si za rychlejší stahování zaplatíte. To je obchodní model těchto služeb.

115

Software / Re:TLSA kontra SSH

« kdy: 21. 04. 2023, 16:10:19 »

Mícháte dohromady různé věci. TLS je obecný šifrovací protokol, který se používá tak, že obalí jiný (nešifrovaný) protokol šifrovaným tunelem. TLS používá k ověření protistrany certifikát (což je veřejný klíč spojený se jménem a dalšími údaji, to celé podepsané certifikační autoritou).

SSH je jiný protokol, který je rovnou šifrovaný – a je to jeden z mála dnes široce používaných protokolů, který nepoužívá TLS jako šifrovací vrstvu. SSH ověřuje protistranu primárně podle veřejného klíče (tj. nepoužívá certifikát).

Je pravda, že v TLSA můžete mít i otisk veřejného klíče, ne jen certifikátu – ale stejně, co by ssh klient měl dělat, když v TLSA najde otisk certifikátu?

V síťovém stacku je TLS implementované v konkrétní aplikaci, obvykle se na to používá nějaká knihovna. Třeba nativní aplikace často používají OpenSSL nebo některý z derivátů. Ale SSH nepoužívá protokol TLS, takže implementace TLS protokolu je vám při implementaci SSH klienta k ničemu.

116

Software / Re:Elektronický podpis v Thunderbirdu

« kdy: 18. 04. 2023, 22:56:06 »

Vis jisaku, jsou lidi kteri vedi jak veci funguji, pak sou lidi kteri vedi jak funguji alespon nektere veci, a pak ten zbytek, tedy vyhradne ty.

No a pak jsou lidi, kteří ani neumí opsat jméno. A kteří si myslí, že budou znít odborně, když si vymyslí své vlastní termíny. Třeba „revalidace“. Slovo „validace“ znamená „ověření“, „validace DKIM“ znamená ověření podpisu (že sedí hash se zdrojovými daty) a že podpis vytvořil ten, kdo má právo za danou doménu podepisovat. Při validaci se tedy e-mail nijak nemění. A co by mohla znamenat „revalidace“? „Znovu ověření“? Čím by se takové „znovuověření“ lišilo od „ověření“? A jak by mohlo při znovuověření dojít ke změně e-mailu, když se nijak nemění při ověření?

jednak to nejsou jenom hlavicky, co exch zmeni, a druhak u dkim lze jaksi rici, co ze ma obsahovat a muze zahrnovat i prave hlavicky, ktere exch zmeni.

Jenže řeč nebyla o tom, že Exchange nějaké hlavičky změní. Řeč byla o tom, že hlavičky přidá. A přidané hlavičky nijak DKIM neovlivňují. Jinak pro vaši informaci, DKIM obsahuje především vybrané hlavičky. To je jeho účel. Otisk zprávy je do podpisu přidán proto, aby nebylo možné vzít hlavičky legitimní zprávy a připojit k nim úplně jiné tělo e-mailu a tvářit se, že je to validně podepsaný e-mail. Ale tělo není tak podstatné, proto nemusí být do výpočtu podpisu zahrnuté celé, může být zahrnut jen počátek e-mailu.

Ale ten počátek, že někteří lidé nevědí, jak věci fungují, ten jste trefil správně. Je vidět, že to byla jediná věc, kdy jste psal o vlastní zkušenosti.

117

Software / Re:Elektronický podpis v Thunderbirdu

« kdy: 18. 04. 2023, 21:42:48 »

Asi máte pravdu. Zkoušel jsem si to pročíst a nenašel jsem v tom žádné řešení.
Přijde mi divné, že pokud je to vážně bug, tak že ještě nebyl opraven. Nebo snad nikdo kdo podepisuje nepoužívá speciální znaky?

V tom e-mailu, co jste sdílel, podle mne podpis opravdu nesedí. Můžete zkusit vyrobit ještě nějaký, kde nebudou znaky s diakritikou, abych ověřil jednak že podpis ověřuju správně, jednak aby byl vidět rozdíl v hlavičkách, když Thunderbird soubor nekóduje do quoted-printable? Ono to také může souviset s nastavením, další možná používají pro znaky mimo ASCII 8bitové kódování, které se zase kóduje jinak…

118

Software / Re:Elektronický podpis v Thunderbirdu

« kdy: 18. 04. 2023, 21:07:20 »

Problém je s tělem MIME mailů, do nějž Exchange při vkládání mailu do schránky skutečně zasahuje.

To by mělo vliv na DIM ale ne na uživatelský elektronický podpis (teda pokud Exchange nemanipuluje i s MIME tělem, což snad nedělá).

119

Software / Re:Elektronický podpis v Thunderbirdu

« kdy: 18. 04. 2023, 19:31:15 »

Do té BugZilly, co odkazoval none_ v komentáři #2 jste se díval? To totiž pravděpodobně popisuje právě váš problém.

120

Software / Re:Elektronický podpis v Thunderbirdu

« kdy: 18. 04. 2023, 17:58:16 »

Mozna bys moh trochu rozepsat, co od toho cekas.

Totiz, pred nejakou dobou sem testoval moznosti, a dokud jsem to testoval mezi "normalnima" klientama, vse fungovalo naprosto bez problemu. Tzn nikoli web. Naprosto vpohode jsme s kolegou pouzili i selfsign, stacilo poslat protistrane 1x podepsany mail, a klient si to ulozil a odpoved uz i klido zasifroval. Testovali sme tb + utlouk + em + nativni android klient. Nejake "autority" to vubec nezajimalo (coz teda neznamena, ze by nejak neslo rict ktere verit, ale to se tem verejnym neda zadne).

Prakticky se to ale nedalo pouzivat se zadnym webmailem. A to ani v situaci kdy se tedy naprosto vzdas jakekoli realne bezpecnosti, protoze jaky asi tak dava smysl sifrovat (nebo i podepisovat) maily kdyz je pak stejne posles guuglu.

Problem pak nastava mimo jine i v tom, ze nektere servery (google, exchange ...) do mailu zasahuji, takze treba kombinace outlook + exchange fungovala jen a pouze v situaci, kdy byl mail nejen podepsan, ale take zasifrovan. Pokud bys treba na tom exchange chtel revalidovat dkim, tak taky smula, nacpe si do mailu hromadu svych nesmyslu, takze to uz neprojde.

Řekl bych, že píšete nějaký text na dané téma, ale s realitou se to moc nepotkává. Kdyby nechyběly háčky a čárky, řekl bych, že to psala umělé inteligence. Zajímalo by mne, co si třeba představujete pod pojmem „revalidace DKIM“ nebo proč by cokoli související s DKIM mělo měnit tělo zprávy (které se podepisuje certifikátem uživatele).