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 - Vietnamka

Stran: [1] 2 3 ... 14
1
Hledám článek na rootu asi někde z března až dubna, asi z seriálu postřehy z bezpečnosti, kde v komentáři někdo si stěžoval(parafrázuju), že bezpečnost webových aplikací moc se neřeší nebo to dělají diletantni a že třeba soubory se nahrávají pod účtem webserveru nebo wwwdata nebo www-data.
To zvýrazněné je ,co tam bylo a taky mě to zajímá. Bohužel v komentářích nejde vyhledávat.  Jak to tedy je s tou špatnou a správnou praxí oprávněním/ownerem souborů/skriptů pod www-data?

2
Server / Re:Program pro verifikaci DKIM
« kdy: 09. 05. 2024, 21:12:01 »
Citace
offline
To je pravda. Myslel jsem offline tak,že nebudu někam to tramtárie posílat znění mailu a že veřejný (a poplatný té době)selektor z DNS taky předám offline algoritmu.
kanonizace=kanolizace=normalizace=Kanonikalizace

(v tom  odkazovaném linku byl problém v něčem jiném, že  v závěru hlavičky DKIM-Signature byl středník na konci "...bh=MM8hb=; b=i8B6fC=); a v tom konkrétně nevidím problém

3
Server / Re:Program pro verifikaci DKIM
« kdy: 09. 05. 2024, 21:04:43 »
Citace
offline
To je pravda. Myslel jsem offline tak,že nebudu někam to tramtárie posílat znění mailu a že i ten veřejný selektor z DNS si dopředu stáhnu  (a poplatný té době) taky předám offline algoritmu.
kanonizace=kanolizace=normalizace

(v tom  odkazovaném linku byl problém v něčem jiném, že  v závěru hlavičky DKIM-Signature byl středník na konci "...bh=MM8hb=; b=i8B6fC=); a v tom konkrétně nevidím problém

4
Server / Re:Program pro verifikaci DKIM
« kdy: 09. 05. 2024, 18:25:15 »
Tak je totakto: ... Ovšem musí se to použít na kanonikalizovaný výstup což je něco jako:
Kód: [Vybrat]
date:Thu, 9 May 2024 18:19:09 +0200
to:Jana.VELKA
mime-version:1.0
content-type:text/plain; charset=utf-8
dkim-signature:v=1; d...9; c=relaxed/simple; h=D....pe; bh=6K8=; b=
(poslední řádek je dlouhý) - následující skript-ohejbák přidá LF (zajistí převod na CR+LF) a zároveň odebere  poslední LF (rovnák)

head -c -1 <(sed -E 's/$/\r/g')| openssl dgst -sha256 -sign ../dkimp.pem |base64 # hlavička
+
echo -ne "Začátek.Konec" |sha256sum | cut -f1 -d \  | xxd -r -ps  |base64 # body
# - ovšem hash body se musí udělat jako první


5
Server / Re:Program pro verifikaci DKIM - openssl dgst
« kdy: 09. 05. 2024, 17:38:37 »
což je mimochodem tady
https://forum.directadmin.com/threads/dkim-signature-did-not-verify.59305/
openssl dgst -sha256 -sign private.key -out sha1.sign head1.txt
(přidat    asi i--binary a následně |base64)

6
Server / Re:Program pro verifikaci DKIM
« kdy: 09. 05. 2024, 17:31:42 »
A jako udělat hash těla  (bh) není problém : echo -ne "Začátek.Konec" |sha256sum | cut -f1 -d \  | xxd -r -ps  |base64
zas*aný xxd vyžaduje parametr -ps  osamoceně- takže -rps nefunguje . A --ps mě napadlo až ted, ale kdyby to bylo v man, tak je to jasné hned. A je to -ps a ne jenom -p

podpis hlavičky (copypaste od začátku po "...;b=") bude vyžadovat nějakou magii s openssl  pubutil nebo tak

7
Server / Re:program pro verifikaci DKIM
« kdy: 09. 05. 2024, 17:14:47 »
Nemám, to k samotnému  podepisování nebo  implementaci validování do flow mailserveru, ale k odhalování jednotlivých problémů "out of band" - v DMARC reportu mi přistálo, že  jednou z 100 nesouhlasil DKIM podpis, který vždy  jindy souhlasil. Tak teď chci vzít zprávy (jsou 4 kandidáti) a  ručně to u nich ověřit.Kdyby šlo se  podívat za rameny příjemců, tak je to rychlejší, ale půlka z nich netuší o existenci Zobrazit Hlavičky natož DKIM.

pro jjrsk: šlo to přímo na seznam.

Chtěl jsem ještě přidat požadavek: jak si předsavuji, přidanou hodnotu tohoto nástroje
A aby to vypsalo v případě nesouhlasu, zda nesouhlasí, bh, b nebo obojí. A jako bonus , takovou třešničku na dortu, pokud  opět nesouhlasí hashe, tak to nějak se pokusilo odhadnout, kde se stala chyba(snažit se nějak dojít k správnému hashi tak, že to vyzkouší případné možné varianty (záměna CRLF-LF, přidání-odebrání posledního prázdného řádku, kanolizace a pak to řekne, tahle varianta souhlasila)

8
Server / Program pro verifikaci DKIM
« kdy: 09. 05. 2024, 16:58:10 »
Znáte nějaký program, skript, či webovou stránku snad (sic!) v offline režimu , kam se jako vstup zadá tělo e-mailu a ono to vyplivne, zda souhlasí DKIM podpis? Hledal jsem na internetu, ale všechny výsledky jsou povrchní - pouze validují syntaxi veřejného záznamu _domainkey "v=DKIM1...." A to ani v nejmenším není to ,co hledám

9
Napíchly i poláky prý. že to byla součást audioozvučení. Tak mi vyvstává kauza promopro pro ozvučení pro evropské předsednictví (už pár let dozadu).

10
Server / Re:Let's Encrypt zmražení vytvářeni certifikátů
« kdy: 09. 05. 2024, 13:44:20 »
Upřesním:aby někdo jiný nemohl generovat certifikát po těch 90 dní. Pokud už bude mít doménu, tak si může s DNS CAA dělat co chce.
Díval jsem se to dokumentace ,  ale  zaujalo mě,, že (nepřekvapivě) je rozdíl mezi renewal a novým generováním  (a možné novým generováním na zelené louce a generováním z počítače, ze kterého už se někdy použil certbot - jsou tam uložené nějaké údaje)

11
Server / Let's Encrypt zmražení vytvářeni certifikátů
« kdy: 08. 05. 2024, 19:58:12 »
Mám -li u stránek Let`s Encrypt certifikát, je možné nějakým způsobem freeznout nebo ochránit před novým vygenerováním certifikátu do té doby, než aktuální nebo poslení expiruje (90 dnů)? Jsou k tomu nutné nějaká kroky nad rámec běžného generování certifikátu přes HTTP challenge? (přidání do DNS), něco  s podepisováním? Případně přidání jiných typů RR do DNS?

12
Vývoj / Re:Zkrácení haše pro identifikaci
« kdy: 26. 02. 2024, 19:32:00 »
K loterii:

Ze je to mala pravdepodobnost? Vyhra jackpotu v loterii $1B ma taky silene nizkou pravdepodonost a presto lidi obcac vice nez miliardu $ vyhraji.
Teď jste se odkopal a ukázal jste, že o tom vůbec nic nevíte. Nejdřív si spočítejte, jaká je pravděpodobnost výhry v té vaší loterii. Pak si spočítejte, jaká je pravděpodobnost, že náhodně vznikne stejný 160bitový hash pro dva různé vstupy.
Stejně jako výše bych chtěl upozornit, že nás to nezajímá pro dva různé vstupy, ale alespoň jednou pro N různých vstupů, což je výrazně a neintuitivně jiné číslo (narozeninový paradox). Nicméně máte pravdu, že je stále nepředstavitelně menší než ta výhra v loterii a pro praktické účely je to i pro 160bit hash „nula“.
Jenže losování v loterii a hledání kolizí je jiná úloha.
Loterie  náhodné losování z N losů a to se ví.
Ale vstupy pro hashe jsou neomezená množina, protože není specifikovaná délka řetězce a může to  být dlouhá jak prsa ženy afrického kmenu. Věc druhá je ,že hash nabývá 2^N hodnot

13
Mělo by to být ireleventní  při ideální implementaci hashovací funkce. Libovolně zvolený rozsah pro "substringování" by měl mít stejnou vypovídající hodnotu . Lze to ad absurdum dovést až  na bitovou úroveň, že budu vybírat jednotlivé bity a ještě  je poskládám v nějakém pořadí. Ale vždy konzistentní. (Tím si nejsem jistý, ale tipl bych, že ani to tohle nehraje roli)

Samozřejmě to má ale důsledek, že v tom hashi bude méně bitů informace.

Ale mám otázku do pléna,  možná se to tu řešil na této stránce :
Pokud chci zkrátit hash (v podstatě to co tazatel), například na poloviční délku, mohu prostě ořezem dat a nebo xorováním.

Já si myslím (tvrdím). že na základě vlastnosti ideální hashovací funkce
1-sub: Při zkracování hashe nemusí  v rámci testování být předpis pro substring   pro každý vstup stejný (indexy bajtů, který zahodím) , může se lišit
1-xor: Při zkracování hashe   xorováním nemusí být předpis pro xorování stejný (které dvojice bitů xoruji a jejich pořadí)
2-equ: Oba způsoby (zkrácení a XOR)) mají "stejnou výstupní kvalitu" . Nebo jak to formulovat... jsou rovnocenné


Samozřejmě že pak pro body 1 pro stejný vstup bude výsledek xoru nebo substr jiný, ale myslím to tak, že když budu testovat unikátní vstupy, tak pole výstupů (jako celek) bude mít stejnou distribuci náhodnosti jako když  pro všechny unikátní vstupy použiju stejný parametry  (v kurzívě )

14
Vývoj / K čemu je na webu soubor "vmc-certificate.pem"
« kdy: 26. 02. 2024, 19:00:43 »
Stahuje ho service-worker.js  Jaký je význam tohoto souboru "vmc-certificate.pem" ?
Při hledání přes konzoli Ctrl Shift F jsem nikde nenalezl jeho použití.

15
Server / Re:Přeposílání pošty mezi více příjemci
« kdy: 12. 02. 2024, 13:50:09 »
Ano, SRS je nutnost, jinak to neprojde přes SPF, vycházím, že většina lidí organizací/hostérů má SPS hard fail (-). A ne soft fail (~).   Prostý přeposlání(bounce) už vůbec nemá šanci. Ale myslím, že googlu se to nelíbí kvůli absenci hlaviček ARC, pokud tam nejsou.

Stran: [1] 2 3 ... 14