Příspěvky

346

Software / Re:Je bezpecne poslat do mailu nebo na forum prilohu prez tor browser ?

« kdy: 04. 03. 2018, 19:46:33 »

Ale tady nejde o postování závadného obsahu. Vizte citaci autora vlákna:

Neni ale dulezite skryt kdo jsem, pouzivane ucty jsou state stejne a dost lidi o nich vi. Jde o to skryt kde jsem (+ zaznamenavani polohy v prubehu casu).

Tzn. zmiňujete problém, který autor vlákna nepovažuje za hrozbu.

347

Software / Re:Je bezpečné poslat do mailu nebo na fórum přílohu přes Tor Browser?

« kdy: 04. 03. 2018, 18:51:51 »

Jak?

348

Software / Re:Je bezpečné poslat do mailu nebo na fórum přílohu přes Tor Browser?

« kdy: 04. 03. 2018, 18:13:20 »

JardaP: Obesně bych souhlasil, ale OP má trochu specifičtější požadavky, takže zjištění identity mu nevadí. Řeší spíše zjištění polohy.

349

Software / Re: Toby rozšíření pro Chrome - export a záloha

« kdy: 04. 03. 2018, 12:29:40 »

Sice neznám Toby a nevím, co bylo v tom souboru, se kterým se špatně pracuje, ale nepomohlo by k lepší práci s tím souborem třeba jq? To je takový švýcarský nožík na JSON. ☺

350

Software / Re:Je bezpečné poslat do mailu nebo na fórum přílohu přes Tor Browser?

« kdy: 04. 03. 2018, 11:17:31 »

JS určitě zvětšuje attack surface, ale netvrdil bych, že jde o díru by design.

Pokud máte takovéto obavy, doporučil bych se podívat na Whonix, ideálně v kombinaci s QubesOS. Nevyřeší to sice všechny možné problémy, ale zrovna možnost leaku IP adresy to dost omezí. Pokud se útočníkovi povede spustit libovolný kód s právy Tor browseru, nemá ještě přístup k IP adrese, protože veškerý traffic toho virtuálního stroje je jaksi směrován do TORu.

351

Software / Re:Nelze nabootovat po obnově systému (dd)

« kdy: 04. 03. 2018, 11:05:44 »

Co vím, tak obecně po TRIMu není chování vyTRIMovaného místa definováno, ale SSD může mít nějaké flagu - DRAT (deterministic read after TRIM, tedy přečtete tam něco nedefinovaného, ale pokaždé to bude totéž) a DZAT (deterministic zero after trim, tedy budou tam nuly).

Jestli přepisovat nulama, 0xff, nebo něčím jiným - to bude asi dost HW-specific, s trochou smůly se to může lišit i u různých kusů modelu se stejným označením. Jestli je firmware dostatečně chytrý, aby při nějakém specifickém patternu udělal interně TRIM, můžeme spekulovat, případně se to můžeme pokusit odhadnout side channelem. Já bych to takto neřešil a prostě TRIMoval, zvlášť pokud to zařízení má DZAT. A i v případě DRAT bez DZAT se dá čekat nějaký dobře komprimovatelný pattern.

BTW, pokud to SSD  bude automaticky TRIMovat při nějakém patternu a má DRAT, mělo by to jít celkem snadno zjistit. Vzhledem k DZAT trochu hádám, že to obvykle budou samé nuly (pokud je ta fíčura implementovaná).

352

Server / Re:Nastavení SSL komunikace pro Apache2

« kdy: 02. 03. 2018, 07:11:29 »

Taky tomu nerozumím. Když to odmítne spojení, uživatel se na web taky nedostane. V čem je to lepší oproti špatnému certifikátu? A kdo dnes tak nutně potřebuje přistupovat na web přes IP, má takové nutkání na začátek adresy psát "https://" , ale přitom mu nevadí, že ho to následně přesměruje na plain HTTP?

353

Server / Re:Šifrování HDD

« kdy: 01. 03. 2018, 23:37:45 »

Dobrý nástroj, ale je to offline, tzn. neřeší to, jak to udělat online.

354

Server / Re:Šifrování HDD

« kdy: 01. 03. 2018, 23:21:27 »

Online si to neumím moc představit, ani s LVM. Jak by to probíhalo?

0. Dejme tomu, že máme jednu partition.
1. Tu zmenšíme, jak to jen půjde. Tady je první problém, online zvětšení často jde, ale zmenšení moc ne.
2. Vytvoříme vpravo vedle původní partition LUKS container a naformátujeme v něm filesystém.
3. Přesumene data do nového FS. Další problém, ale to zmiňujete. Možná by to řešil nějaký unionfs, ale pokud se na soubory pořád hrabe, tak asi ne.
4. Zase zmenšíme hlavní FS, stejný ptoblém jako v bodu 1.
5. Zvětšíme LUKS container. Pokud máme LVM, půjde to celkem snadno, i když za cenu fragmentace. S GPT/MBR to bude znamenat přesun celé partition vlevo, což opět asi nepůjde offline. Navíc to bude velký přenos dat.
6. Pokračujeme krokem 3, ledaže by už nebylo co přesouvat.

Vytvořením LUKSu před původní partition  nic nevyřešíme, jen přesuneme některé problémy mírně jinam.

