DNSSEC dotazy přes Tor (mini howto), Firefox leakující DNS (diskuse)

[Mrkva]

Hmm, DNS leaky nejen z Firefoxu, ono ve výsledku to pak může leaknout třeba Flash (i když ten už jsem odinstaloval) nebo Java řeším:

iptables -A OUTPUT -m owner --uid-owner 1002 -j toronly_out
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 6668 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 4444 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 6010:6020 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 8118 -j ACCEPT
iptables -A toronly_out -d 127.0.0.1/32 -p tcp -m tcp --dport 9050 -j ACCEPT
iptables -A toronly_out -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A toronly_out -j REJECT --reject-with icmp-port-unreachable

[limit_false]

Jj, binární pluginy můžou dělat co chtějí. Byl jsem alespoň příjemně překvapen, že poslední verze Flashe použijou SOCKS proxy nastavenou ve FF.

Jinak, máš nastaveno v about:config "network.proxy.socks_remote_dns" na true? Ono je to by default false, tudíž i FF by default leakuje DNS. Kromě firewallu lze ještě použít Torsocks, ten via LD_PRELOAD blokuje např. UDP úplně (ale momentálně to mají mírně rozbitý).

V Tor Browser Bundle (TBB) to vyhackovali až na level že se vůbec nespustí plugin-container. Tím pádem nepoběží žádné pluginy ani addony s binárními komponenty. Ani když to člověk povolí v nastavení TorButtonu.

TBB má jednou velmi speciální vlastnost: všichni uživatelé TBB vypadají "téměř stejně". Nelze pak profilovat podle UA, screen resolution, fontů a podobných informací. Což je velmi dobrý důvod proč používat specificky TBB a nedělat to "po staru".

Vůbec build skripty pro TBB s úpravou nastavení jsou celkem zajímavé, ale neměl jsem čas se na ně podívat podrobně: git://git.torproject.org/torbrowser.git

[Mrkva]

Jinak, máš nastaveno v about:config "network.proxy.socks_remote_dns" na true? Ono je to by default false, tudíž i FF by default leakuje DNS.

Nemám, ale stejně to resolvuje (podle mě FF zjistí že neroslvne protože to firewall rejectne, tak to pošle přes proxy).

TBB má jednou velmi speciální vlastnost: všichni uživatelé TBB vypadají "téměř stejně". Nelze pak profilovat podle UA, screen resolution, fontů a podobných informací. Což je velmi dobrý důvod proč používat specificky TBB a nedělat to "po staru".

Jo, to jo, já se snažil nastavit co nejvíc nenápadně podle tohohle a taky to není tak zlý.

A k tomu omezení - osobně bych se (i přes použití TBB) vážně přimlouval za použití firewallu, přece jen se dá pouštět víceméně cokoliv bez obav. OK, vím o tom, že by si aplikace mohla získat nějaký obraz o počítači (použitý HW, systém, fingerprinty pár konfiguráků) a pak to klidně přes TOR poslat do světa. Ale fakt je, že kdybych dělal něco co by někomu stálo za to na mě nasazovat takovéhle prostředky, budu mít na tuhle "tajnou" práci separátní počítač se separátní a maximálně anonymní konektivitou.

[limit_false]

Podle Panopticlicku nejspíš nastavili v TBB ty UA parametry apod. Podobně se teď válčí o to, jak udělat Tor-ové certifikáty a TLS handshake, aby vypadaly "normálně". Viz proposal 179.

Původně jsem chtěl navrhnout nějaké zlepšení na prop 179, ale všechny trumfy se nesmí vysypat naráz. Prop 179 vypadá jako dost dobrý následující krok. Obdobně jako v případe fingerprintingu UA a Panopticlicku se pro certifikáty a handshake používá SSL Observatory jako referenční bod. (A když jsem si už nakódil vlastní observatoř skenující denně "ty SSL internety" a strávil hrabáním se ve výsledích dni a hodiny, tak aby se to i využilo!)

Firewall věci nepokazí (modulo v článku zmíněný italský operátor, pořád se úspěšně protunelovali všichni, nad některými metodami jsem kroutil hlavou ), ale je to zacpávání cedníku. Mnohem lepší přístup je nepovolit náhodný binární kód pluginů (nelze je efektivně ohlídat ani sandboxovat). Je mnohem jednodušší ukázat, že browser s implementací javascriptu může todle a tamto (i vrátaně potenciálních chyb), než chytat kam všude může sahat binární plugin. Takový "model-checking light", ale funguje.

Zajímavou přednášku týkající se klasifikace softwarových děr z hlediska vyčíslitelnosti/lingvistiky měla na 28c3 Meredith Patterson: The science of insecurity. Je to mírně "sušší" - teoretická informatika - minutové shrnutí začíná o 3:30.

Nejdůležitější tvrzení přednášky je: navrhujte protoly, aby byly rozeznatelné deterministickým zásobníkovým automatem. Tím pádem vás nerozháže halting problem. S gramatikou protokolu je pak jednoduché zjistit, jestli je správa formována správně nebo nikoli. To ovšem znamená konec "length-fields".

Nicméně existují části protokolů, které to splňují, a pořád tam programátoři dělají chyby. Příklad: OID encoding v X.509 ASN.1 BER a Kaminskeho 0x80 bug. Ale je pravda, že kdyby byl k protokolu vydána gramatika v nějakém rozumném formátu (př. bison), šlo by to zmrvit mnohem hůře.

[Jendа]

(A když jsem si už nakódil vlastní observatoř skenující denně "ty SSL internety" a strávil hrabáním se ve výsledích dni a hodiny, tak aby se to i využilo!)

Hele, když už skenuješ SSL, nechtěl bys tahat i SSH fingerprinty? Podle těch pár sítí, co jsem zatím zkusil oťuknout, by to mohla být docela sranda.

[limit_false]

Zdá se mi, že to už nekdo dělal, ale teď to neumím vygooglit.

Pro scanování SSH bych potřeboval dalšího stroj (nebo alespoň IP z úplně jiného /24 rozsahu), aby pak blokování na straně scanovaných strojů kvůli SSH scanu neblokovalo SSL scan. Taky bych asi musel řešit více abuse complaintů než při SSL scanu.

Jinak kód pro scanování SSH je téměř kompletní, v threaded_scanner.py se musí jenom vyměnit jeden řádek v ScanThreadu, v StorageThread pak ukládání (git://git.nic.cz/perspectives-observatory). SSH scanovací kód jsem zmazal, ale je v historii.

[petr_p]

Nerozumím, proč vyžadujete validující rekurzivní server a vzápětí nabízíte cizí servery. K čemu je dobrý příznak validity v odpovědi apriori nedůvěryhodné třetí strany.

[limit_false]

Rekurzivní: unbound vyžaduje rekurzivní server při upstreamingu

Validující: je to hlavně kvůli testování tunelu. Skutečnou validaci dělá unbound, abychom se v "ostrém" provozu nespoléhali na 'ad' flag co přijde z tunelu (proto je unbound na konci řetězu). Přesnější by bylo požadovat resolver, který není "DNSSEC-oblivious" (pak může být ladění složitější).

Cizí: Tor nepomůže, pokud se budete ptát vlastního resolveru a budete jeden z mála dotazujících klientů (odposloucháním na straně serveru by bylo snadné zjistit kdo se na co ptá).