Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Paul Syverson (syver...@itd.nrl.navy.mil): For those who want more background, you can read more at item #1 on https://www.torproject.org/research.html.en#Ideas (I hoped to transition https://www.torproject.org/volunteer.html.en#Research over to that new page, but haven't gotten around to finishing) Yes. Exploring defensive techniques would be good. Unlike correlation, fingerprinting seems more likely to be amenable to traffic shaping; although the study of this for countering correlation (as some of us recently published at PETS ;) may be an OK place to build on. Personally I still think trust is going to play a bigger role as an effective counter than general shaping, but one place we seem to be in sync is that it all needs more study. Yeah, though again I want to point out that what we are actually looking at when we intuitively believe fingerprinting to be easier to solve than correlation is the event rate from the base rate fallacy. Otherwise, they really are the same problem. Correlation is merely the act of taking a live fingerprint and extracting a number of bits from it, and adding these bits to the number of bits obtained from a window of time during which the event was supposed to have occurred. Or, to put it in terms of event rates, it is merely the case that much fewer potentially misclassified events happen during the very small window of time provided by correlation, as opposed to the much larger number of events that happen during a dragnet fingerprinting attempt. Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. Personally, I believe that it may be possible to develop fingerprint resistance mechanisms good enough to also begin to make inroads against correlation, *if* the network is large enough to provide an extremely high event rate. Say, the event rate of an Internet-scale anonymity network. For this reason, I think it is very important for academic research to clearly state their event rates, and the entropy of their feature extractors and classifiers. As well as source code and full data traces, so that their results can be reproduced on larger numbers of targets and with larger event rates, as I mentioned in my other reply. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgp4G3BRZVD7p.pgp Description: PGP signature
Re: Tor seems to have a huge security risk--please prove me wrong!
On Sun, Aug 29, 2010 at 3:54 AM, Mike Perry mikepe...@fscked.org wrote: [snip] Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. If this is so— that people are trying to attack tor with size fingerprinting but failing because of the size quantization and then failing to publish because they got a non-result— then it is something which very much needs to be made public. Not only might future versions of tor make different design decisions with respect to cell size, other privacy applications would benefit from even a no-result in this area. *** 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?
Hi, Gregory Maxwell wrote (22 Aug 2010 00:55:49 GMT) : 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. I doubt there is something like the best way of using Tor. One always needs to balance the risks vs. the efforts needed to get some protection against it. More practically speaking: there are use cases the Tor Browser Button is perfect for, but it cannot prevent every leakage of anonymity to local disks. Then come Tor-ified VM setups that protect users a bit more but still somehow rely on the host operating system. Then comes running a Tor-ified Live system such as T(A)ILS [1] on bare metal. Each situation has its best fit solution but I don't think one solution can be told to be best in any cases. [1] https://amnesia.boum.rog/ 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. About performance: a five years old laptop with 1.7 GHz processor and 1GB RAM is able to run a fully-fledged Tor-ified desktop system such as T(A)ILS in VirtualBox. It was also true with qemu+kqemu last time I checked. About complexity: running a guest OS in a VM is really easy with VirtualBox (and presumably with its proprietary counterparts). But maybe I am missing the point. What kind of complexity are you talking of? 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). 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. 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. I'm sure there are use-cases such a sandbox would fit very well, and am in favour of developing new ways of using Tor when practical use-cases make it necessary. If it fits a bunch of (potential) users' needs, I do encourage you to push this idea forward. On the other hand: if we want to consider ease of use for many people as an important criterion, which we do, which one seems easier amongst the two following solutions? 1. Download T(A)ILS and burn it on a CD, then boot it when needed (possibly in a VM if you can afford it wrt. performance and security). 2. Replace your current OS with another one that supports SE Linux well enough to support the SE Linux enhanced sandbox described solution (examples needed), install the sandbox front-end program that does not exist yet, and setup the needed sandboxes for the apps that need to be Tor-ified and somehow isolated. Then you only need to never, ever confuse your nice sandboxed web browser with your other non-sandboxed one. As a T(A)ILS developer I am of course biased but #1 seems pretty much easier to me. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr-fingerprint.asc | The impossible just takes a bit longer. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor seems to have a huge security risk--please prove me wrong!
On Sun, Aug 29, 2010 at 12:54:59AM -0700, Mike Perry wrote: Thus spake Paul Syverson (syver...@itd.nrl.navy.mil): For those who want more background, you can read more at item #1 on https://www.torproject.org/research.html.en#Ideas (I hoped to transition https://www.torproject.org/volunteer.html.en#Research over to that new page, but haven't gotten around to finishing) Yes. Exploring defensive techniques would be good. Unlike correlation, fingerprinting seems more likely to be amenable to traffic shaping; although the study of this for countering correlation (as some of us recently published at PETS ;) may be an OK place to build on. Personally I still think trust is going to play a bigger role as an effective counter than general shaping, but one place we seem to be in sync is that it all needs more study. Yeah, though again I want to point out that what we are actually looking at when we intuitively believe fingerprinting to be easier to solve than correlation is the event rate from the base rate fallacy. Otherwise, they really are the same problem. Correlation is merely the act of taking a live fingerprint and extracting a number of bits from it, and adding these bits to the number of bits obtained from a window of time during which the event was supposed to have occurred. Or, to put it in terms of event rates, it is merely the case that much fewer potentially misclassified events happen during the very small window of time provided by correlation, as opposed to the much larger number of events that happen during a dragnet fingerprinting attempt. Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. I disagree. Most of what you say about base rates etc. is valid and should be taken into account, but that is not the only thing that is going on. First, you have just stated one reason that correlation should be easier than fingerprinting but then tried to claim it as some sort of methodological flaw. Truncating the lower 8 bits does have a significant impact on fingerprinting but little impact on correlation because of the windows and datasets, just like you said. But way more importantly, fingerprinting is inherently a passive attack. You are sifting through a pile of known fingerprints looking for matches and that's all you can do as an attacker. But its easy to induce any timing signature you want during a correlation attack. (It seems to be completely unnecessary because of point 1, but it would be trivial to add that if you wanted to.) Tor's current design has no mechanism to counter active correlation. Proposed techniques, such as in the recent paper by Aaron, Joan, and me, are clearly too expensive and iffy at this stoge of research. This is totally different for fingerprinting. One could have an active attack similar to fingerprinting in which one tries to alter a fingerprint to make it more unique and then look for that fingerprint. I don't want to get into a terminological quibble, but that is not what I mean by fingerprinting and would want to call it something else or start calling fingerprinting 'passive fingerprinting', something like that. Then there is the whole question of how effective this would be, plus a lot more details to say what this is, but anyway I think we have good reason to treat fingerprinting and correlation as different but related problems unless we want to say something trivial like They are both just instances of pattern recognition. Personally, I believe that it may be possible to develop fingerprint resistance mechanisms good enough to also begin to make inroads against correlation, *if* the network is large enough to provide an extremely high event rate. Say, the event rate of an Internet-scale anonymity network. For this reason, I think it is very important for academic research to clearly state their event rates, and the entropy of their feature extractors and classifiers. As well as source code and full data traces, so that their results can be reproduced on larger numbers of targets and with larger event rates, as I mentioned in my other reply. We don't have the luxury of chemistry or even behavioral stuff like population biology of some species of fish to just hand out full traces. There's this pesky little thing user privacy that creates a tension we have that those fields don't. We could also argue more about the nature of research and publication criteria, but I suspect that we will quickly get way off topic in such a discussion, indeed have already started. aloha, Paul *** To unsubscribe, send an e-mail to
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sun, 29 Aug 2010 00:25 +0200, intrigeri intrig...@boum.org wrote: Hi, Gregory Maxwell wrote (22 Aug 2010 00:55:49 GMT) : 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. I doubt there is something like the best way of using Tor. One always needs to balance the risks vs. the efforts needed to get some protection against it. More practically speaking: there are use cases the Tor Browser Button is perfect for, but it cannot prevent every leakage of anonymity to local disks. Then come Tor-ified VM setups that protect users a bit more but still somehow rely on the host operating system. Then comes running a Tor-ified Live system such as T(A)ILS [1] on bare metal. Each situation has its best fit solution but I don't think one solution can be told to be best in any cases. [1] https://amnesia.boum.rog/ That would be '.org' :) BTW is there somewhere from where the CACert root certificate (or fingerprint) can be downloaded with protection from an SSL cert I already trust? The above link, once corrected, generates an SSL warning. GD -- http://www.fastmail.fm - Same, same, but different... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Another cost mentioned by coderman was elevated privs for accelerated virtualization / para-virtualization. AFAIK VirtualBox does not need any special privileges (once the kernel part of the software is installed, and the modules/services loaded). the loading / configuring of kernel module part is one elevated task. route table changes / altering iptables rules and chains*, many other such things require elevated privileges. there are often host facilities to permit specific use of valid settings, and rsbac constraints, lots of other mitigation techniques... if you give up acceleration and do full softmmu / user only and constrained device emulation you can still have a guest / least privilege virtual machine, but the overhead is significant. fortunately fast virtio devices are become common across both userspace only and accelerated virtual machine implementations. i also like livecd as you mention, and qubes on live fedora is a nice setup, perhaps coupled with HTTPS-Fuse on-demand pre-caching file system overlays... many many different combinations and techniques to complement and fit a particular need. the limiting factor is time to explore them all and their relative strengths/weaknesses/trade-off's... http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html http://qubes-os.org/Architecture.html * i call this out specifically because you need extend beyond the basic VirtualBox / Qemu / VMWare settings associated with the common bridge, nat, host-only network devices and implement host level routing protections; otherwise you're exposed to a number of potential side channel and other attacks listed in the FAQ and elsewhere. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor + SELinux sandbox = leak proof without VM overhead?
On Sat, Aug 28, 2010 at 3:25 PM, intrigeri intrig...@boum.org wrote: ... Please don't misunderstand me. I'm not a fan of VM-based solutions and pretty much prefer the bare-metal + Live OS approach, but I feel we need to consider their pros and cons in a more detailed way than discarding them on the assumption that their cost must be too high else we would push for their usage much more than we do. one last note, these are all complementary techniques. the SELinux effort early on was applied to VMWare virtual machine rules per instance on virtual disks and across network devices. improving the usability of such a configuration by deploying via livecd images supporting a wide range of hardware would also be a clear improvement for many users. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Paul Syverson (syver...@itd.nrl.navy.mil): On Sun, Aug 29, 2010 at 12:54:59AM -0700, Mike Perry wrote: Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. I disagree. Most of what you say about base rates etc. is valid and should be taken into account, but that is not the only thing that is going on. First, you have just stated one reason that correlation should be easier than fingerprinting but then tried to claim it as some sort of methodological flaw. Truncating the lower 8 bits does have a significant impact on fingerprinting but little impact on correlation because of the windows and datasets, just like you said. But way more importantly, fingerprinting is inherently a passive attack. You are sifting through a pile of known fingerprints looking for matches and that's all you can do as an attacker. But its easy to induce any timing signature you want during a correlation attack. (It seems to be completely unnecessary because of point 1, but it would be trivial to add that if you wanted to.) Tor's current design has no mechanism to counter active correlation. Proposed techniques, such as in the recent paper by Aaron, Joan, and me, are clearly too expensive and iffy at this stoge of research. This is totally different for fingerprinting. One could have an active attack similar to fingerprinting in which one tries to alter a fingerprint to make it more unique and then look for that fingerprint. I don't want to get into a terminological quibble, but that is not what I mean by fingerprinting and would want to call it something else or start calling fingerprinting 'passive fingerprinting', something like that. Then there is the whole question of how effective this would be, plus a lot more details to say what this is, but anyway I think we have good reason to treat fingerprinting and correlation as different but related problems unless we want to say something trivial like They are both just instances of pattern recognition. Ah, of course. What I meant to say then was that passive fingerprinting really is the same problem as passive correlation. I don't spend a whole lot of time worrying about the global *active* adversary, because I don't believe that such an adversary can really exist in practical terms. However, it is good that your research considers active adversaries in general, because they can and do exist on more localized scales. I do believe that the global external passive adversary does exist though (via the ATT secret rooms that splice cables and copy off traffic in transit), and I think that the techniques used against passive fingerprinting can be very useful against that adversary. I also think a balance can be found to provide defenses against the global external passive adversary to try to bring their success rates low enough that their incentive might switch to becoming a local internal adversary, where they have to actually run Tor nodes to get enough information to perform their attacks. This is definitely a terminological quibble, but I think it is useful to consider these different adversary classes and attacks, and how they relate to one another. I think it is likely that we are able to easily defeat most cases of dragnet surveillance with very good passive fingerprinting defenses, but that various types of active surveillance may remain beyond our (practical) reach for quite some time. Personally, I believe that it may be possible to develop fingerprint resistance mechanisms good enough to also begin to make inroads against correlation, *if* the network is large enough to provide an extremely high event rate. Say, the event rate of an Internet-scale anonymity network. For this reason, I think it is very important for academic research to clearly state their event rates, and the entropy of their feature extractors and classifiers. As well as source code and full data traces, so that their results can be reproduced on larger numbers of targets and with larger event rates, as I mentioned in my other reply. We don't have the luxury of chemistry or even behavioral stuff like population biology of some species of fish to just hand out full traces. There's this pesky little thing user privacy that creates a tension we have that those fields don't. We could also argue more about the nature of research and publication criteria, but I suspect that we will quickly get way off topic in such a discussion, indeed have already started. In most cases, we pretty intensely frown on these attacks on the live Tor network, even for research purposes, so I don't think anyone is asking for live user traces.
Re: Tor seems to have a huge security risk--please prove me wrong!
Thus spake Gregory Maxwell (gmaxw...@gmail.com): On Sun, Aug 29, 2010 at 3:54 AM, Mike Perry mikepe...@fscked.org wrote: [snip] Any classifier needs enough bits to differentiate between two potentially coincident events. This is also why Tor's fixed packet size performs better against known fingerprinting attacks. Because we've truncated the lower 8 bits off of all signatures that use size as a feature in their fingerprint classifiers. They need to work to find other sources of bits. If this is so??? that people are trying to attack tor with size fingerprinting but failing because of the size quantization and then failing to publish because they got a non-result??? then it is something which very much needs to be made public. According to the research groups Roger has talked to, yes, this is the case. Not only might future versions of tor make different design decisions with respect to cell size, other privacy applications would benefit from even a no-result in this area. The problem though is that it's hard to publish a no-result, unless its pretty a pretty surprising no-result, or at least a quantifiable no-result. It's not terribly surprising that existing fingerprinting techniques do not work well out of the box against Tor, because a lot less information is available during a Tor session, and there is a lot more noise (due to more than just the 512-byte cell size). If someone actually worked hard and took all these things into account, and still had a result that said Fingerprinting on Tor does not usually work unless you have fewer than than X numbers of targets and/or event rates below Y, it still probably would belong more in a tech report than a full academic paper, unless it also came with information-theoretic proofs that showed exactly why their implementation got the results it did. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpMoFK8glL4M.pgp Description: PGP signature
Tcpcrypt and tor
Tcpcrypt (http://tcpcrypt.org/) proposes a new extension to TCP to enable opportunistic encryption with optional authentication. From a features and performance perspective, it's probably exactly what we need to get away from the almost-everything-in-the-clear Internet that we have today. Unfortunately, it won't interact well with tor as tor is today: It's a TCP level technique and with tor the TCP sessions don't cross the network. This means it would provide security between an exit and the destination but not end to end security. I spent a little time thinking about this and trying to figure out if there were some socket options that could be added to tcpcrypt in order to make it run in a purely proxy mode where the data is end to end encrypted but the TCP still runs on the exit. However, I don't think this is possible: It integrates deeply with the TCP state machine. For example, it uses TCP's sequence numbers as the counter and replay prevention. It also uses TCP retransmission (with it's own MAC) to deal with forged data. I don't like the idea that a future layer-3 transport in tor is the solution to this: Today tor gains a lot of fingerprinting immunity by isolating the layer 3/4 and it's also nice that the tor software doesn't need access to weird raw sockets so that it can inject packets. So perhaps someone smarter than I can see a way that tor could gain end to end crypto in a world using tcpcrypt, perhaps with some changes to tcpcrypt? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tcpcrypt and tor
On 08/29/2010 09:21 PM, Gregory Maxwell wrote: Tcpcrypt (http://tcpcrypt.org/) proposes a new extension to TCP to enable opportunistic encryption with optional authentication. From a features and performance perspective, it's probably exactly what we need to get away from the almost-everything-in-the-clear Internet that we have today. This looks like a protocol by Adam Langley: https://secure.wikimedia.org/wikipedia/en/wiki/Obfuscated_TCP All the best, Jake *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