355

Server / Re:Nastavení SSL komunikace pro Apache2

« kdy: 01. 03. 2018, 22:01:16 »

Snažíš se o něco, co dost možná nejde. HTTPS svazuje konkrétní identifikátor (typicky doménové jméno, vzácně IP adresu) s veřejným klíčem a různými metadaty jako je doba platnosti. Ty máš certifikáty na dvě doménová  jména (tj. na dva identifikátory). Když se na HTTPS pokusíš připojit přes IP adresu (tj. přes jiný identifikátor, ke kterému nemáš certifikát), server k němu nemá žádný certifikát. Teoreticky by mohl odmítnout spojení (a uživatel by dostal hlášku, že se nepodařilo připojit), prakticky spíše server vybere jeden z certifikátů, který se použije. Je zde asi jedno, který to bude, ani jeden nebude vyhovovat a uživatel dostane hlášku o neplatném certifikátu.

Co se s tím dá dělat:

a. Najít CA, která vydá certifikát pro IP adresu. (Pak ani není potřeba přesměrovávat na HTTP.) teoreticky možné (pokud je IP adresa veřejná), prakticky se to moc nedělá a nalezení takové CA může být náročné a cena za takto unikátní službu může být vysoká.
b. Jako předchozí bod, ale s vlastní CA. To ale znamená instalovat CA na každé zařízení, odkud chcete přistupovat. To by možná šlo, když přes IP adresu tam nebude přistupovat každý BFU, ale moc to nedoporučuju. CA se pak stane riskantním místem a unikne-li její privátní klíč, lze pak těmto zařízením odposlouchávat a modifikovat provoz na všech webových stránkách. (Zjednodušeně řečeno.)
c. Pokud to trápí pár lidí (asi přístup přes IP není pro širokou veřejnost), mohou si odklepnout nevalidní certifikátválit výjimku trvale. Pak by to ale chtělo pro tu IP adresu nějaký separátní certifikát (klidně self-signed), který se nebude měnit, jinak při nejbližší změně se zobrazí varování znovu.
d. Když to není pro širokou veřejnost (hádám), jaký je vlastně problém jim říct, aby na to nepřistupovali přes HTTPS, když na to jdou přes IP adresu?

Ještě bych poznamenal, že v tak 99.99999 % případů se to prostě neřeší, protože není moc use-case, aby na to někdo šel přes IP, když má doménové jméno. Neřeší to ani třeba Google: https://172.217.23.206

356

Server / Re:Šifrování HDD

« kdy: 01. 03. 2018, 21:24:50 »

Jistě, záleží třeba i na tom, jestli ten počítač vůbec má swap. Další potenciální problém je /tmp (ale ten může být v tmpfs). Jako rule-of-thumb (ne však dogma) bych doporučil:

* root nepracuje zbytečně s citlivými daty
* co je zapisované uživatelem, který má s citlivými daty pracovat, mělo by být na správné partition. Dá se pohledat něčím ve stylu find / -xdev -user ..., případně -group a -perm, a případně pro další nechráněné mountpointy.

357

Server / Re:Šifrování HDD

« kdy: 01. 03. 2018, 19:57:56 »

Chce to vyřešit všechna místa, kam se mohou data podít, tedy i například swap (ten lze šifrovat náhodným klíčem, pokud nepotřebujete hibernaci) nebo adresáře, kde se může objevit core dump.

Pro existující instalaci: Chcete vyřešit i stávající data? Pokud ano, bude asi "zajímavé" vyřešit jejich secure erase. V případě SSD bych pak ani o jiné možnosti než překopírování jinam a secure erase celého SSD neuvažoval.

ECryptFS nemá moc výhod. Co si vzpomínám na výkon, bylo to výrazně horší. Dále tu je omezení délky názvů souborů a AFAIR nepodpora sparse files. Nějak se s tím žít dalo, ale pokud není problém mít LUKS partition fixní velikosti, není moc důvod. Navíc se tím neřeší swap (ano, je možné každé vyřešit jinak, swap pomocí eCryptFs asi fakt nechcete...) a leakuje to více metadat, ale to už je jen takový "bonus".

Pro úplnost, EncFS, co jsem naposledy viděl, bylo vesměs kryptograficky hůře navržený klon eCryptFS, navíc přes FUSE.

358

Odkladiště / Re:Jak embedovat stránku s „osekanými právy“ (bez XHR, JS)

« kdy: 22. 02. 2018, 10:07:17 »

Je to ono? https://www.w3schools.com/tags/att_iframe_sandbox.asp

359

Hardware / Re:Nákup tabletu: kdy budou čipy odolné proti M+S?

« kdy: 10. 02. 2018, 12:40:40 »

Pokud jde o Spectre, tak největší šance je u těch in-order ARM. U AMD si se Spectre dnes nepomůžete, maximálně s Meltdown. A u výkonnějších ARMů taky ne.

360

Desktop / Re:Doporučili byste na desktop Manjaro?

« kdy: 07. 02. 2018, 20:20:59 »

Osobně bych nedoporučil rolling release, aspoň ne pro systém, který má fungovat a není čas si s tím hrát, když se to pokazí. (I když to člověk třeba zvládne, může se to objevit v nejnevhodnější okamžik...)