Re: Bridging from Bootcamp???
On Tue, Feb 8, 2011 at 2:09 AM, bao song 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 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 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 5:44 AM, 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 relay on vserver exeeding numtcpsock
On Wed, Jan 12, 2011 at 7:57 AM, Klaus Layer 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 3:11 AM, intrigeri 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/
BHDC11 - De-anonymizing Live CDs through Physical Memory Analysis
does anyone know more about the methods to be discussed by Andrew Case next week? the memory analysis of Tor seems interesting. (do Tor Live CDs need a new kexec target for memtest sweeps / ram zeroisation? :) http://www.blackhat.com/html/bh-dc-11/bh-dc-11-briefings.html#Case """ Traditional digital forensics encompasses the examination of data from an offline or “dead” source such as a disk image. Since the filesystem is intact on these images, a number of forensics techniques are available for analysis such as file and metadata examination, timelining, deleted file recovery, indexing, and searching. Live CDs present a large problem for this forensics model though as they run solely in RAM and do not interact with the local disk. This removes the ability to perform an orderly examination since the filesystem is no longer readily available and putting random pages of data into context can be very difficult for in-depth investigations. In order to solve this problem, we present a number of techniques that allow for complete recovery of a live CD’s in-memory filesystem and partial recovery of its previously deleted contents. We also present memory analysis of the popular Tor application as it is used by a number of live CDs in an attempt to keep network communications encrypted and anonymous. """ *** 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 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: Tor VM stalled at 25%
On Thu, Dec 23, 2010 at 2:45 PM, Praedor Atrebates wrote: > ... do we all have to roll out own? not all, but at least one. why not use the standard Bundle in an Ubuntu or other VM? the transparent VM model is experimental and complicated; if you're not comfortable building and deploying it yourself the supported bundle distributions and modes of use are much more recommended. there are also third party distributions like Janus VM if you're evaluating all your options... 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 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: Bitcoin And The Electronic Frontier Foundation
On Sat, Nov 20, 2010 at 7:45 PM, slush 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: Bitcoin And The Electronic Frontier Foundation
On Sat, Nov 20, 2010 at 8:57 PM, John Case 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 Fri, Nov 19, 2010 at 6:10 PM, John Case wrote: > ... > How does the on-chip encryption feature set of the i7 compare to the very > latest sparc processors and their on-chip encryption features ? the latest i5 / i7 with AES-NI can accelerate ... AES. the SPARC T2/T3 can accelerate: - AES (ECB, CBC, CTR, CCM, CGM, CFB modes) - RSA, DSA, DH - Elliptic Curve (ECDH, ECDSA, including key generation) - MD5, SHA1, SHA256, SHA384, SHA512 - Hardware entropy source not much of a comparison, really. *** 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 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: Scalability and fairness [was: P2P over Tor [was: Anomos - anonBT]]
On Wed, Nov 17, 2010 at 3:02 PM, grarpamp 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: Bitcoin And The Electronic Frontier Foundation
On Tue, Nov 16, 2010 at 7:00 AM, TheGravitator 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 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: DNS with Tor (compared to VPNs).
On Wed, Oct 20, 2010 at 4:47 PM, 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: TCP stack attack?
On Sun, Oct 24, 2010 at 8:28 PM, coderman 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: TCP stack attack?
On Sat, Oct 23, 2010 at 5:59 PM, Robert Ransom wrote: > On Sat, 23 Oct 2010 12:42:11 -0700 > Julie C 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: The best way to run a hidden service: one or two computers?
On Mon, Sep 27, 2010 at 2:46 AM, grarpamp wrote: >... > Unknown here if original MAC can be read, usually, yes. extended device statistics / mib, diagnostic cmds, hardware manufacturer, or third party driver/stack components, or any other numerous ways have been demonstrated to obtain serial nos, device mac (regardless of sw/host change), and other sensitive information. this is why arbitrary plug-ins are so dangerous and a restricted browser necessary. > or reset the nic for reading, > via the same original boot-time routines at any given later runtime. service affecting, but works every time... *** 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 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 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 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 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 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: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri 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: How to Run High Capacity Tor Relays
On Tue, Aug 24, 2010 at 8:27 AM, Mike Perry 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: https proxy [was polipo]
On Mon, Aug 23, 2010 at 8:58 AM, morphium wrote: >> I can see it could provide some >> protection against ssl/ssh mitm attacks. > > No. Why do you think it could? - because by default applications trust either a large, promiscuous set of certificate authorities, or even worse, use the operating system supplied list of trusted authorities. - because by default applications do not or cannot utilize mitigating measures like perspective based certificate retrieval and consensus from varying endpoints or sources. - because by default applications may not support robust cipher suites or handle some aspects of protocol or session negotiation poorly / incorrectly / insecurely. - because by default applications don't support a persistent, mobile store of trusted server certificates built up over time, which a proxy could provide (Tahoe LAFS / encrypted $cloud storage for your certificate store available wherever you need it.) - lots of additional reasons... *** 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 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 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 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: Flash Cookies and Tor.
On Thu, Jul 29, 2010 at 5:34 PM, coderman 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: Flash Cookies and Tor.
On Thu, Jul 29, 2010 at 2:17 PM, Matthew 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: US Seeks Access to More Internet Data Without Court Order
On Thu, Jul 29, 2010 at 2:16 PM, punkle jones 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: 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} < $po
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 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
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 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 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)
On Sun, Jul 4, 2010 at 3:17 PM, coderman 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 Sun, Jul 4, 2010 at 3:17 PM, coderman 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: 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 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: 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 found. se
Re: why not TORVM for linux?
On Sat, Jul 3, 2010 at 10:54 PM, emigrant wrote: > why not? it is not maintained. this applies to all Tor VM unless you've patched and built a current version for yourself / others. the controller is built for a windows environment. you'll have to customize the invocation and configuration for Linux based systems. there is no support for hardware assisted / para-virtualization by default, due to instability and elevated permissions. for best performance you'll have to configure the KQEMU or KVM acceleration support yourself with the appropriate KVM and/or virtio device interfaces. more reasons too numerous to list here. moving Tor VM from a (dated) research beta to production ready is a non-trivial effort for which there does not seem to be much interest. 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 Browser Bundle for GNU/Linux 1.0.0 Released
On Sat, Mar 27, 2010 at 3:44 AM, Mike Perry 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 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 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 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 Thu, Jan 14, 2010 at 4:52 PM, Ted Smith 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: Google in China
On Tue, Jan 12, 2010 at 4:23 PM, downie - 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: Anyone running Tor on routing/switching hardware ?
On Mon, Oct 26, 2009 at 8:52 AM, John Case 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: hardware acceleration available for Tor ? On FreeBSD ?
On Mon, Oct 12, 2009 at 8:24 PM, John Case wrote: > ... > You discuss the performance benefits of using the AES CTR in hardware below, > but before I get to that, I wonder if you experienced the same as what is > quoted just above: that the real CPU load occurs during "the asymmetric-key > processing (i.e., onion-skin encrypting/decrypting)" and that that is the > only area where we can attempt to speed things up with hardware ? speeding up OpenSSL derived CTR mode with hardware acceleration is useful. (the HardwareAccel and EngineName options above) speeding up Tor with native hardware acceleration and chained / repetitive CTR offload is a much bigger win. as an example the VIA Padlock engine can do a few score MBytes/sec aes 128 with small/single block sizes like those used when HardwareAccel is on and EngineName padlock set. if you could utilize the maximum 16KByte rep instruction mode directly goes well over a gigabyte / second. this is also why the native Solaris API CTR mode gives much better performance than the OpenSSL engine acceleration. speeding up OpenSSL pubkey ops also helps. as of OpenSSL 0.9.9 and 1.0.x you can build OpenSSL with padlock MONTMULT acceleration. still no dynamic engine support for pubkey ops iirc... > So, if I understand correctly, the HardwareAccel option can be turned on by > anyone, regardless of OS or hardware platform. It will then (probably) just > do AES CTR with OpenSSL (since most people use OpenSSL) and just get no > benefit because OpenSSL won't do AES CTR through hardware. there will be some benefit as Tor wraps a CTR mode around (accelerated) OpenSSL ECB mode. the problem is that this method is limited to single blocks per call, rather than long buffers optimized for crypto offload. you may also get SHA acceleration. the notices log should say, for example: [info] crypto_global_init(): Initializing OpenSSL engine support. [info] crypto_global_init(): Initializing dynamic OpenSSL engine "padlock" acceleration support. [info] crypto_global_init(): Loaded dynamic OpenSSL engine "padlock". [info] crypto_global_init(): Loaded OpenSSL hardware acceleration engine, setting default ciphers. [info] Using default implementation for RSA [info] Using default implementation for DH [info] Using default implementation for RAND [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for SHA1 [info] Using default implementation for 3DES [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for AES > So, even if I got a BCM5825 working with with the ubsec driver on FreeBSD, > and used HardwareAccel, it would just be wasted with OpenSSL. not necessarily, per above :) > On the other hand, there are Solaris-specific routines (crypto framework > APIs (PKCS#11)) built into Solaris that Tor can call instead of OpenSSL, > which _will_ do AES CTR in hardware, yielding a huge gain in performance > (you mention 25x). > > Do I have all of that correct ? it would also be nice to have these routines native for other engines, like padlock. however this is not a small amount of effort and no one with time and skill has shown an interest yet. (Tor buffer allocation alignment to 16K, inline padlock instr. calls in REP mode, and other changes required.) > - Are there analogues to the "crypto framework APIs (PKCS#11)" in other OS's > ? What is this layer called for Linux, for instance ? there are kernel cryptographic facilities including asm optimized and hardware accelerated crypto primitives. these are usually not utilized from userspace directly. there are PKCS specs for communicating with offload devices in a concise manner, and libs of various types to speak this to myraid hardware. perhaps a longer discussion should be taken off list... > - How does the T2 (Niagara 2) compare to dedicated hardware such as the Sun > Crypto 6000 which is currently available ? the T2 is core acceleration and thus higher throughput for most purposes. the 6000 is useful as a hardened private key store service for your less trusted OS and software to cooperate with. > - Am I correct that if a new version of OpenSSL appeared with AES CTR > hardware support, an end user could just proceed blindly with card > insertion, driver install, add HardwareAccel=1, and poof! Yes ? Tor would need to be updated to take advantage of the new CTR mode in the OpenSSL API calls, but then the same HardwareAccel (and AccelName) options would provide a significant improvement over the previous acceleration mode. 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, grarpamp 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,
OpenSSL dynamic hardware engines in 0.2.2.1-alpha
The new 0.2.2.1-alpha release includes support for dynamic crypto offload engines in OpenSSL. Two new config options are added to the existing HardwareAccel boolean: HardwareAccel 0|1 : If non-zero, try to use built-in (static) crypto hardware acceleration when available. (Default: 0) AccelName NAME : When using OpenSSL hardware crypto acceleration attempt to load the dynamic engine of this name. This must be used for any dynamic hardware engine. Names can be verified with the openssl engine command. AccelDir DIR : Specify this option if using dynamic hardware acceleration and the engine implementation library resides somewhere other than the OpenSSL default. In most cases OpenSSL will know where to find its dynamic engine shared library files and only "AccelName" needs to be set. For example, to enable the padlock engine add: HardwareAccel 1 AccelName padlock to your torrc. If the engine is successfully loaded you should see confirmation in the notices.log similar to: Aug 30 15:04:17.844 [notice] Tor 0.2.2.1-alpha (git-1092fdca53ec0110) opening new log file. Aug 30 15:04:17.864 [notice] Parsing GEOIP file. Aug 30 15:04:18.374 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for SHA1 Aug 30 15:04:18.374 [notice] Using OpenSSL engine VIA PadLock: RNG (not used) ACE2 PHE(8192) PMM [padlock] for AES ... Best regards,
Re: More Secure Tor Browsing Through A Virtual Machine in Ubuntu
On Thu, Aug 20, 2009 at 9:05 AM, Curious Kid 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=details&id=1067 best regards,
Re: Tor/Iptables Question
On Thu, Aug 20, 2009 at 4:55 AM, Ringo<2600den...@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: windows tor
On Wed, Aug 12, 2009 at 10:23 PM, Peter 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-503 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-503 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. Blue 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 Foll 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: New option DirPortFrontPage
On Sat, Jul 25, 2009 at 7:55 PM, downie - 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 Sat, Jul 25, 2009 at 3:26 AM, Ringo<2600den...@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: Hidden Service Weirdness
On Mon, Jul 13, 2009 at 12:06 AM, Ringo<2600den...@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: 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 10:38 PM, Ringo<2600den...@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: Question: Hidden Services, Virtual Machines, and iptables
On Tue, Jul 7, 2009 at 6:10 PM, Ringo<2600den...@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 Heuvel 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 Bennett 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 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 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 - 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 - 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: Avoiding HTTPS pitfalls [was: Re: Moxie Marlinspike]
On Mon, Feb 23, 2009 at 12:29 PM, Arjan 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: aes performance
On Mon, Feb 23, 2009 at 12:29 PM, Arjan 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:04 PM, Fran Litterio wrote: > ... > This is ok, but I'd also like to be alerted when the certificate changes for > a site that I regularly visit. yes. Tyler's suggestion is a good one. if you want the certs themselves authenticated you get to manage them yourself too. remove all CA's by nuking libnssckbi.so and only add back those you've authenticated and trust. sadly, this is beyond the skills of most people. the PKI cartel lives another day... :P best regards,
Tor on virtual servers [was: Re: Suspended..]
On Mon, Feb 23, 2009 at 8:27 AM, Andy Dixon 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,
Avoiding HTTPS pitfalls [was: Re: Moxie Marlinspike]
On Thu, Feb 19, 2009 at 4:17 AM, Erilenz 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,
Re: aes performance
On Mon, Feb 23, 2009 at 8:23 AM, Arjan 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,
Re: Geoip information
On Wed, Feb 18, 2009 at 6:36 AM, downie - 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 - 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 - 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: Tor speed
On Thu, Feb 12, 2009 at 4:58 PM, slush wrote: > Hello, > > for my thesis, I tested speed of Tor and JAP (free service). Although JAP > was a little bit slower than circuits of Tor in benchmark tests, I was > surprised that JAP had much better user experience and acted as faster. latency is also an important component to measure. especially when content, like html pages, contains many nested elements or links which require additional connections to other sites. the latencies are additive and some elements of an HTML document are not rendered until a sufficient number of bytes / linked entities are loaded. best regards,
Re: problem while trying to fetch 0.2.1.8-alpha
On Wed, Jan 21, 2009 at 1:43 AM, Scott Bennett 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 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,
Re: cannot compile 0.2.1.10-alpha
On Tue, Jan 13, 2009 at 7:59 PM, zmj wrote: > windows xp+sp3+mingw >... how did you invoke configure? what version of mingw?
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: Jailed/sandboxed/chrooted applications
On Thu, Jan 1, 2009 at 6:56 PM, Adlesshaven 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 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 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 Tue, Dec 30, 2008 at 6:53 AM, Udo van den Heuvel 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 Mon, Dec 29, 2008 at 11:04 AM, Udo van den Heuvel 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: User tor issue
On Mon, Dec 29, 2008 at 10:43 AM, Udo van den Heuvel 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: Perfect MITM attack with valid SSL Certs
On Tue, Dec 23, 2008 at 8:47 AM, Roc Admin 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 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 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, 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: problem while trying to fetch 0.2.1.8-alpha
On Thu, Dec 11, 2008 at 11:35 AM, Scott Bennett wrote: > I appear to be getting an SSL connection error when using wget(1) to > fetch 0.2.1.8-alpha using the links from the tor project's download page... is it possible you have an old openssl cacerts package without the newer ev signing and root ca's? (you can tell wget to use an explicit trusted ca cert file if necessary) does: openssl s_client -connect www.torproject.org:443 -showcerts indicate anything unusual during session negotiation? 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: 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,
