Re: [tor-talk] Hidden Services Questions (mostly) Please?
On Mon, Mar 31, 2014 at 08:48:44PM -0400, me wrote: Bare with me as I ramble my way toward hidden services. First a plain server connect: Assuming a simple web client using Tor to contact a normal web page, NOT HTTPS for simplicity. Client = Node A = Node B = Node C - HTTP Server Node C (exit) sees unencrypted traffic to the server and can monitor everything. Yes. For those following along at home, check out https://www.eff.org/pages/tor-and-https Assuming I set up more than 3 nodes in a circuit, can any of the nodes determine how many nodes I'm using? The first one knows that it's getting a connection from a non-relay so can guess it's you. The last one knows it's being asked to exit to the http server. The middle one(s) know it's not the first or last. If you have multiple middle ones, they could perhaps use timing to guess what hop they are. We don't claim to hide from relays what position they are in the circuit, since it seems hard to reliably hide it. Also, it's really the first and last relays you should be concerned about: https://www.torproject.org/docs/faq#ChoosePathLength Now Hidden service: Client = A = B = C = Rendezvous = D = E = F ~ Hidden Server Actually the client picks three hops and the hidden service picks three hops, so there is no 'C' hop. I assume that unlike the non-HS, C is not equivalent to an exit node and C = Rendezvous is encrypted? B = Rendezvous is encrypted yes. Does C know it is the last node before connecting to a Rendezvous? B does not know it's the last node before connecting to a relay that's used for rendezvous. However, B can know it's not the first hop, and can look at Rendezvous's exit policy and learn that you're probably not exiting from it, meaning you're probably doing something else. This isn't something we try to (or think we can) hide. So, assume yes but maybe it's hard in practice. Is the F ~ Hidden Server connection encrypted or not? It is. Exactly like the client = A hop is encrypted. Does F know it is the last node and connecting to a Hidden Service? F can know it's the guard (first hop) for a Tor client. We assume it can look at the traffic patterns and guess that the client it's being a guard for is probably offering a hidden service. So, assume yes. --Roger -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Pirate Linux 2.0 alpha
Hi, AK wrote (01 Apr 2014 01:53:06 GMT) : Let me just clarify some points. Is the goal to be more secure than a standard Linux distro such as Ubuntu or Debian? Yes. OK. What I'd be delighted to read now is what more secure means. I'll wait for your next write-up :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Linux kernel transproxy packet leak (w/ repro case + workaround)
Mike Perry: I've discovered that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances. Quite the bombshell! I've reproduced those packets on kernel 3.13 using your iptables rules. Strangely enough my own personal transproxy setup does not exhibit this issue, but it's not yet in a releasable state. Anyway, if someone wants to experiment on this bug without actually sending out clearnet packets, current versions of corridor* have an optional logging facility: [1540.249244] corridor: reject IN=eth0 OUT=eth1 MACSRC=... MACDST=... MACPROTO=0800 SRC=10.0.0.2 DST=74.125.28.104 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=59190 DF PROTO=TCP SPT=33200 DPT=80 WINDOW=229 RES=0x00 ACK FIN URGP=0 [1591.827163] corridor: reject IN=eth0 OUT=eth1 MACSRC=... MACDST=... MACPROTO=0800 SRC=10.0.0.2 DST=74.125.28.104 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=59198 DF PROTO=TCP SPT=33200 DPT=80 WINDOW=229 RES=0x00 ACK FIN URGP=0 Rusty * https://github.com/rustybird/corridor signature.asc Description: OpenPGP digital signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-dev] Linux kernel transproxy packet leak (w/ repro case + workaround)
On Saturday 29 March 2014 03:10:47 grarpamp wrote: On Fri, Mar 28, 2014 at 5:20 PM, intrigeri intrig...@boum.org wrote: grarpamp wrote (28 Mar 2014 21:02:35 GMT) : [...] what happens with entire vm IP transproxy (perhaps like Tails)? Tails only uses a transproxy for the automapped .onion addresses: https://tails.boum.org/contribute/design/Tor_enforcement/ My mistake. I think I meant to say whonix [1], just haven't followed the developments of those two projects in quite some time. [1] Or any model that sandboxes apps/OS/vm behind a firewall that redirects all tcp and dns traffic into tor Trans* options and drops the rest. As the maintainer of the qubes-tor (TorVM) plugin for Qubes, I'm definitely interested in this answer as I imagine Patrick @ whonix is too. I'll see if I can reproduce this bug with the Qubes context [0] ~abel [0]: https://github.com/abeluck/qubes-tor/blob/master/start_tor_proxy.sh signature.asc Description: This is a digitally signed message part. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] corridor, a Tor traffic whitelisting gateway
On Sunday 16 February 2014 13:42:59 Patrick Schleizer wrote: Rusty Bird: Patrick Schleizer: The problem is, any Whonix-Workstation behind Whonix-Gateway - once compromised - can claim to be another Whonix-Workstation, thus not being stream isolated anymore. This could be solved, when there was a defense, that prevented impersonating other workstations. VPN and/or Static ARP entries and/or OpenSSH could be used for that purpose. (How) does Qubes deal with this? Last time I checked, it it did not. (Apart from the workaround of using a separate Tor-VM per workstation.) I guess they'd be also interested to discuss your new concept on their qubes-devel mailing list. qubes-tor maintainer here.. playing with corridor in a Qubes ProxyVM right now :) As to the spoofing question, Qubes doesn't suffer from this problem. While there is only one gateway/torvm to many-workstation/appvm, each appvm uses a separate interface and subnet, so appvms can't impersonate or affect eachother. ~abel signature.asc Description: This is a digitally signed message part. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hidden Services Questions (mostly) Please?
Thank you! -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
