Re: [Brmlab] GnuPG best practices + tips
On 05/22/18 02:32, Pavel Ruzicka wrote: > Co mi u efail neni uplne jasne (ale mozna jen proto ze jsem nad tim > dostatecne dlouho nepremyslel) zda jde do odchoziho HTTP pozadavku > zakomponovat vysledek neceho co se behem renderovani HTML mailu spustilo > na strane klienta (ne jen obsah puvodni zpravy). Napr. v Thunderbird se > afaik Javascript pochazejici ze zpravy nespusti. Mozna pres nejaka ta > "zverstva" s CSS ktera se provedou driv nez se email klient pokusi > stahnout ten obrazek. Co som cital z toho paperu a rozlicnych PoC na twitteri apod., tak javascript neni mozne pouzit (tj. nevidel som, ze by sa to niekomu podarilo, ale tiez to 100% neviem vylucit, email klienti su strasne zloziti, si myslim, ze tam chyb moze byt viac). Co som videl, tak pouzili CSS background, /, niekde tusim na githube som videl zoznam tagov, ktore to triggeruju, ale teraz to neviem najst. Ale bolo ich celkom dost (radovo cca 50+). Ale javascript som medzi nimi nevidel. Dalsia vec, co limituje ten utok, ze prakticky ma URL nejaky limit, takze to odreze zaciatok spravy. OM ___ Brmlab mailing list Brmlab@brmlab.cz https://brmlab.cz/cgi-bin/mailman/listinfo/brmlab
Re: [Brmlab] GnuPG best practices + tips
Velke plus za tenhle email. more of this. ad efail: vypnuti renderovani HTML je v teto souvislosti doporucovane, bohuzel mi to prijde hodne neprakticke. Zaznamenal jsem i doporuceni na kompartmentalizaci (ne jako reseni, ale zmirneni) pripadne firewall ve stylu Little/OpenSnitch, bez detailni analyzy kazdeho odchoziho pozadavku si ale myslim, ze i ja bych takovou komunikaci odklikl jako potrebnou, takze to stezi jde povazovat za reseni. Osobne teda nepodepisuju pokud k tomu neni opravdu duvod abych mohl cokoli poprit :) Ale ano, AEAD je asi spravna cesta. Prestoze je pro mne email porad nejpouzivanejsim prostredkem komunikace a organizace, doufejme ze zemre ve prospech nastroje bez techto neduhu. Web-of-trust mi porad prijde vic v pohode nez PKI :) Co mi u efail neni uplne jasne (ale mozna jen proto ze jsem nad tim dostatecne dlouho nepremyslel) zda jde do odchoziho HTTP pozadavku zakomponovat vysledek neceho co se behem renderovani HTML mailu spustilo na strane klienta (ne jen obsah puvodni zpravy). Napr. v Thunderbird se afaik Javascript pochazejici ze zpravy nespusti. Mozna pres nejaka ta "zverstva" s CSS ktera se provedou driv nez se email klient pokusi stahnout ten obrazek. ruza On 05/21/2018 11:54 PM, Ondrej Mikle wrote: > Zdar, > > k tomuto prispevku ma viedlo to, ze par clenov brmlabu pouziva GnuPG > (typicky s enigmailom) a ze ked zmenim pocitac, tak mam problem najst > verejne kluce, pokial si ich nevyexportujem z keyringu na nejakom inom > kompe. > > 1. Majte kluc najditelny, idealne vygooglitelny podla mailu a potom > podla fingerprintu > > 2. Na to sa hodi mat kluc publikovany napr. na user stranke brmlab wiki, > vlastnu VPS, alebo keybase.io. Kluc sa da publikovat na PGP keyserver > cez 'gpg --send-keys', potom to umoznuje ludom kluc importovat cez 'gpg > --recv-keys'. Mat fingerprint na separatnej stranke umoznuje mat iny > kanal, jak overit fingerprint. > > Velmi dobry napad je mat na tej stranke https, takze to nikto nemoze > jednoducho vymenit. V pripade vlastnej VPS/vlastnej domeny je dobre, ked > si clovek moze overit cez whois, komu to patri. > > Web-of-trust je failed concept, nefunguje to v praxi. > > PGP keyservers (tych asi 6 hlavnych) si medzi sebou synchronizuju kluce, > takze prakticky by malo byt jedno, z ktoreho tahate tie kluce (inak je > na to parameter --keyserver). > > Keybase.io umoznuje cloveku pouzit niekolko kanalov na publikaciu kluca > (github, twitter, vlastny web, atd.) > > V skutocnosti jeden z najtazsich problemov public key encryption je > distribuovanie tych klucov spolahlivo. > > 3. Bez tych postupov vyssie to nuti ludi random akceptovat kluce (lebo > ich nevedia "aspon +/- spolahlivo najst"), ktore niekde najdu a bolo uz > par pripadov, ze pre "vysoko profilovych ludi" (napr. developerov Tor > Project) niekto zverejnil svoje fake kluce. Dolezite je pri hladani > pouzit a/alebo skontrolovat fingerprint, pretoze to kratke 32-bitove ID > ide bruteforcovat. Sice to chvilu trva, a pre bezneho clena brmlabu by > sa na to nikto neobtazoval, ale ide to. > > 4. Ked uz sifrujete, podpisujte. Pointa je, ze ziskat public key a > zasifrovat nan dokaze kazdy. Preto vsetky dnes moderne schemy su tzv. > AEAD (=authenticated encryption) > > PGP/GnuPG je spravene tak, ze dokym sa sprava nerozsifruje prijemcom, > tak sa neda zistit, kto ju podpisal. Viz nizsie o formatovani PGP sprav. > > 5. Niektore tieto vlastnosti mozem demonstrovat na ukazani, jak su > formovane PGP spravy (RFC 4880). Napr viz v prilohe dump sifrovanej > spravy, ktora bola podpisana, ale kvoli sifrovaniu neni videt jej podpis. > > Da sa na to pouzit 'gpg --list-packets' alebo 'pgpdump -ilmp > message.asc' (pgpdump je separatna utilita, nie priamo sucastou GnuPG). > > Keby bol zaujem, mozem o tom spravit talk, jak to interne je implementovane. > > 5a. GnuPG by default nechava vidiet, na ktore kluce bola sprava > sifrovana. Da sa to vypnut cez '--hidden-recipient' (vsetky tieto veci > sa daju by default zapnut v configu ~/.gnupg/gpg.conf). Pokial ID kluca > prijemcu neni urcene, GPG vyskusa vsetky private keys. > > Na druhej strane ma tento option dost obmedzene prakticke pouzitie, > pretoze ten, kto vam sleduje emaily, vidi odosielatela a prijemcu. > > 6. Nepouzivajte outdated schemy ako DSA a El-Gamal. Minimalna dlzka RSA > kluca 2048 bit. > > 7. Co sa tyka tej poslednej zranitelnosti "E-fail" (efail.de), tak trik > spociva v tom, ze je to "decrypting oracle". Niekto vam posle vas > zasifrovany email a mail klienti nemaju dostatocne dobre filtrovanie na > remote contect - tj. napr Thunderbird a dalsie sice filtruju remote > images, ale ked pouzijete nejke zverstva s CSS, tak tam utocnik namiesa > tu spravu tak, ze tam da link napr. ako CSS backgroud > "https://attackes.picus/bullshit/; + zasifrovanu spravu a email klient > na to spravi request. Klient spravu rozsifruje a posle request, ked cast > URL je ta desifrovana sprava. > > Nevedel som zatial na 100% zistit, ci nejak staci
Re: [Brmlab] [GnuPG]
GPG zasifruje dokument klicem K: --- to je ci klic? r...@brmlab.cz? Je to pár set bitů vytažených z /dev/random. Je to one-time *symetrický* klíč. Jinak posílání skupině - to podle mě GPG nijak jednoduše řešit neumí. On 10.10.2013 17:52, Tomas Overdrive Petru wrote: Zalozil jsem to jako novy subject, nerad mam v emailech bordel. GPG zasifruje dokument klicem K: --- to je ci klic? r...@brmlab.cz? klic se pak zasifruje clenskymi klici: --- nemyslim. zasifrovany klic je pak jen nejaka hromada znaku, rek bych, ze spis mas na mysli prave nejake podepsani klice ostatnimi... ale jisty si nejsem. nebo neco nechapu? Jak by to vedlo k tomu, ze takovy klic muze byt neprimo [to je co?] pouzit k desifrovani... nevim. Idea, jeste jednou, pro prehlednost, kdyz uz jsem zacal novy thread: == Problem je to, ze ja ted chci napsat na r...@brmlab.cz, ta se ted cela zmenila, takze je mozne, ze klice maji lide, kteri uz by muj email nemeli mit moznost cist, stejne jako pristup k emailum. Jak ted muzu tyhle lidi vynechat? Jasne, idealne nekdo, kdo se o klic pro radu stara jej revokoval a rozdal nove, ale je tohle opravdu jedine reseni? Kdyz se bude skupina menit relativne rychle, bude se porad revokovat Master Key? Jak v tomhle hraji roli subkeye, coz je imho sila konceptu, ale nevim. ~ Over Dne 10.10.2013 17:42, Jiří Pinkava napsal(a): funguje to tak že - gpg zašifrtuje dokument nějakým klíčem K - klíč K se pak zašifruje zvlášť káždým klíčem který patří do skupiny - výsledek je že kterýkoliv z klíčů může (nepřímo) dešifrovat dokument zatím jsem to nikdy nepotřeboval, takže jak to prakticky použít ti neporadím Dne 10.10.2013 17:29, Tomas Overdrive Petru napsal(a): @Jenda: Jak nectim filosofii WoT, to se jako NECHES KAMARADIT? Jen[da] pockej zajici! Je pravda, ze WoT je spatny koncept, je to k nicememu a jeste je to bezpecnostni riziko, ja se jen rad chlubim tim, kdo se semnou kamaradi nebo aspon kamaradi. Jinak na adresu confidental jsem poslal vsechny soukrome klice, ktere jsem nasel - omlouvam se, ne vsechny jsou moje, buh uz si to vytridi. Kdyz by se nekomu zdalo, ze je to /dev/random, tak se plete ;] A pak by me jeste zajimalo, ale to poresime osobne: zna nekdo nejaky koncept, jak sifrovat emaily pro nejakou group entitu, ktera se ale muze v case promenovat? GnuPG by melo podporovat Forward Secrecy [snad uz, ted nemam changelog, dohledam]... Jak se to teda dela? Udela se globalni klic typu: r...@brmlab.cz k nemu se udelaji subkeye pro jednotlive cleny a ty se revokuji? Nemuzu to ted nejak domyslet, kdyz se revokuje subklic, znamena to pro majitele soukrome casti co? Imho nic, soukroma cast proste funguje at uz subklic je nebo neni. Jak tedy na to? ~ Over Dne 9.10.2013 22:35, Jan Hrach napsal(a): Pokud mě uvidíte, můžete se mě zeptat, jaký klíč si právě rada myslí, že máte. A úřaduji i jindy než na meetupu každé druhé úterý po druhém úplňku v měsíci. Klíč vám ale bohužel nepodepíšu, protože filozofii WoT nectím. Myslím ale, že jste to nepochopili. Ta adresa se jmenuje confidential, protože tam máte posílat důvěrná data - tedy například *soukromou* část vašeho klíče. Naši specialisté v oblasti HR jsou názoru, že to stmelí tým. Veřejný klíč mám veřejně v patičce, soukromý jsem samozřejmě už zaslal na zmíněnou adresu. On 8.10.2013 23:48, Nephirus wrote: Pokud by nekdo trval na osobnim overeni, tak mu vyhovim a overim to v mych soukromych urednich hodinach: 31. dne v mesicich neobsahujicich pismeno 'e' v dobe od 19:57 do 20:00. nephirus On 10/08/2013 11:32 PM, Jiří Pinkava wrote: neměla by mít rada za úkol individuálně každý klíč ověřit (a případně ověření stvrdit (vzájemným) podpisem) Dne 8.10.2013 23:21, Pavel Ruzicka napsal(a): jednou uz jsme po meetupu meli takovy gpg mini workshop kde jsme si vzajemne overovali a podepisovali klice. muzeme usporadat znovu On 10/08/2013 11:10 PM, Jiří Pinkava wrote: je nějaký konkrétní plán/postup ja by se ty klíče měli ověřovat nebo na to dlabem? ___ Brmlab mailing list Brmlab@brmlab.cz http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab ___ Brmlab mailing list Brmlab@brmlab.cz http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab ___ Brmlab mailing list Brmlab@brmlab.cz http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab ___ Brmlab mailing list Brmlab@brmlab.cz http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab ___ Brmlab mailing list Brmlab@brmlab.cz http://brmlab.cz/cgi-bin/mailman/listinfo/brmlab -- Jan Hrach, http://jenda.hrach.eu/ GPG CD98 5440 4372 0C6D 164D A24D F019 2F8E 6527 282E signature.asc Description: OpenPGP digital signature ___ Brmlab mailing list
