Re: Bridging from Bootcamp???
On Tue, Feb 8, 2011 at 2:09 AM, bao song michaelw...@yahoo.com.au wrote: ... On the Bootcamp side (Windows 7 Professional 64), 'Test port forwarding' always fails to find a valid UPnP, and no one ever manages to access my bridge. check your firewall. usually this is the windows or $antivirus firewall blocking UPnP and/or the listening Tor socket. (you can try just disabling the firewall to confirm/deny, and then continue on to the various help sites for configuring allow rules for Tor bridge, relay, UPnP requests, etc.) best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor raid [was: cease and desist from my vps provider...]
On Mon, Feb 7, 2011 at 12:47 AM, Marco Predicatori ma...@predicatori.it wrote: morphium, on 02/04/2011 03:08 PM, wrote: Oh and yes, they took only my hardware @ home, not the Server in the data center that actually DID run Tor and that the bad IP belonged to. That's interesting, because it means that running the node away from home doesn't affect the chance of being harassed at 5 AM. :-( only if you purchase said services under your real name/accounts or without sufficient indirection. defense in depth++ but that is tangential discussion not for this list... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor raid [was: cease and desist from my vps provider...]
On Fri, Feb 4, 2011 at 6:08 AM, morphium morph...@morphium.info wrote: ... Oh and yes, they took only my hardware @ home, not the Server in the data center that actually DID run Tor and that the bad IP belonged to. this is interesting. just to clarify: you had traffic of interest from a dedicated server in a data center running Tor, yet the raid and confiscation targeted hardware at your home? (while leaving the data center server untouched?) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
On Wed, Jan 12, 2011 at 3:11 AM, intrigeri intrig...@boum.org wrote: ... (do Tor Live CDs need a new kexec target for memtest sweeps / ram zeroisation? :) As far as I understand, this seems like enhancements over the cold boot attack, and one more reason why Tor Live CDs should wipe the system memory on shutdown. Am I misunderstood? likely so. however, more than just wipe at shutdown is useful. explicit ordered zeroisation is handy. (starting with keys and key schedules, working cipher state, then on to user data, before completing a full pass or three. this takes a smart kexec or other ham fisted - still worth the effort.) synchronous wipe on shutdown in foreground with progress indication. i argue this necessity on usability basis. experimental methods like key and state storage in CPU cache lines may hold promise. physical rendition of your solid state memory via self-powered capacitive discharge initiated by big red panic button! (ok, not really. you get the picture :) Most Tor Live CDs (e.g. the good old, now obsolete, Incognito, and its spiritual successor T(A)ILS) have been doing this for ages. yes, i've seen the sleep 10 magic smem trick, and this is one reason why pre-empting the entire runtime to execute a wipe is useful - there are no locked devices or blocking operations contending for resources with the wipe procedure itself. in any case, this begs the question of best practice in solid state remanence avoidance. it would make a good FAQ entry, perhaps... best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor relay on vserver exeeding numtcpsock
On Wed, Jan 12, 2011 at 7:57 AM, Klaus Layer klaus.la...@gmx.de wrote: ... Error creating network socket: No buffer space available errors. The numtcpsocks parameter limit is set to 550 on the vserver. Before asking the ISP to increase the value I would like to ask you what a reasonable value of this parameter would be. 550 is ridiculous. it should be at least 4096, more if they are accomodating. you may or may not find the ConstrainedSocksSize option useful as well. good luck! you may want to update the good / bad ISP entry with your experience. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
On Wed, Jan 12, 2011 at 5:44 AM, berta...@ptitcanardnoir.org wrote: ... explicit ordered zeroisation is handy. (starting with keys and key schedules, working cipher state, then on to user data, before completing a full pass or three. this takes a smart kexec or other ham fisted - still worth the effort.) There is actually discussions on lkml about this [1]. Actually, code to wipe the encryption keys in ram is already in the linux kernel, but available only when you do a suspend. That is cryptsetup luksSuspend does use dm_crypt's crypt_wipe_key function. There is an obvious problem when the rootfs is encrypted, as once you wipe the encryption keys, you can't access anymore the necessary files to go on with the shutdown process. A page on the debian wiki has started some thoughts about this [2], surely the solution would be the kernel to issue this wipe key function at the very end of the shutdown process. Still this wouldn't address the issue of the system being shutdown the hard way (e.g by removing the computer power source). right. there are trade-off's with the kexec approach, mainly that you're bypassing most normal shutdown. i don't care, as long as dirty pages are written before mem is trashed... the kernel key management facilities do make it easy, although you also need to consider userspace like OpenSSL keys and cipher state. synchronous wipe on shutdown in foreground with progress indication. i argue this necessity on usability basis. Which is T(A)ILS does :) kudos sir! experimental methods like key and state storage in CPU cache lines may hold promise. There were discussions about this when the cold boot attack was disclosed, and it didn't appears to be such a good solution [3]. But maybe you're talking about another method. nope, that's the method. it is ghetto, for sure, but unless you've got a real HSM that's as good as you'll get. and as mentioned, cache line key storage is only effective if the entire key, including any expanded key schedules, is kept in cache. this is another performance hit, unless you've got AES-NI on die or other acceleration. anyway, not really practical yet. and likely never will be. best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor VM stalled at 25%
On Thu, Dec 23, 2010 at 2:03 PM, Praedor Atrebates prae...@yahoo.com wrote: I just finished installing VMWare Player, fired it up, and then installed the latest tor_vm.iso (Ubuntu) as the OS/system in the VM. It has stalled here: Bootstrapped 25%: Loading networkstatus consensus. where in the world did you find a tor_vm.iso ? latest is years deprecated at this point unless you've built it yourself or got it from someone who has. Any ideas as to what the problem is? if you're using a '2009 image you're too far out of date for current network. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor VM stalled at 25%
On Thu, Dec 23, 2010 at 3:08 PM, Praedor Atrebates prae...@yahoo.com wrote: ... I want the VM system because I want to be able to browse without having to deactivate java, javascript, and flash... I want the VM so I can access these websites while still being anonymous, thus the necessity of a VM environment. there are still a large number of risks to your anonymity when using things like Java, Flash, arbitrary applications with Tor, even in a fully transparently Tor'ified VM configuration. local DNS resolver IP disclosures and side channels, chained exploits (accelerated VM interfaces are very risky but oh so performant...), many, many other considerations and risks. you need to carefully consider your risks for using such things, hence my recommendation for the stock bundle without those risky things unless you really know what you're doing or the risks are exceptionally low. best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Bitcoin And The Electronic Frontier Foundation
On Sat, Nov 20, 2010 at 8:57 PM, John Case c...@sdf.lonestar.org wrote: ... That's what I thought... So, would a sparc T3 be an interesting platform upon which to run bitcoin ? Or are the fermi based GPUs still orders of magnitude faster ? a T3 would be a great platform for a Tor relay, were someone to code support for it. fermi still pwns bitcoin... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Bitcoin And The Electronic Frontier Foundation
On Sat, Nov 20, 2010 at 7:45 PM, slush sl...@centrum.cz wrote: ... Yours complaints are on the same level as if you say 'I have only 486DX, those guys with Quad cores driving me crazy'. ... maximum ~200 blocks per day, because it is limit of network. ... Regards to wasting electricity. There are many kinds of wastes. Somebody waste electricity to finding bitcoins, somebody find UFO using s...@home. s...@home is a cooperative effort. if they were to code their client such that everybody was chewing on the same chunk of datum, that would be wasted effort. (read: waste) having any software miners active when GPU miners are active is wasted effort. for integrity sake, bitcoin should disable all software miners, and explain to users that trying to mine via software is a waste of your time and power. last but not least, this discussion has clearly drifted way off topic. why not take it to cypherpunks or cryptography list (if not bitcoin forums)? if Tor starts using bitcoin for priority routing we can revive this thread.. ;) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, Nov 17, 2010 at 3:02 PM, grarpamp grarp...@gmail.com wrote: ... So long as users are covering their bandwidth with giveback [1], I think it's safe to assume the rest of their overhead is also covered by the addition of that node to the network. there's always a catch. ;) ... [1] It's already established that in order for your use of Tor bandwidth to be zero sum (in the Hidden Service -- Hidden Service case) you need to give back at least 6x your use. So you will already be running said relay (for the purpose of bandwidth giveback). [2] Isn't there a proposal out there to better handle magnitudes more users [and avoid shutdown points] by getting rid of the directories and self-hosting the TorNet into a DHT or something? Tor would become something else, perhaps UDP Tor. there has been more written on that subject than i can do justice here. i'm fond of DTLS signalling for encapsulated IPsec telescopes with SFQ and DLP transport for multi-homed SCTP endpoints, but that is just one of many possibilities. a grand unified datagram Tor spec has yet to be written... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, Nov 17, 2010 at 5:20 PM, Andrew Lewman and...@torproject.org wrote: ...I wish people would stop cross-posting between -dev and -talk...;) mea culpa; i shall curb my reply-all enthusiasm! grarpamp: i'll follow this up with links for various UDP Tor papers and discussions. i've got a bunch of bookmarks somewhere... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Bitcoin And The Electronic Frontier Foundation
On Tue, Nov 16, 2010 at 7:00 AM, TheGravitator thegravita...@googlemail.com wrote: Its not all i7's, only the i7-980X (extreme series) about $1000. AES-NI is pretty slick. now if only we could get RSA/DSA/DH on die... :) [the benchmarks in question show 875MB/s AES256 on PhenomII X6 1090T @ 3.8Ghz as the closest competitor to the 11,000MB/s on i7-980X w/ AES-NI instruction at less clock.] i haven't had a processor to test with; has any Tor user had luck with openssl-aesni patches against 1.0.0? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Hints and Tips for Whistleblowers - their comments on Tor and SSL - I don't understand.
On Wed, Oct 27, 2010 at 11:49 AM, Jan Weiher j...@buksy.de wrote: ... I'm not aware of any negative impacts on privacy due to the usage of https://, client certificates, although fortunately these are difficult to leverage surreptitiously... ... but without, there is the danger of eavesdropping at the exit node. this is definitely the riskiest aspect and why https is awesome when used correctly. sadly, most https sites don't use https correctly. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TCP stack attack?
On Sat, Oct 23, 2010 at 5:59 PM, Robert Ransom rransom.8...@gmail.com wrote: On Sat, 23 Oct 2010 12:42:11 -0700 Julie C ju...@h-ck.ca wrote: Has anyone come across any TCP stack implementation vulnerability research? ... At this point in my education it strikes me that the TCP stack on any Tor node could be altered to do malicious things, and no one would ever know, or be able to know. Roughly every attack that can be performed in a Tor node's TCP stack can also be performed by anyone that can stick his own hardware between the Tor node and the Internet. There are some attacks that can be performed there, but an attacker who can modify a Tor node's kernel would be able to do more damage by reconfiguring or modifying Tor itself. long of it short: given the spectrum of OS level remote ring0 exploits in network device and protocol attack surface, there is a potential risk here. given all of the other risks [0][1], this is probably the least of your many concerns... best regards, 0. if I were to rank broad category, a. application level arbitrary execution or side channel attack. so many, so frequent to reify and persist, so easy to leverage for full privileged arbitrary execution, so many additional clauses to add but omitted for brevity. (remote w/ priv. escalation, direct remote root/ring0, local escalation, vm break-out, many others) b. Tor deployment weaknesses as commonly built, distributed, and used on various platforms, primarily Windows, Mac and various Linux and Unix like systems to a lesser extent for everyone but node operators. (ex. Unauthenticated control port access with cross protocol vector - implementation / deployment vulnerability) c. Tor usability or correctness deficiencies including the application layer (ex. Firefox with Tor Button Extension - application usability, Transparent Virtualized Privacy Router - configuration correctness: IP and DNS side channel elimination) d. everything else, including mundane issues like not using trojaned hardware out to exotic risk models with chained professional multi-0day targeted efforts or state agency actors. but not the risks that exist outside your threat model, or the un-identifiable and un-conjecturable unknown risks we can't predict or reason about. :/ i mentioned the Threat Model, right? because this entire topic of conversation requires the presumptive act of you having pointed out the threat model you are assumed to be operating under and that we are both discussing. :) 1. remote ring0 do happen, c.f. CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow. fortunately these are rare, extremely valuable (likely to be exposed once propagating), and relatively infrequent compared to most other operating system vulnerability concerns. stuxnet is a good example of the exotic end of this spectrum; unless you yourself are a very well funded or state level actor you're pretty much fucked/ entirely and inevitably fucked. :P *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TCP stack attack?
On Sun, Oct 24, 2010 at 8:28 PM, coderman coder...@gmail.com wrote: ... 1. remote ring0 do happen, c.f. CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow. Forgot to link to the announce in question; it is worthy of a read if only to emphasize why any claim of immunity from a broad class of threats with blanket assurance is a strong claim best made after thorough and extensive effort to prove it to yourself via technical applied testing and measurement. http://www.coresecurity.com/content/open-bsd-advisorie OpenBSD's IPv6 mbufs remote kernel buffer overflow 2007-02-20: First notification sent by Core. 2007-02-20: Acknowledgement of first notification received from the OpenBSD team. ... 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term vulnerability when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems... 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow. 2007-03-05: OpenBSD team notified of PoC availability. 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a reliability fix notice on the project's website. ... The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in: 1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or; 2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic) The issue can be triggered by sending a specially crafted IPv6 fragmented packet. OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration. However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: DNS with Tor (compared to VPNs).
On Wed, Oct 20, 2010 at 4:47 PM, and...@torproject.org wrote: ... : However, my ISP does not see the DNS requests (or the website since : all traffic flows through the encrypted VPN). It depends on the VPN. Many vpns don't touch your dns settings, therefore your local resolver sees the requests. the reverse is not true, however. there are numerous side channels around host default nameserver entries set by VPN software or yourself manually (explicit resolver IP passed to host libs, or custom UDP DNS queries, or caching proxy query reflection, or. etc. am I leaking DNS? turns out to be a complicated question... : If I am using Tor then all DNS resolution is done by the Tor exit : node. No DNS requests leave my computer unencrypted - unlike in the : previous two examples. If the apps are set to use tor correctly, yes. this is one reason why Tor Button or other privacy minded extensions and configurations explicitly disable bad plug-ins and mime types; this is useful for VPN users in general who want leakage resistant DNS privacy through their VPN provider DNS nameservers rather than ISP defaults. again, more complicated than it seems; devil in the technical details according to your uses and threats... best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
On Sat, Sep 25, 2010 at 5:04 PM, Mike Perry mikepe...@fscked.org wrote: ... however, if an attacker has access to read this locally they've already compromised you to a degree that random mac affords no protection... Is this really true? yup. for the very few situations it is not true, you've designed a virtual network and client environment with this class of information leakage covered (read: you know what you're doing and what you're defending against :) One of the things I've wondered about here is plugins, but since Torbutton disables them for other reasons I haven't really looked into it. yes. this is one reason why Torbutton is great regardless of other protections. the list of plug-ins exposing dangerous interfaces / attack surface is about as long as the list of plug-ins for FFox, Chrome only has a prayer as live browser instance (which it does well by the way!). IE, Opera, Safari, most are hopeless. For insance, I know Java can create a socket, and query the interface properties of that socket to get the interface IP. Why not mac address? yup, and/or upstream router details sufficient to geo locate you, expose public IP endpoint, etc. (like the how i met your girlfriend attacks, many others...) And if not java, can one of flash, silverlight, pdf-javascript, or others do this? yes. Already we have location features built in to the browser based on nearby Wifi MACs... yes. :) The Java trick to get the interface IP does not require special privs, so a randomized MAC would in fact help this scenario, if it were somehow possible. yes. :P *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The best way to run a hidden service: one or two computers?
On Fri, Sep 24, 2010 at 4:01 PM, Jacob Appelbaum ja...@appelbaum.net wrote: ... Try the following by hand: sudo ifconfig eth1 hw ether 00:00:00:00:00:00 ... you'll likely need to have the interface down before changing mac: sudo ifconfig eth1 down sudo ifconfig eth1 hw ether random mac sudo ifconfig eth1 up / or dhclient / or pump / or ... however, if an attacker has access to read this locally they've already compromised you to a degree that random mac affords no protection... (remember mac only visible on link-local or host) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: How to Run High Capacity Tor Relays
On Wed, Sep 1, 2010 at 2:28 PM, John Case c...@sdf.lonestar.org wrote: ... I really do think some subset of that discussion should be included in your lore, at the very least the parts pertaining to the built-in crypto acceleration included in recent sparc CPUs, which appear to be the only non-painful way to make this work. if you're running a high capacity relay you likely don't need hw acceleration because: a. you're on a fast server with relatively modern processor to get into the high capacity game. assembly optimized crypto is pretty fast on these systems. b. the compression, buffer management, and other aspects of Tor are just as significant as the crypto specific parts on such a server. c. the crypto hw needed to be effective is expensive, at least a grand, or inside specialized server processors you're unlikely to have in your dedicated / leased server hardware. this is not to say it isn't useful. it's useful in all kinds of ways ranging from efficiency improvements, side channel attack resistance, to entropy sources for strong session key / nonce generation. however, i doubt hardware crypto will prove useful for anyone in the top tier of relay capacity to drastically improve their throughput or efficiency overall given the current architecture of Tor itself. and, as mentioned, there have been a number of threads on the subject, and widely expanded OpenSSL engine support added since last year for those interested in experimenting with hw acceleration. best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Another cost mentioned by coderman was elevated privs for accelerated virtualization / para-virtualization. AFAIK VirtualBox does not need any special privileges (once the kernel part of the software is installed, and the modules/services loaded). the loading / configuring of kernel module part is one elevated task. route table changes / altering iptables rules and chains*, many other such things require elevated privileges. there are often host facilities to permit specific use of valid settings, and rsbac constraints, lots of other mitigation techniques... if you give up acceleration and do full softmmu / user only and constrained device emulation you can still have a guest / least privilege virtual machine, but the overhead is significant. fortunately fast virtio devices are become common across both userspace only and accelerated virtual machine implementations. i also like livecd as you mention, and qubes on live fedora is a nice setup, perhaps coupled with HTTPS-Fuse on-demand pre-caching file system overlays... many many different combinations and techniques to complement and fit a particular need. the limiting factor is time to explore them all and their relative strengths/weaknesses/trade-off's... http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html http://qubes-os.org/Architecture.html * i call this out specifically because you need extend beyond the basic VirtualBox / Qemu / VMWare settings associated with the common bridge, nat, host-only network devices and implement host level routing protections; otherwise you're exposed to a number of potential side channel and other attacks listed in the FAQ and elsewhere. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Please don't misunderstand me. I'm not a fan of VM-based solutions and pretty much prefer the bare-metal + Live OS approach, but I feel we need to consider their pros and cons in a more detailed way than discarding them on the assumption that their cost must be too high else we would push for their usage much more than we do. one last note, these are all complementary techniques. the SELinux effort early on was applied to VMWare virtual machine rules per instance on virtual disks and across network devices. improving the usability of such a configuration by deploying via livecd images supporting a wide range of hardware would also be a clear improvement for many users. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: How to Run High Capacity Tor Relays
On Tue, Aug 24, 2010 at 8:27 AM, Mike Perry mikepe...@fscked.org wrote: ... # Set the hard limit of open file descriptors really high. # Tor will also potentially run out of ports. ulimit -SHn 65000 typically in /etc/security/limits.conf. i like to append: * softnofile 4096 * hardnofile 65535 but on big servers use .25mm as hard limit. (Tor not this fd hungry, 64k is fine) # Load an amalgam of gigabit-tuning sysctls from: ... # We have no idea which of these are needed yet for our actual use # case, but they do help (especially the nf-contrack ones): you probably want to save in /etc/sysctl.conf , then sysctl -p ... net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 2500 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1 net.core.rmem_max = 1048575 net.core.wmem_max = 1048575 ^- these are important and useful net.ipv4.ip_local_port_range = 1025 61000 ^- that's a little aggressive, better to set FIN timeout lower. i like 5000 to 65535 ephemeral port range net.ipv4.tcp_max_syn_backlog = 10240 net.ipv4.tcp_fin_timeout = 30 ^- i like a fin timeout of 3-4 seconds on a busy server, otherwise you've got lots of resources tied up in sockets waiting to die... Tor not quite so volatile as some services, so perhaps 30 is fine. net.ipv4.tcp_keepalive_time = 1200 ^- who uses keepalive? :) net.netfilter.nf_conntrack_tcp_timeout_established=7200 net.netfilter.nf_conntrack_checksum=0 net.netfilter.nf_conntrack_max=131072 net.netfilter.nf_conntrack_tcp_timeout_syn_sent=15 ^- best to just disable conntrack altogether if you can. -J NOTRACK in the raw table as appropriate. you're going to each up lots of memory with a decent nf|ip_conntrack_max ( check /proc/sys/net/ipv4/netfilter/ip_conntrack_max , etc ) [...] some dupes in here? net.ipv4.ip_forward=1 ... net.ipv4.conf.default.forwarding=1 net.ipv4.conf.default.proxy_arp = 1 ^- BAD! this should not be enabled by default unless you're actually routing specifically to guest vm's or between interfaces or something. if you enable forwarding by default, someone may use you to relay some malicious traffic. were these cut and paste errors? remember to disable forwarding first, before tuning other parameters, as changing this value will reset some others back to defaults. (!!) net.ipv4.tcp_syncookies = 1 ^- not usually worth the overhead? net.ipv4.conf.all.rp_filter = 1 ^- note that you need to be precise with your routing metrics and such for multi-homed with rp_filter enabled. also, this costs resources, and if you can avoid it, do so. net.ipv4.conf.default.send_redirects = 1 net.ipv4.conf.all.send_redirects = 0 ^- don't know if these are too useful either. i prefer to limit ICMP beyond this. (perhaps related to forwarding defaults above.) Ex: echo 1 /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 /proc/sys/net/ipv4/icmp_echo_ignore_all echo 0 /proc/sys/net/ipv4/conf/all/accept_redirects echo 1 /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses == Did I leave anything out? == Well, did I? i'd love to see an sca6000 accelerated node. been working with these recently but unfortunately they're allocated for other work... (most of the other crypto hw is going to be bus / implementation limited to less than what a beefy 64bit modern server can provide, so of little utility in this context.) best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 21, 2010 at 5:55 PM, Gregory Maxwell gmaxw...@gmail.com wrote: ... I think it's obvious that the best way of using tor is running your torrified apps in a VM which can only access the outside world via TOR. This provides the highest protection from network leaks and also partially thwarts fingerprinting. But I can only assume that the 'cost' (performance, complexity, etc) of using a VM for tor is too high for many people— otherwise we would insist that anyone who wants anonymity operate that way. not a silver bullet, but tends to fail safer. the costs include: - elevated privs for accelerated virtualization / para-virtualization. Tor by default does not require such. - additional resource consumption. isolated os, network stacks, and applications require additional memory and CPU. - only solve part of the problem; you still need Torbutton and other application level protections, even if direct proxy-bypass type disclosures of endpoint or identity are mitigated. ideally this model would apply across the entire user experience, see qubes: http://qubes-os.org/Home.html Has anyone looked into using the SELINUX sandbox (http://danwalsh.livejournal.com/28545.html) to prevent leaks? The sandbox provides a high degree of application isolation. It looks like it would be pretty much trivial to add an option to the sandbox front end program to only allow accesses to the tor socks port from the isolated app. developing and maintaining a robust RSBAC policy is non-trivial. that said, these are complementary techniques. a strong RSBAC model around and within virtual machine based isolation provides additional defense against application errors, vm break-outs, etc. it doesn't help that a lot of the good SELinux policy development / management tools are closed source / proprietary. it's not the only game in town... With this users on a supporting platforms wouldn't have to use wireshark to figure out if, say, pidgin, is leaking via DNS. They could simply run the app inside the sandbox and be sure of it. there's RSBAC bypass just like vm break-out; anyone claiming infallibility is smoking something or selling you lies... Does this sound like a practice which should be refined and recommended? absolutely! you could submit a series of policies for various Tor modes of operation and solicit feedback / commit to contrib. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Padding again Was: Practical web-site-specific traffic analyses
On Sun, Aug 1, 2010 at 8:02 PM, Gregory Maxwell gmaxw...@gmail.com wrote: ... The overhead of padding schemes that I've seen, either end to end type, or hop-based for free routed networks as presented above, are simply too large to be practical. perhaps DLP with SFQ and datagram transport. could even add endpoint mobility / multi-path for resilience. (it sounds so easy ;) practical can be surprisingly forgiving if the protections are compelling. you could build it and find out... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Practical web-site-specific traffic analyses
On Fri, Jul 30, 2010 at 12:32 PM, Seth David Schoen sch...@eff.org wrote: ... The researchers suggest that web application developers should use padding to make different activities on their sites less distinguishable. That sounds pretty optimistic to me. I've heard other privacy researchers complain that it's extremely hard to get web developers to do things. i've heard QA and security departments complain that it's extremely hard to get web developers to do things! there's a parable about a creek full of excrement and no paddles ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: US Seeks Access to More Internet Data Without Court Order
On Thu, Jul 29, 2010 at 2:16 PM, punkle jones punkle.jo...@gmail.com wrote: ... It's time, finally, for every website to start supporting SSL. What reasons are there not to support it nowadays? money/time, lack of hardware acceleration, certificate management, cross-browser or historical client compatibility, nullification of in-line/transparent caching infrastructure, probably lots more reasons... i agree with your sentiment for the most part. Unless there are bad folks out there actively matching entries to exits and making the info available to your ISP/the guys in suits (there's no reason to entirely doubt this possibility - why not be paranoid?), there won't be a whole heck of a lot of info if you're using TOR. The standard warnings still apply: https://www.torproject.org/download.html.en#Warning traffic confirmation is pretty easy. as for active attacks both near and far end via this route, that's a different question. it does happen, but if you're in that kind of spotlight Tor use is the least of your worries :P This is a very deep topic that IMO goes far beyond simply using TOR and stopping conspicuous behaviors to stymie tracking. I'm no expert on breaking anonymity, so hopefully some of those will chime in. Kyle Williams, or coderman maybe? hah; sadly i lack the discipline to be expert in this subject. you've seen the anobib, right? in general i agree that at the level of scrutiny being discussed here you're either off the radar in the Tor crowd or screwed totally and entirely via all of the other weaker links in your protections. and that's generously assuming your threat model is sufficient and prudent. they don't give out NSL's for just any whim or fancy after all... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Flash Cookies and Tor.
On Thu, Jul 29, 2010 at 2:17 PM, Matthew pump...@cotse.net wrote: ... When I use Tor, I disable Flash. good! However, when not using Tor, sometimes I do use Flash. we all have our vices... I was surprised today to discover in my .macromedia folder on Ubuntu dozens of flash cookies. this will quit surprising you as you begin paying attention. Can these cookies have connected my static non-Tor IP and the various Tor IPs... can the flash cookie connect to the website even when flash is turned off? nope, as long as you NEVER, EVER, NOT EVEN ONCE have Flash enabled while using Tor. or anything with privs (extensions, other plug-ins) that have access to the local store, or other situations where remote disclosure of local file content may occur. an easier consideration, are you consistent about always using a recent and signature verified release of the browser bundle? best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Flash Cookies and Tor.
On Thu, Jul 29, 2010 at 5:34 PM, coderman coder...@gmail.com wrote: ... an easier consideration, are you consistent about always using a recent and signature verified release of the browser bundle? having looked at the download page i see the Linux bundle is at 1.0.9 and beta, while the usual is 1.3.9. these may be totally incomparable sequences but the above advice is more apropos Windows users (the majority) than yourself... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Mon, Jul 5, 2010 at 6:49 PM, Jacob Appelbaum ja...@appelbaum.net wrote:
...
I haven't seen a PERL version of the program - do you have a link to the
source?
this is the only copy i have on hand. i believe there is an updated
version in bsd ports archive (no longer in current mirrors).
best regards,
#!/usr/bin/perl
#
# dns-proxy-tor
#
# This script has been dedicated to the public domain.
# See LICENSE file included with this distribution for the dedication.
#
use strict;
use warnings;
our $VERSION = '0.0.6';
{
package Log;
use strict;
use warnings;
use constant INFO = 0;
use constant DEBUG = 1;
my @Levels = qw/INFO DEBUG/;
my @Attributes = qw/level handle/;
our %Log = (level = 1);
our $Err;
sub _self {
my $class = __PACKAGE__;
no strict 'refs';
return \%$class;
}
sub init {
my $self = shift-_self;
%$self = @_;
if (not $self-{handle} and not open $self-{handle}, '', $self-{file}) {
$Err = Can't open log file $self-{file}: $!\n;
return;
}
select( (select($self-{handle}), $| = 1)[0] );
return 1;
}
sub close {
my $self = shift-_self;
close $self-{handle};
}
for my $attribute (@Attributes) {
no strict 'refs';
*$attribute = sub {
use strict 'refs';
my $self = shift-_self;
$self-{$attribute} = shift if @_;
return $self-{$attribute};
};
}
for my $level (@Levels) {
no strict 'refs';
*{lc $level} = sub {
my $self = shift-_self;
return unless $self-{level} = $level;
use strict 'refs';
my $fh = $self-{handle};
printf $fh @_;
};
}
1;
}
{
package DNS::Session;
use strict;
use warnings;
use Socket;
use constant SERVFAIL = 0x8102;
use constant NOERROR = 0x8100;
use constant TYPE_A = 1;
use constant CLASS_IN = 1;
use constant NAME_PTR = 0xc00c;
sub new {
my $class = shift;
my $self = {
sessions = {},
last_timeout = time,
@_
};
bless $self, $class;
}
sub add_request {
my ($self, $dns_request) = @_;
Log-debug(Adding session for %s\n, $dns_request-domain);
push @{ $self-{sessions}{lc $dns_request-domain} }, $dns_request;
}
sub _pack_name {
join( '', map chr(length).$_, split /\./, $_[1] ).\0;
}
sub _pack_response {
my ($self, $id, $flags, $req_type, $domain, $addr) = @_;
my ($qd, $an, $ns, $ar) = (1, 0, 0, 0);
my $answer;
if ($addr) {
$an = 1;
$answer = pack('n3Nn', NAME_PTR, TYPE_A, CLASS_IN, 0, 4).inet_aton($addr);
}
# header
my $response = pack 'n6', $id, $flags, $qd, $an, $ns, $ar;
# question
$response .= $self-_pack_name($domain).pack('n2', $req_type, CLASS_IN);
# answer
$response .= $answer if $an;
return $response;
}
sub exists {
my ($self, $domain) = @_;
return exists $self-{sessions}{lc $domain};
}
sub flush {
my $self = shift;
$self-send_response($_ = 0)
for keys %{ $self-{sessions} };
}
sub send_response {
my ($self, $domain, $addr) = @_;
if (not $self-exists($domain)) {
Log-debug(Session not found for $domain\n);
return;
}
my $requests = $self-{sessions}{lc $domain};
my $flags = $addr ne '0' ? NOERROR : SERVFAIL;
undef $addr if $addr eq '0';
while (my $request = shift @$requests) {
if (defined $addr) {
Log-info(Resolved %s = %s, sent to %s:%s\n, $domain, $addr,
$request-remote_addr, $request-remote_port);
} else {
Log-info(Failed to resolve %s, sent to %s:%s\n, $domain,
$request-remote_addr, $request-remote_port);
}
my $response = $self-_pack_response(
$request-id,
$flags,
$request-type,
$request-domain,
$addr
);
send $self-{handle}, $response, 0, $request-remote_sa;
}
delete $self-{sessions}{lc $domain};
}
sub timeout {
my $self = shift;
my $limit = time - $self-{timeout};
return if $limit $self-{last_timeout};
for (keys %{ $self-{sessions} }) {
delete $self-{sessions}{$_}
if $self-{sessions}{$_}[0]-time $limit;
}
$self-{last_timeout} = time;
}
sub handle {
my $self = shift;
$self-{handle} = shift if @_;
return $self-{handle};
}
1;
}
{
package DNS::Request;
use strict;
use warnings;
use Socket;
use constant INVALID= 0;
use constant FORMERR= 0x8101;
use constant SERVFAIL = 0x8102;
use constant TYPE_A = 1;
use constant TYPE_ = 0x1c;
use constant CLASS_IN = 1;
use constant MAX_LABEL_LEN = 63;
use constant MAX_DOMAIN_LEN = 255;
sub receive {
my ($class, $handle) = @_;
my $remote_sa = recv $handle, my $query, 512, 0;
return unless defined $remote_sa;
my $self = {
query = $query,
remote_sa = $remote_sa,
time = time
};
bless $self, $class;
}
sub _unpack_name {
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
#!/usr/bin/perl
#
# dns-proxy-tor
#
# This script has been dedicated to the public domain.
# See LICENSE file included with this distribution for the dedication.
#
use strict;
use warnings;
our $VERSION = '0.0.6';
{
package Log;
use strict;
use warnings;
use constant INFO = 0;
use constant DEBUG = 1;
my @Levels = qw/INFO DEBUG/;
my @Attributes = qw/level handle/;
our %Log = (level = 1);
our $Err;
sub _self {
my $class = __PACKAGE__;
no strict 'refs';
return \%$class;
}
sub init {
my $self = shift-_self;
%$self = @_;
if (not $self-{handle} and not open $self-{handle}, '', $self-{file}) {
$Err = Can't open log file $self-{file}: $!\n;
return;
}
select( (select($self-{handle}), $| = 1)[0] );
return 1;
}
sub close {
my $self = shift-_self;
close $self-{handle};
}
for my $attribute (@Attributes) {
no strict 'refs';
*$attribute = sub {
use strict 'refs';
my $self = shift-_self;
$self-{$attribute} = shift if @_;
return $self-{$attribute};
};
}
for my $level (@Levels) {
no strict 'refs';
*{lc $level} = sub {
my $self = shift-_self;
return unless $self-{level} = $level;
use strict 'refs';
my $fh = $self-{handle};
printf $fh @_;
};
}
1;
}
{
package DNS::Session;
use strict;
use warnings;
use Socket;
use constant SERVFAIL = 0x8102;
use constant NOERROR = 0x8100;
use constant TYPE_A = 1;
use constant CLASS_IN = 1;
use constant NAME_PTR = 0xc00c;
sub new {
my $class = shift;
my $self = {
sessions = {},
last_timeout = time,
@_
};
bless $self, $class;
}
sub add_request {
my ($self, $dns_request) = @_;
Log-debug(Adding session for %s\n, $dns_request-domain);
push @{ $self-{sessions}{lc $dns_request-domain} }, $dns_request;
}
sub _pack_name {
join( '', map chr(length).$_, split /\./, $_[1] ).\0;
}
sub _pack_response {
my ($self, $id, $flags, $req_type, $domain, $addr) = @_;
my ($qd, $an, $ns, $ar) = (1, 0, 0, 0);
my $answer;
if ($addr) {
$an = 1;
$answer = pack('n3Nn', NAME_PTR, TYPE_A, CLASS_IN, 0, 4).inet_aton($addr);
}
# header
my $response = pack 'n6', $id, $flags, $qd, $an, $ns, $ar;
# question
$response .= $self-_pack_name($domain).pack('n2', $req_type, CLASS_IN);
# answer
$response .= $answer if $an;
return $response;
}
sub exists {
my ($self, $domain) = @_;
return exists $self-{sessions}{lc $domain};
}
sub flush {
my $self = shift;
$self-send_response($_ = 0)
for keys %{ $self-{sessions} };
}
sub send_response {
my ($self, $domain, $addr) = @_;
if (not $self-exists($domain)) {
Log-debug(Session not found for $domain\n);
return;
}
my $requests = $self-{sessions}{lc $domain};
my $flags = $addr ne '0' ? NOERROR : SERVFAIL;
undef $addr if $addr eq '0';
while (my $request = shift @$requests) {
if (defined $addr) {
Log-info(Resolved %s = %s, sent to %s:%s\n, $domain, $addr,
$request-remote_addr, $request-remote_port);
} else {
Log-info(Failed to resolve %s, sent to %s:%s\n, $domain,
$request-remote_addr, $request-remote_port);
}
my $response = $self-_pack_response(
$request-id,
$flags,
$request-type,
$request-domain,
$addr
);
send $self-{handle}, $response, 0, $request-remote_sa;
}
delete $self-{sessions}{lc $domain};
}
sub timeout {
my $self = shift;
my $limit = time - $self-{timeout};
return if $limit $self-{last_timeout};
for (keys %{ $self-{sessions} }) {
delete $self-{sessions}{$_}
if $self-{sessions}{$_}[0]-time $limit;
}
$self-{last_timeout} = time;
}
sub handle {
my $self = shift;
$self-{handle} = shift if @_;
return $self-{handle};
}
1;
}
{
package DNS::Request;
use strict;
use warnings;
use Socket;
use constant INVALID= 0;
use constant FORMERR= 0x8101;
use constant SERVFAIL = 0x8102;
use constant TYPE_A = 1;
use constant TYPE_ = 0x1c;
use constant CLASS_IN = 1;
use constant MAX_LABEL_LEN = 63;
use constant MAX_DOMAIN_LEN = 255;
sub receive {
my ($class, $handle) = @_;
my $remote_sa = recv $handle, my $query, 512, 0;
return unless defined $remote_sa;
my $self = {
query = $query,
remote_sa = $remote_sa,
time = time
};
bless $self, $class;
}
sub _unpack_name {
my ($self, $pos) = @_;
return if length $self-{query} $pos + 2;
my @labels;
while (my $len = ord substr $self-{query}, $pos, 1) {
return if ($len 0xc0) == 0xc0 or length $self-{query} $pos+$len+2;
push @labels, substr $self-{query}, ++$pos, $len;
$pos += $len;
}
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Sun, Jul 4, 2010 at 3:17 PM, coderman coder...@gmail.com wrote: ... a better wording: ... ultimately, any application that uses DNS or UDP may compromise your anonymity. i should mention that the Tor Browser Bundle when used as directed has been and continues to be most resilient to these attacks. while this is a very limited environment (no plug-ins, flash, java, etc.) these limitations are a feature ensuring your protection. when you start using arbitrary applications or plug-ins with Tor or any other anonymity service you open yourself up to great risk as described here for DNS, not to mention other side channels avenues using TCP directly. best regards, (hi pedants!) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Mon, Jul 5, 2010 at 6:49 PM, Jacob Appelbaum ja...@appelbaum.net wrote: ... Nice catch. Do you want to provide some test cases for this? I guess it would be nice to see how wide-spread this problem is - it would also help us build in some protection mechanisms. to manually test: 1. route -n or equiv to find default gateway (running dproxy-nexgen or equiv. DNS proxy / resolver) (for remainder of this sequence 192.168.1.1 is assumed to be router and dproxy host) 2. dig @192.168.1.1 192.168.1.1 3. observe the ISP provided hostname in answer 4. dig @192.168.1.1 ISP hostname 5. observe public IP endpoint address in answer not sure how many routers run this kind of stuff, but they number in the millions. (cheap Linux routers, Wifi captive portals, etc.) as for Java test case, i can dig up the applet code from ages back, if i've got it. i recall another avenue via sun.net.spi.nameservice.provider and sun.net.spi.nameservice.nameservers. there is also a mechanism via JNI to use _res.options global to reset DNS bindings, and open up other attacks. (although if you've got JNI access these are all less interesting approaches.) Having a local DNS server is useful; many applications may only support SOCKS4, rather than SOCKS4A or SOCKS5 - their failure could lead to de-anonymization. It is also useful to ensure that possible DNS leaks will fail closed - if your system only knows about 127.0.0.1:53, it's hard but not impossible to leak DNS packets to the public internet. not really hard in any sense of the word. :( Can you give me an example of how you'd do this? I know that if a user does something like `dig @8.8.8.8 torproject.org` - the query won't go to 127.0.0.1:50 - But if you can do that, you've already won in a very serious way consider the case of a link local resolver like above, or any DNS server on the LAN for public routed requests. you don't need arbitrary execution; i agree that's game over in any case. I haven't seen a PERL version of the program - do you have a link to the source? I noticed a newish python version was written by Dug Song. I think it's similar in scope to ttdnsd. yeah, not to be confused with the dsocks python version. i'll find a copy and forward it on. i know it's around here somewhere... the best of all worlds would combine: - virtualaddrnetwork based immediate resolve and map I'm not sure that this is too useful because of the issues with OpenSSH; I'd prefer that it simply fail. right, i usually don't like this behavior. but sometimes it is very handy, particularly when applications cache negative responses for too long, or aggressive DNS rebinding attack prevention makes a resolution last much longer than you'd like. (in which case, in is better to be stuck to a binding against 10.x or other virtualnetwork addr that can reconnect on the TCP side rather than having an old public DNS mapping that persists beyond TTL, etc.) this is all a bit technical, and i agree that the above is the lesser desired behavior. ... Can you give me an example of that happening with ttdnsd? I'm not sure that I've ever encountered it with Tor; generally I find negative caching issues like that one to be a bug. i'm thinking of the Windows DNS cache behavior. it probably should be considered a bug :) It sounds like you have some great stuff up your sleeve; you should help hunt the DNS de-anonymization unicorns. :-) If a user's local DNS resolver is 127.0.0.1 (via ttdnsd), a user will not be able to leak information as easily as it will with a network or non-Torifed resolver. agreed. the issue is when you've got a link-local resolver accessible, and a mechanism to perform DNS queries against it. in such a case, the host configuration of 127.0.0.1 is simply ignored, and an explicit local resolver is queried. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
great info! my comments below... On Fri, Jul 2, 2010 at 6:15 PM, Jacob Appelbaum ja...@appelbaum.net wrote: ... While Tor users should always use Torbutton[-1] for their web browsing, not all applications have an equivalent plugin available. Torbutton addresses DNS leaks from within Firefox by ensuring that Firefox uses the local Tor proxy for its DNS name lookup requests. However, other applications may not do this and may, as a result, leak DNS requests. We try to discover if popular applications are leaky but, ultimately, any application that makes a DNS request may compromise your anonymity unless specifically configured to make that request over Tor. The central concern is thus for an applications that don't know to send their name lookup requests via Tor, or don't know how to do so. Tor can't protect these applications' requests. a better wording: ... ultimately, any application that uses DNS or UDP may compromise your anonymity. best intentions fail in the face of an attacker in most circumstances. Java can be configured to use explicit resolver endpoints regardless of suggested default proxy or other configuration. raw UDP sockets via third party plug-ins are worst case. note that even with transparent proxy configuration and DNS port you are at risk if the attacker can direct explicit DNS requests to a local resolver (over link-local route, not default gateway). this type of attack affects all VPN or transparent proxy configurations that do not use a /29 point-to-point router path. to add insult to injury, many commercial Linux based routers like ActionTek and D-Link use dproxy-nexgen resolvers accessible at link-local 192.168.1.1. a reverse lookup of the gateway itself provides not just the internal address but also the public IP and hostname from ISP. there are other caching resolvers used in captive wifi portals and other locations with same behavior. ... Having a local DNS server is useful; many applications may only support SOCKS4, rather than SOCKS4A or SOCKS5 - their failure could lead to de-anonymization. It is also useful to ensure that possible DNS leaks will fail closed - if your system only knows about 127.0.0.1:53, it's hard but not impossible to leak DNS packets to the public internet. not really hard in any sense of the word. :( === Old Hope: tor-proxy-dns ... Once, a long time ago, we had a super star programmer named Tup in our community. He was anonymous to us. He was a programming machine and we really miss him. We often wonder and worry about what has happened to our friend. He would crank out code in a myriad of languages that served all sorts of useful purposes. One of the things that he wrote was a small program in Python called tor-proxy-dns; this software was useful but written in Python, abandoned by the missing superstar, and generally lost to the sands of time. PERL, but that doesn't detract from the awesome that is Tup. sadly, we are not currently temporally propinquitous with Tup. VirtualAddrNetwork is an obscure but very useful option for decreasing latency at connection time. When enabled, Tor will automatically return a specially mapped IP address. Eventually, Tor will learn the real address and keep an internal mapping between the virtual address and the real address. Tor remembers this mapping for the duration of execution but it is not saved between Tor restarts. This works except in cases where the IP address is noted by an application, such as OpenSSH. This will decrease perceived and actual latency but it has frustrating side effects for some applications. the other trade-off with this approach is that is behaves very poorly with some applications that expect name resolution to fail on un-reachability (like .onion or .exit) rather than in-determinate connection establishment. that is, your application may resolve a random site or hidden service immediately and attempt to connect, but this attempt (via transparent transport access) may hang indefinitely for minutes before success or failure. some prefer to have more explicit control over these resolution timers and timeouts. = A New Hope: ttdnsd === ... coming soon: clever play on star wars idiom the best of all worlds would combine: - virtualaddrnetwork based immediate resolve and map - dnsport transparent resolve through Tor - ttdnsd based tunneled TCP DNS from exit - host based interception and/or filtering mechanisms against side channels around the above until then you're exposing yourself to specific attacks and providing poor end user experience in other situations. = Caching Answers == ... a discussion of negative caching might be useful. some people encounter situations where they get a positive responsive from an explicit request but host based resolver facilities still return not
Re: The State of the DNS and Tor Union (also: a DNS UDP - TCP shim)
On Sun, Jul 4, 2010 at 3:17 PM, coderman coder...@gmail.com wrote: ... this type of attack affects all VPN or transparent proxy configurations that do not use a /29 point-to-point router path. apologies; that should read: /31 point-to-point router path. i've been dealing with service provider annoyances too much lately.. :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Browser Bundle for GNU/Linux 1.0.0 Released
On Sat, Mar 27, 2010 at 3:44 AM, Mike Perry mikepe...@fscked.org wrote: ... we've come to the conclusion that we need to do a bit more to protect our users against Firefox... In addition, we've decided to try to deploy a list of popular sites that have insecure https functionality that can be secured by NoScript... certlock add-on would be useful too... even better if seeded with perspectives like validated cert details for the popular targets, like those you listed above. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Searching for good ISPs
On Fri, Feb 19, 2010 at 4:22 PM, wuiv yccwg wuivyc...@googlemail.com wrote: ... Basically, I am after some feedback and maybe a wish list or suggestions. What Tor community would like to see in such kind of service provider? Tor is a decentralized architecture. why use Tor in your centralized (even if distributed) network? based on your description a one or two hop VPN service would fit the needs of your customers and design nicely. attempting to use Tor in such a configuration would only mislead your users about the potential privacy and security that could be afforded. perhaps i have misunderstood the nature of your hosted Tor service. best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TOR Blocked at Universities
On Thu, Feb 11, 2010 at 11:15 AM, Peter Farver farv...@auburn.edu wrote: TOR is now blocked campus-wide at Auburn University (for all 24,000 students) because of apparent attacks emanating from the TOR network. can you elaborate on that? are these apparent attacks coming _from_ the Tor exits or are Tor clients being used to circumvent network policy, etc? Whenever trying to run TOR, TOR cannot get past the 10% mark. do bridges work or is this identifying Tor client signature to filter? best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: browser fingerprinting - panopticlick
On Thu, Jan 28, 2010 at 2:33 PM, Mike Perry mikepe...@fscked.org wrote: ... I want to point out that Torbutton's obfuscation features are only intended to make you appear uniform amongst other Tor users. Tor users already stick out like a sore thumb because of using exit IPs, and the small numbers relative to the rest of your vistor base will make Torbutton's obfuscated settings appear very unique compared to regular visitors. it would be nice if the tool could distinguish between persistent uniqueness and ephemeral / transient settings like those employed by Torbutton and other privacy proxies (which randomize some aspects of the request and/or headers). this is not a trivial task though... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
browser fingerprinting - panopticlick
EFF has an interesting tool available: https://panopticlick.eff.org/ technical details at https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy an interesting look at exactly how distinguishable your default browser configuration may be... best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Google in China
On Tue, Jan 12, 2010 at 4:23 PM, downie - downgeo...@hotmail.com wrote: This may have consequences for demand for (or attacks against) Tor: http://googleblog.blogspot.com/2010/01/new-approach-to-china.html weaponized 0days in IE leveraged for this assault are a disturbing escalation. the targets of their interest imply relevance to Tor now or in the near future. Google funding/developing large scale decentralized anonymity and circumvention technologies would be a welcome retort against the coming constraints in .cn and elsewhere. interesting times! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Google in China
On Thu, Jan 14, 2010 at 4:52 PM, Ted Smith ted...@gmail.com wrote: ... Opposing censorship (not on moral grounds, but they've attacked us so we're leaving grounds) is very different from supporting anonymity. right. hence would be nice as a qualifier. in any case, it is interesting that these attacks on their lawful intercept functions occurred just days after hosting a closed-door symposium on circumventing censorship They haven't made the move that would help tor yet. perhaps not in this manner exactly, however they have helped Tor. Summer of code and the secure Thandy updater funding just two examples... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Anyone running Tor on routing/switching hardware ?
On Mon, Oct 26, 2009 at 8:52 AM, John Case c...@sdf.lonestar.org wrote: ... I am particularly interested in whether there are performance advantages to be had in running Tor on dedicated network hardware. maybe. yes in that network hardware often provides hardware accelerated crypto primitives that can be utilized by Tor to accelerate the CPU bound aspects of relaying a large amount of traffic. no since hardware acceleration is poorly supported in OpenSSL let alone via direct offload in Tor itself. the latter is necessary to truly take advance of hardware acceleration for large chunks of CTR mode or Montgomery multiplication given shortcomings in the OpenSSL API's used by Tor. if you have a hardware entropy device and a good userspace entropy daemon / mixer this is always useful to Tor and OpenSSL in general. this is manged outside of Tor or OpenSSL by administrator however. as for particular hardware acceleration support the archives of this list provide some details. best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Gmail
On Mon, Aug 31, 2009 at 9:44 PM, grarpampgrarp...@gmail.com wrote: Noticed today that gmail is again requiring new account creation to use SMS verification. someone should set up a gmail invite spooler on a hidden service. many gmail users probably have 100 or so invites sitting around... (invites do not need to be delivered to valid addresses; you can check your sent folder for the invite code with a bogus dest.) best regards,
Re: Tor/Iptables Question
On Thu, Aug 20, 2009 at 4:55 AM, Ringo2600den...@gmail.com wrote: ... I can't connect to any websites, but I can send requests out. Is there anything obvious I'm missing or a something I should add? ... try adding: iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT before: #disallow all external incoming connections sudo iptables -A INPUT -p TCP -j DROP otherwise that last one is killing all incoming TCP packets. best regards,
Re: More Secure Tor Browsing Through A Virtual Machine in Ubuntu
On Thu, Aug 20, 2009 at 9:05 AM, Curious Kidletsshareinformat...@yahoo.com wrote: .. How is entropy gathered in virtual machines? Will it tell you if there is not enough entropy to support unpredictable routing and encryption? (Or is that even an issue at all with Tor?) hi Curious, entropy in virtual machines can be a serious problem. (see Cloud computing needs more chaos). this can be mitigated by passing entropy into the VM and keeping seed state persisted on virtual disk between runtime instances. further improvement would entail an entropy daemon like rngd inside the guest VM receiving entropy from the host. Tor VM does persist the /dev/random seed state on virtual disk and also hashes the kernel command line passed to the VM for mixing into guest entropy pool. this has less entropy than would be desired, however. i have created a new flyspray to improve this further: http://bugs.noreply.org/flyspray/index.php?do=detailsid=1067 best regards,
Re: windows tor
On Wed, Aug 12, 2009 at 10:23 PM, Peternecedema...@gmail.com wrote: I'm not complaining about it, I'm just saying, if you want widespread adoption, a kernel driver is the way to go. And moreover, a kernel driver is easier to write and support than a VM. hi Peter, there are various reasons for the design decision chosen; a kernel driver would certainly be useful for non-ethernet Windows clients who want a transparent Tor proxy. the advantages of a VM hosting Tor and performing the transparent redirection is that the Windows TCP/IP stack is bypassed entirely, avoiding issues with non-paged pool socket buffer resources and many socket file descriptors/handles. it is also simpler to write and maintain a Qemu based transparent Tor proxy virtual machine using existing WinPCAP features for the bridged network mode and having Windows route through this VM. a kernel driver to do this would require an intermediate layer driver with hooks into all of the various L3/L4 protocols and winsock2 / firewall capabilities (to do securely / properly). long term it would be great to have a well supported intermediate layer transparent Tor proxy interface that works on win2k through win7, however, this is simply too much an effort for the limited resources available. if you're willing to help with such an effort that would be great but it sounds like you're already overloaded. in any case, this solves just one part of the Tor puzzle. you really do need Firefox and Torbutton to use Tor properly. see https://www.torproject.org/torbutton/design/ for all the details. a transparent proxy mode may protect against IP disclosure side channels but there are still many other privacy risks worth protecting against. best regards,
Re: Libevent errors with running Tor on a virtual server
On Sat, Aug 8, 2009 at 2:06 AM, D-503d-...@awxcnx.de wrote: ... I'm just wondering if this will or is already causing problems like aborting connections or I can just improve my node behavior with some settings. you are already causing some problems; if someone tries to extend a circuit or exit a stream through your relay when this happens it will fail, wasting effort / causing intermittent issues. (they will try again somewhere else, and succeed, most likely) can you contact your hosting provider and see if they'll make an exception? I know that my hosting provider isn't happy with Tor and already cancelled one exitnode-owner's contract because of abuse-notifications so I don't think he will raise ulimit for me thus I can run Tor better :) well, you don't need to mention Tor specifically. any network intensive application may need more than 1024 descriptors. good luck! best regards,
Re: Libevent errors with running Tor on a virtual server
On Fri, Aug 7, 2009 at 8:53 AM, D-503d-...@awxcnx.de wrote: ... I'm not allowed to raise the ulimit above 1024 then you've got a problem. you may not be able to run a useful relay in this situation. can you contact your hosting provider and see if they'll make an exception? ... Yes I read this already and there is also the ConstrainedSockets mentioned. But in the Tor-Manpage is written this should be used if I get the:Error creating network socket: No buffer space available message in the logs but my error is different. you must fix the 1024 ulimit first. once that is resolved, you may run into the socket buffer issue next and have to set ConstrainedSockets. best regards,
Re: Which proxy to use?
On Sat, Aug 1, 2009 at 9:19 AM, Mr. Bluetrashd...@yahoo.com wrote: My requirements are: 1) It must have privoxy's functionality: hide-tor-exit-notation header filter to remove the Tor exit node notation in Host and Referer headers. exit notation as used this way is a deprecated feature. it will be removed at some point. you really want the controller to direct an exit for you, if you need it, rather than some mangled domain names implying the choice. 2) Must be capable to run as a reverse proxy. ... what are you trying to do, exactly? best regards,
Re: Issue creating a private tor network
On Sun, Aug 2, 2009 at 10:12 AM, Cedric Follcedric.f...@gmail.com wrote: ... I'm trying to create a private tor network.. i assume you've read the FAQ entry, and you might find an earlier thread on the subject informative. http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#HowdoIsetupmyownprivateTornetwork.3F http://archives.seul.org/or/talk/Oct-2007/msg00071.html best regards,
Re: Hidden Service Weirdness
On Sat, Jul 25, 2009 at 3:26 AM, Ringo2600den...@gmail.com wrote: ... For some reason qemu doesn't want to redir port 80 to the guest's port 80. I'm sure nothing else is listening on my host's 80. Any other ideas or possible solutions to this? unfortunately you must run qemu as root to bind to privileged ports like 80, which negates some of the protections you're hoping to provide. the best solution would be correct behavior from wordpress. perhaps someone in that community has encountered this situation and knows what configuration or code changes are required. best regards,
Re: New option DirPortFrontPage
On Sat, Jul 25, 2009 at 7:55 PM, downie -downgeo...@hotmail.com wrote: Hi, is DirPortFrontPage only available to Directory Mirror operators? difficult to have a DirPort open otherwise :) If so, what is the additional overhead of mirroring the Directory? someone else can speak to the realworld load added better than i, however if you're running a server behind a NAT you may have to contend with another forwarded port and additional strain on your connection tracking resources. And finally, what is the option syntax? DirPortFrontPage FILENAME When this option is set, it takes an HTML file and publishes it as / on the DirPort. Now relay operators can provide a disclaimer without needing to set up a separate webserver. There's a sample disclaimer in contrib/tor-exit-notice.html. best regards,
Re: Hidden Service Weirdness
On Mon, Jul 13, 2009 at 12:06 AM, Ringo2600den...@gmail.com wrote: ... When I visit the wordpress directory, I get a timeout and Firefox tries to go through port 5022. this is wordpress sucking. it tries to be helpful and always explicitly list non-80 ports in complete URI's. you can try running on port 80 in the VM (and --redir tcp:80::80), setup apache mod_rewrite, or get wordpress to quit sucking. (there might be a more effective method, but i don't like wordpress, so have no idea what it might be.) good luck,
Re: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 10:38 PM, Ringo2600den...@gmail.com wrote: ... I still feel like there's got to be a simpler way to do this. iptables owner match (by process uid) is simpler, both LAMP and Tor in a single VM. restrict outbound for LAMP user processes. lightweight appliance type virtual machines can be light on resource consumption even with many running concurrently. the LAMP stack will be the most resource intensive part. best regards,
Re: Running a Tor Server as a Tax Deduction?
i had the best luck positioning Tor relay contribution as a way to support the Sarbanes-Oxley Act whistleblower retaliation provision with my last employer. but even that was a stretch... best regards,
Re: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 6:10 PM, Ringo2600den...@gmail.com wrote: ... One could.. run Tor inside the vm and have that torrc contain the instructions for the hidden service. The problem then, is that the vm has to access the web. ... Of course, one could always run a hidden service on the host machine and then redirect all traffic to the vm, but the pitfalls in this are obvious Does anybody have any solutions to this dilemma or thoughts on ways to restructure the model so this isn't a problem? in such a configuration i prefer to use two virtual machines. one vm has host-only networking to serve hidden service content. second vm hosts Tor router with hidden service pointed at vm host. host uses iptables redirect and/or tcp proxy to connect hidden service connections from Tor VM to hidden service VM port at host-only endpoint. (there are variations on this theme...) best regards,
Re: Ping times with Tor running
On Sat, Jun 27, 2009 at 8:50 AM, Udo van den Heuveludo...@xs4all.nl wrote: On 2009-06-27 17:47, Kris Linquist wrote: Is this expected ...? Traffic shaping. http://lartc.org/wondershaper/ see also http://git.torproject.org/checkout/tor/master/contrib/linux-tor-prio.sh
Re: jurisdictional concentration of authorities
On Sun, Jun 21, 2009 at 11:04 PM, Scott Bennettbenn...@cs.niu.edu wrote: ...Where would I find that, please? The only pointer I have at present for the proposals is.. try https://git.torproject.org/checkout/tor/master/doc/spec/proposals/ best regards,
Re: Iptables configuration for a transparent proxy for a single user
On Fri, May 15, 2009 at 2:00 PM, unknown unkn...@pgpru.com wrote: ... Any possible vulnerabilities here? make sure control port is disabled or properly authenticated; otherwise a good setup. an improvement is white listing Tor process with direct access and all other traffic is transparently re-routed through Tor. this protects against attacks where embedded content or network filesystem based URIs are used to initiate requests through a kernel subsystem or other process not associated with the anonymous Tor network user. (this is a relevant issue on Windows, less so unix like systems) best regards,
Re: How to deal with OS hibernation
On Wed, Apr 22, 2009 at 11:34 AM, Marcus Griep tormas...@xpdm.us wrote: ... When you restore your computer from hibernation, Tor picks up right where it left off, but notes that the system clock has jumped forward... circuits may now be invalid,... while this is not a problem for clients (they won't be sending traffic while OS is hibernating) it does cause interruption for others using your relay as a bridge or exit. when you terminate and/or OS hibernate any circuits with your relay in them will fail. if you are not a guard or stable exit the impact of this might be minimal in practice. best regards,
Re: Clock problems
On Sun, Mar 8, 2009 at 8:20 PM, downie - downgeo...@hotmail.com wrote: ... A few days ago I had some overnight broadband outages. FWIW the clock synchronises to Apple's server, I'm not sure how often, and I haven't had any warnings about being out of sync. you could check /var/log/system.log for things like: Mar 9 01:24:55 imac ntpd[3721]: time reset -0.173970 s Mar 9 01:49:24 imac ntpd[3721]: time reset +0.168392 s (also bzcat /var/log/system.log.*.bz2 | grep ntpd) if ntpd is quiet, you've got something else affecting the clock jumps... best regards,
Re: Clock problems
On Sun, Mar 8, 2009 at 6:16 PM, downie - downgeo...@hotmail.com wrote: ... [warn] Your system clock just jumped 160 seconds forward; assuming established circuits no longer work. There are big blocks of these errors occuring 3 minutes 40 seconds or so apart, for 3 hours. The reported clock jump is always 150-170 seconds, and always forwards. ... this sounds like the expected behavior of ntpd issuing adjtime() calls to slowly bring your clock skew down to current time. this can take hours depending on how large of an adjustment is needed. is the computer off for a longer period of time than usual when such behavior occurs? from OSX adjtime man page: DESCRIPTION Adjtime() makes small adjustments to the system time, as returned by gettimeofday(2), advancing or retarding it by the time specified by the timeval delta. If delta is negative, the clock is slowed down by incrementing it more slowly than normal until the correction is complete. If delta is positive, a larger increment than normal is used. The skew used to perform the correction is generally a fraction of one percent. Thus, the time is always a monotonically increasing function... also, ntpd / ntpdate may also perform similar incremental adjustment themselves: [ntpd|ntpdate may] step the time using settimeofday(2) if the offset is greater than +-128 ms. Note that, if the offset is much greater than +-128 ms in this case, it can take a long time (hours) to slew the clock to the correct value. During this time, the host should not be used to synchronize clients. best regards,
Re: aes performance
On Mon, Feb 23, 2009 at 8:23 AM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... It would be nice if Tor was using bigger blocks, but I've not looked at the code yet. i think you mean buffers (or at least multiples of 16 byte blocks); and yes the 4096 byte or larger buffers would be nice to get the most of the rep style XCRYPT instruction chaining. ... clock frequency isn't very high, so something else (instead of encryption) may become the bottleneck. it is also worthwhile to accelerate the public key ops with MONTMULT on the padlock core. there is assembly optimized code for this in openssl 0.9.9 (work in progress). the bottleneck for Tor on these CPU's becomes the libz compression/decompression overhead with padlock enabled. best regards,
Avoiding HTTPS pitfalls [was: Re: Moxie Marlinspike]
On Thu, Feb 19, 2009 at 4:17 AM, Erilenz eril...@gmail.com wrote: ... Lots of people simply don't know how to use Tor safely. agreed. i always recommend two things when using HTTPS over Tor: - install the petname toolbar. this will also notify you if some rogue CA is suddenly signing the google.com certs, for example, not just that encryption isn't used. - save bookmarks to sites that support HTTPS only (secure cookies) with the https:// secure URL. (no insecure transition). I wonder if something could/should be built into TorButton to force a list of commonly used services to go entirely over https? Eg any request for ^http://mail\.google\.com/.*$ a plugin to enforce secure cookies and https only operation for some domains would be useful. i don't know of any that do this kind of thing yet... best regards,
Tor on virtual servers [was: Re: Suspended..]
On Mon, Feb 23, 2009 at 8:27 AM, Andy Dixon a...@andydixon.com wrote: ... Who do you use as a VPS provider..? note that because a Virtual private server is usually sharing kernel networking resources with other vservers you're likely to encounter limits of some kind that will cause problems. see: http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#VServer and the ConstrainedSockets option and kernel tuning parameters, if available to you. best regards,
Re: aes performance
On Mon, Feb 23, 2009 at 12:29 PM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: ... My upload speed is much too slow to run into this problem, but could the compression be (partially) disabled for middle nodes? I'm assuming that the data they are relaying has already been compressed + encrypted, so it wouldn't compress much anyway. it would be interesting to see how roles (middle, exit, directory cache) affect the crypto overhead. i suspect you're right, that a middle only would opt toward the traffic it is most effective at (lots of AES, fewer pubkey ops, fewer compressed payloads). i have no if this would make a significant impact, or get you past other CPU limits for network saturation. would be a fun experiment for someone with the bandwidth/lab setting and some C7 cores... :) best regards,
Re: Avoiding HTTPS pitfalls [was: Re: Moxie Marlinspike]
On Mon, Feb 23, 2009 at 12:29 PM, Arjan n6bc23cpc...@list.nospam.xutrox.com wrote: Noscript has some options (Options, Advanced, HTTPS) that may help. Disclaimer: I've not used these options and I don't know if it's secure. from https://www.torproject.org/torbutton/faq.html Which Firefox extensions should I avoid using? ... NoScript: using NoScript can actually disable protections that Torbutton itself provides via Javascript, yet still allow malicious exit nodes to compromise your anonymity via the default whitelist... as an aside, i found a plugin that could do everything above, but only if the sites themselves send you a ForceHTTPS cookie securely: https://crypto.stanford.edu/forcehttps/ the design paper does a good job of explaining why this is all more complicated than you might think... best regards,
Re: Geoip information
On Wed, Feb 18, 2009 at 6:36 AM, downie - downgeo...@hotmail.com wrote: ... There was a geoip-cache file from November, which I guess is the last time it worked. I renamed that in case it was corrupted. A new one hasn't been created, I don't think. the behavior you describe is exactly as if whatever Vidalia's thinks is the data directory does not exist. this could be file system corruption, an accidental deletion, permissions. the best suggestion is to reinstall, so that the installer creates and populates the Vidalia data directories correctly. debug level logging should point out the cause, but you may have to dig for it among all the other verbosity. best regards,
Re: Geoip information
On Tue, Feb 17, 2009 at 6:15 PM, downie - downgeo...@hotmail.com wrote: ... Hmm, If I set logging to Info, try debug, i should have mentioned this before. it will be exceptionally noisy though :/ ... start Tor from Vidalia, and watch the Connection box in the Network Map, I see a connection opened to geoip.vidalia-project.net:1443 , then closed, good! did you see it actually CONNECT ok before closing? or was the close a gave up or no exit available close? (may have to watch closely) but no Geographic data comes up on the map or the list of relays - no flags, no routemap of my connection. depending on how out of date your cached information is, there may be hundreds and hundreds of IP's to get info for. while the request to the geoip service does try to ask about many IPs at a time, it will still break a huge amount into reasonable chunks, and thus multiple GOOD responses are needed to successfully connected requests for some router details to get geo coordinates. There is also no mention of GeoIP in the log. Are we talking about different things here? How does all the geographic information get uploaded into Vidalia? we should be talking about the same thing.
Re: Geoip information
On Mon, Feb 16, 2009 at 10:02 AM, downie - downgeo...@hotmail.com wrote: Hi, Vidalia has not been showing any geographic data for me for a couple of months now the service works, you can verify yourself by making a request to https://geoip.vidalia-project.net:1443/cgi-bin/geoip one thing i have seen is that because this is using port 1443 it can be hit or miss to find a decent exit for requesting all of the desired information. your vidalia log should indicate what is going on in more detail. best regards,
Re: problem while trying to fetch 0.2.1.8-alpha
On Wed, Jan 21, 2009 at 1:43 AM, Scott Bennett benn...@cs.niu.edu wrote: ... Okay. I downloaded entrust_ssl_ca.der (the man page for wget(1) says it wants DER or PEM format for certificates) and i tend to use PEM; DER won't work with many wget installations. wget --ca-certificate=entrust_ssl_ca.cer https://www.torproject.org/dist/... should work fine. best regards,
Re: tor-browser bundle on XP
On Wed, Jan 14, 2009 at 10:20 PM, mikel.ander...@juno.com mikel.ander...@juno.com wrote: ... it doesn't work on my limited-user accounts. Specifically, the Vidalia control panel status reads, connecting to a relay directory failed(no route to host). Is this due to the lack of administrator rights? the no route to host can be caused by many things, and may not be impacting the ability for Tor to function. can you try running vidalia with notice or info loglevel to see if a failure is reported? vidalia.exe -loglevel notice -logfile log.txt (don't send a full log to the list of course :) i would also be curious if the MSI based installer bundle works better when installed as unprivileged user: https://data.peertech.org/files/demo/updater/index.html best regards,
Testing the Tor Vidalia bundle with Thandy updater support
Two packages for Windows are now available for testing the new Thandy updater code for maintaining current versions of Tor in the Vidalia bundle. These are test only releases and should not be used for anything important; feedback on the package installation and ease of use is solicited. The first package is the usual bundle installer with all necessary programs included. The second is a network based installer that uses Thandy to download the most up to date versions of the bundle packages at install time. Note that if you want to test the update process for Tor 0.2.1.9 to 0.2.1.10 you will need to install the bundle package; the network installer will always install the latest version. Instructions for testing the packages: https://data.peertech.org/files/demo/updater/index.html My thanks in advance for help testing these packages; I can be reached at this address for any question or comments. Best regards, also, some additional detail about the MSI based packages and update process is here: https://data.peertech.org/files/demo/updater/about.html
Re: cannot compile 0.2.1.10-alpha
On Tue, Jan 13, 2009 at 7:59 PM, zmj zan...@gmail.com wrote: windows xp+sp3+mingw ... how did you invoke configure? what version of mingw?
Re: Jailed/sandboxed/chrooted applications
On Thu, Jan 1, 2009 at 6:56 PM, Adlesshaven adlessha...@embarqmail.com wrote: Does anyone here jail, sandbox or chroot the applications they use with Tor? ... What is the best way to isolate applications completely for use with Tor? situations vary but my personal preference is for distinct virtual machines to run groups of applications and Tor separately. the main benefit this provides is stronger isolation from arbitrary execution and other exploits as well as providing a virtual network address that does not provide any hints about the topology or configuration of your internal LAN / Internet connection. being able to configure Tor'ified applications in freebsd jails would be useful though; i've only tried to do that (owner match) with iptables on linux though... best regards,
Re: problem while trying to fetch 0.2.1.8-alpha
On Wed, Dec 31, 2008 at 12:21 AM, Scott Bennett benn...@cs.niu.edu wrote: ... Nope. Instead I get: ah the joys of PKI. Tor has been changing certs. new roots are http://www.entrust.net/developer/index.cfm and Entrust Secure Server CA is the one you want. i believe the check.torproject.org and blog.torproject.org will be changing soon as well. best regards,
Re: User tor issue
On Tue, Dec 30, 2008 at 6:53 AM, Udo van den Heuvel udo...@xs4all.nl wrote: ... I am using that patch (and others) to be sure that openssl uses the via padlock hardware: yes, you're fine. just a note: the no-rng is a good sign - you are expected to use an entropy daemon that does fips sanity checks on /dev/hw_random output before seeding the kernel entropy pool with garbage. (usually called rngd) best regards,
Re: User tor issue
On Tue, Dec 30, 2008 at 6:53 AM, Udo van den Heuvel udo...@xs4all.nl wrote: ... I am using that patch (and others) to be sure that openssl uses the via padlock hardware: # openssl engine (padlock) VIA PadLock (no-RNG, ACE) another suggestion: you could try openssl 0.9.9 (devel) with the montgomery multiplier acceleration to speed up some of the rsa/dsa ops: openssl engine padlock (padlock) VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM PHE is the sha1 padlock hash engine PMM is the MONTMULT accel best regards, .. any further discussion down this tangent should probably be taken off list for brevity. let me know directly if you're still having trouble with the hardware throughput.
Re: User tor issue
On Mon, Dec 29, 2008 at 10:43 AM, Udo van den Heuvel udo...@xs4all.nl wrote: ... Dec 29 19:09:21.991 [info] crypto_global_init(): Initializing OpenSSL via tor_tls_init(). Hardware isn't used at all!? you'll need to set HardwareAccel 1 like you mentioned. then you should see Initializing OpenSSL engine support. followed by the engine used for various cipher primitives. (RSA,DH,AES,etc...) best regards,
Re: User tor issue
On Mon, Dec 29, 2008 at 11:04 AM, Udo van den Heuvel udo...@xs4all.nl wrote: In main.c crypto_global_init is called with the contents of the HardwareAccel setting; in crypto.c useAccel is tested and the tor_tls_init line is printed although it is set to 1... you are correct; my apologies. by the time tor_tls_init invokes crypto_global_init it should have been initialized correctly based on the config option as you describe. are you not seeing the hardware accel log entries at all? or is this a question about the (potentially misleading) call from tor_tls_init? btw, if you want to force OpenSSL hardware acceleration without requiring application intervention see: http://www.logix.cz/michal/devel/padlock/contrib/openssl-0.9.8e-engine.diff best regards,
Re: Perfect MITM attack with valid SSL Certs
On Tue, Dec 23, 2008 at 8:47 AM, Roc Admin onionrou...@gmail.com wrote: ... receive a completely valid certificate for a random domain of his choosing without any questions or verification. ... the browser pre-trusted certificate authorities really needs to be cleaned up. this is why i am fond of the petname toolbar to identify server certificates using local trust information rather than assuming any cert signed by any of the dozens of random CA's bundled with Firefox is legit: https://addons.mozilla.org/en-US/firefox/addon/957 for other applications that use system or application CA certificate stores you've got fewer options. if you're really concerned you can extract the few roots you trust into a new certificate store and tell the app in question to validate against those CA's only. supposedly extended validation certs will restore trust in the PKI hierarchy, but i'm not holding my breath... *grin* best regards,
Re: problem while trying to fetch 0.2.1.8-alpha
On Sun, Dec 21, 2008 at 10:31 PM, Scott Bennett benn...@cs.niu.edu wrote: ... is it possible you have an old openssl cacerts package without the newer ev signing and root ca's? Beats me. yup, that appears to be it. (looking at the certs you got). nothing nefarious, aside from another random root added to your circle of trust :) you can download via: https://www.geotrust.com/resources/root-certificates/ you want: https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Global_eBusiness_CA-1.cer verify things look good: openssl s_client -CAfile Equifax_Secure_Global_eBusiness_CA-1.cer -connect www.torproject.org:443 -showcerts ... Verify return code: 0 (ok) and to use this with wget: wget --ca-certificate=Equifax_Secure_Global_eBusiness_CA-1.cer https://www.torproject.org/... best regards,
Re: Windows buffer problems
On Fri, Dec 19, 2008 at 7:54 AM, Lee ler...@gmail.com wrote: ... Manipulating HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\GlobalMaxTcpWindowSize and TcpWindowSize to 0xfaf00 (1027840) seemed to increase the time to failure when running Tor and BitTorrent. seems backwards. Instead of buffering up to 16KB of data for each open connection you're telling the system to buffer up to 1MB of data for each open connection. How can increasing system buffer usage help if the problem is insufficient buffer space? this is a little odd. there is a different option useful for virtual servers (and seems to help with the WSAENOBUFS too) called ConstrainedSockets. this will use setsockopt() to limit the size of send and receive buffers associated with each socket. the ConstrainedSockSize parameter can lower or increase from the default constrained size. i wonder if the person reporting that behavior allowed TCP windows to scale above 1M so constraining them to 1M limit helped (but still seems high). So I'm wondering if the problem could be that the system runs out of available ports. i don't think this is quite as common, and is reported as an error distinct from the too many concurrent pending and buffer exhaustion errors. XP defaults to using something like 4K ports and 240 seconds for keeping a closed socket in the timed wait state. Has anyone tried bumping the allowable port numbers up to 64K and dropped the timed wait state time to 16 seconds? dropping the time wait state is a good idea. i have to do this for other connect heavy applications in a different setting to keep within global kernel limits for max open files. by default this is usually around 4 minutes. that's a long time to tie up scarce kernel buffer resources and/or file descriptors. i don't know how useful this would be for Tor servers; a good experiment for someone to try perhaps! :) best regards,
Re: System Proxyfier for Windows: WideCap
On Thu, Dec 18, 2008 at 7:30 PM, grego...@fastmail.fm wrote: ... WideCap is supposed to proxify the whole OS I think and it handles DNS too. by default nothing is proxied and the user interface requires individual applications to be selected for proxy. as Kyle mentioned this is insufficient protection for Tor users since various Windows services may access network resources outside application proxy settings. if WideCap were to default all applications proxied that would be more useful. ... WideCap acts as virtual network driver covering all your TCP/IP activity. No launchers - just run your program as usual and work via proxy. this is the model of operation for the early work done on Tor in a VM for Windows: https://data.peertech.org/files/demo/testinfo.html please heed the warnings about the alpha state of this software :) ... Q: After the proxy checking I've got that all proxies are broken. And the system event log reports about EventID 4226: TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts. What's wrong? I have Windows XP SP2. A: It's problem related to WinXP SP2 users (and possible Win2003). In this systems the TCP/IP driver has a limitation for concurrent connection attempts. Limited to 10 concurrent connection attempts. Unfortunately there's no registry key to fix this but patch exists. Read more about Event ID 4226 + patch --That last question is the same issue I think of non-server Windows issues when acting as a Tor node. In my next email to the list found a great little app that will change the connect limits in the tcpip.sys file to whatever you want. I set mine to 100. there are actually two issues (or more?) for non-server Windows running Tor. the usual problem Tor encounters is not related to the number of concurrent attempts but to kernel non-paged memory resources consumed to exhaustion when lots of active non-overlapped-I/O sockets are in use. details here: https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems the concurrent connection attempt limit is easier to fix, although messing with system files is generally not advised! best regards,
Re: tor-0.2.0.32 doesn't compile on Solaris?
On Sun, Nov 23, 2008 at 12:53 AM, otto otto [EMAIL PROTECTED] wrote: ... -D__DARWIN_UNIX03 -DIPHONE did you specify an architecture when invoking the configure script? the config.log would be helpful but should probably go in a flyspray report if needed. best regards,
Re: swap and live CD
On Sat, Nov 22, 2008 at 5:48 AM, Matej Kovacic [EMAIL PROTECTED] wrote: ... But the problem is, that Ubuntu uses swap partition of the host machine. this isn't much of a problem if you use encrypted swap with an ephemeral / one time key. power off the host (and wait for DRAM to drain :) and you should be in good shape. if data remanence attacks are in your threat model you've probably got bigger concerns about porting your OS around random hardware though. regarding using the USB for full OS/swap: the duty cycle of flash memory is significantly less than disk platters. if you can make use of disk swap safely it would probably be useful to do so. booting from read only ISO media also provides some integrity benefit. (8.10 supports LVM+LUKS which can provide the encrypted swap without the key management headaches eCryptfs avoids. and both take advantage of hardware crypto acceleration in kernel so those with VIA padlock cores and other crypto offload won't even notice the overhead!) my $0.02 best regards,
Re: Ping: Kyle Williams: TorVM
... xeromail is xerobank, right? is this topletz incognito? On Tue, Nov 11, 2008 at 5:09 PM, Jack [EMAIL PROTECTED] wrote: Kyle, recently saw your latest contribution: TorVM. Could you discuss the essential differences between TorVM and JanusVM? Looking forward to giving this a try!! Thanks, Jack Straw
Re: Kudos on memory usage in 0.2.X
On Sun, Nov 9, 2008 at 3:15 PM, slush [EMAIL PROTECTED] wrote: ... Im running Tor exit on VPS, version 0.2.0.x. So each MB of memory is quite bit expensive for me along with the 0.2.1.x memory improvements you may want to experiment with the ConstrainedSockets option. there has been reported success using this feature on virtual private servers where kernel and/or system memory is limited more than usual. you can read more about this option in the man page for Tor. best regards,
Re: Ping: Kyle Williams: TorVM
On Wed, Nov 12, 2008 at 12:11 AM, Jack [EMAIL PROTECTED] wrote: Negatori, my friend. sorry. my apologies to yourself and Steve. (if he's reading :) given that Tor in a VM is a work in progress not ready for common use it is difficult to discuss differences. i'd say the essential difference is that the Tor VM work is all open source without a dependency on VMWare or other closed source virtualization products. aside from that, you'll probably have to wait a while longer until a functional release is available for a good comparison. best regards,
Re: Tor 0.2.1.6-alpha is out
On Sat, Oct 18, 2008 at 6:15 AM, otto otto [EMAIL PROTECTED] wrote:
I get the following error when trying to build tor-0.2.1.6-alpha on Sun
Solaris 10x86.
...
compat.c: In function `tor_lockfile_lock':
compat.c:509: warning: implicit declaration of function `flock'
it looks like the way to fix this is add a configure check for flock
and fall back on fcntl when not present. for example:
src/common/compat.c: line 508
#ifdef HAVE_FCNTL_H
struct flock fl;
fl.l_type = F_WRLCK;
fl.l_whence = SEEK_SET;
fl.l_start = 0;
fl.l_len= 0;
fl.l_pid= getpid();
if (fcntl(fd, F_SETLK, fl) 0) {
#else
if (flock(fd, LOCK_EX|(blocking ? 0 : LOCK_NB)) 0) {
#endif
unlock is similar, except you set fl.l_type = F_UNLCK;
this is a bit of a patch, and unfortunately not many Tor developers /
supporters use Solaris. it would be nice to have a fix for this,
perhaps if you would be willing to test some patches i could take a
stab at initial support for the fcntl changes.
best regards,
Re: Proposed student project
On Mon, Sep 15, 2008 at 12:17 PM, Kyle Williams [EMAIL PROTECTED] wrote: ... I believe coderman has been using the TorVM as a server, so he would have a better answer as to how much RAM it uses running as a server node. i have been able to run a middle node with 32M guest VM (8M free below 32M limit in OS) for days. dir cache and exit will increase this, as does the amount of traffic. i know some people have used quite a bit less for client only on routers with 8-16M, and others who need a lot more memory for their high traffic nodes. sorry i don't have more quantified results; your mileage will vary :) best regards,
Re: peculiar server bandwidth posted by server mnl and possible new type of attack
On Wed, Sep 10, 2008 at 1:53 PM, Olaf Selke [EMAIL PROTECTED] wrote: ... 10% less than the bw data collected by mrtg i'd be curious to compare number of packets with the observed bandwidth; how much of that 10% is TCP/IP protocol headers that aren't visible to Tor's bandwidth accounting (which looks at bytes read/write at socket level). best regards,
Re: No torrc in xBBrowser
On Thu, Aug 14, 2008 at 12:51 PM, Kyle Williams [EMAIL PROTECTED] wrote: ... I don't see any documentation on how to build your own Browser Bundle... instructions for building the browser bundle are at: https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL
Re: Exit node connection statistics
On Mon, Jul 14, 2008 at 8:43 AM, [EMAIL PROTECTED] wrote: ... do you blindly trust all other Tor operators until they show some bad behaviour? [that's] nothing but security by obscurity. this is why use of SSL/TLS over Tor is so strongly encouraged. Can you explain what the threat scenario is for what I'm doing? ... I'm not argument-resistant. So tell me your views. the strongest argument is not for the privacy of those who exit your node, but your own personal liability for knowing what exits your node. see the Tor Legal FAQ: https://www.torproject.org/eff/tor-legal-faq.html.en Should I snoop on the plaintext that exits through my Tor relay? No. You may be technically capable of modifying the Tor source code or installing additional software to monitor or log plaintext that exits your node. However, Tor relay operators in the U.S. can create legal and possibly even criminal liability for themselves under state or federal wiretap laws if they affirmatively monitor, log, or disclose Tor users' communications, while non-U.S. operators may be subject to similar laws. Do not examine the contents of anyone's communications without first talking to a lawyer. best regards,
Re: How are hackers breaking Tor and trojan users?
On Wed, Jun 11, 2008 at 5:35 PM, scar [EMAIL PROTECTED] wrote: ... If someone were to develop a browser-based exploit that managed to get the 'authenticate', with no preceding bytes, to the controlport... like this? http://www.janusvm.com/goldy/vuln/tor-controlport.html that is a standard HTTP post and thus sends HTTP request headers before the textarea form payload. what Robert indicated is that he thinks it is highly unlikely that you could use a browser to connect and send AUTHENTICATE before anything else, like the request headers. the challenge / response handshake he suggested is an interesting option for authenticating to the control port; it would indeed eliminate any blind injection attacks, while still making it trivial to use the control port legitimately. best regards,
Re: How are hackers breaking Tor and trojan users?
On Tue, Jun 10, 2008 at 9:10 PM, Arrakis [EMAIL PROTECTED] wrote: ... you can stop the effects of 0-days altogether. ... janusvm or xb machine ... implementation removes the attack landscape for 0-day attacks. this is a pretty strong statement and unsupported for any more complex attack against a host. to claim immunity from 0day is to ignore the (less likely) use of multiple exploits against a virtual machine environment for escalation of compromise of the guest up to full control of the host. [0] [1] [2] [3] [4] [5] [6] [7] [8] that is not to downplay the benefits of a vm model with isolated network stack; this provides a clear improvement in terms of defense in depth and reducing attack surface available to attackers (to use against you). unfortunately, without fundamental and sweeping changes in the way software is designed, implemented and used the 0day is here to stay, no matter who you are... best regards, NOTE: i'm picking on vmware to prove a point (and because they're such an easy target!) but the lesson applies to all virtual machines or hyper visor implementations crafted by human brains... 0. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2100 1. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2099 2. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0967 3. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0948 4. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0888 5. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0553 6. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0062 7. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5671 8. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4459 [ ... no need to continue beating this dead horse ... ]
Re: OpenSolaris?
On Wed, Jun 4, 2008 at 9:33 AM, Wesley Kenzie [EMAIL PROTECTED] wrote: ... I'm investigating using Amazon EC2 and OpenSolaris on my server to address scalability. i'm confused. you want to run a node on Solaris on EC2 to achieve higher throughput? this is not likely to work as well as you expect, as the current implementation of Tor has a hard time utilizing multiple processors for the bottleneck crypto operations. a grid computer with multiple virtual cores is likely to have the same issues with load distribution. you will most likely be limited by the crypto power of a single virtual core, regardless of how many are configured. i'd be interested to hear how this experiment goes, if you do try it. for better performance, you might consider using hardware crypto offload to improve throughput. this is known to work to well, and some crypto acceleration is effective enough that the compression/decompression is now the bottleneck for a Tor router. there are a number of such add in cards and even some CPU's with crypto acceleration built in (VIA padlock). best regards,
Re: relay tidbits...
On Mon, Jun 2, 2008 at 12:12 AM, luser [EMAIL PROTECTED] wrote: ... If I believe that the majority of ... traffic over tor is ... unauthorised how do you determine? that is the crux, and since you cannot do so, you open yourself to legal liability and target a subset of the legitimate users as well. this is not to say that better education of users about authenticity and privacy over Tor is not needed, but that exit sniffing is a risky and less effective way to do so. best regards,
Re: relay tidbits...
On Mon, Jun 2, 2008 at 4:33 PM, luser [EMAIL PROTECTED] wrote: ... could protocols supporting en clair passwords be denied, a la smtp? see proposal 129: rejecting plaintext ports: https://www.torproject.org/svn/trunk/doc/spec/proposals/129-reject-plaintext-ports.txt this would be quite useful, and help Tor fail safe when a user is not sophisticated enough to understand how their use of Tor might compromise the privacy of accounts they access. is is possible to run a relay on tcp/25? how about tcp/21? sure, why not? best regards,
