Hello, while taking a looking at TorCloud I it used static OR and obfs2+obfs3 ports making them trivial to discover by scanning EC2's IP address space. This led me to consider the more general attack of internet-wide scanning to discover Tor bridges. Most Tor relays run their ORPorts on port 443 or 9001 so I began investigating there. I began by looking at Project Sonar's port 443 SSL certificate database looking for certificates matching the tor certificate pattern. In talking with Eric Wustrow about ZMap, I discovered that he and the other ZMap authors had already published about this attack in their original paper. Eric mentioned that in his discussion with Roger that the response to the attack was going to be the soon-to-be-deployed obfuscated transports which were intended to be run on random high ports; however, the eventual roll out of obfsproxy did not change the fact that bridge's ORPorts continue to be publicly accessible. While I was analyzing Internet-wide survey-data for port 443 and 9001 (helpfully provided by Project Sonar/H D Moore) I found the Onionoo data set. I was able to quantify the impact of the attack using the Onionoo data and verify it using the ZMap scans. There are 4267 bridges, of them 1819 serve their ORPort on port 443 and 383 serve on port 9001. That's 52% of tor bridges. There are 1926 pluggable-transports enabled bridges, 316 with ORPort 443 and 33 with ORPort 9001. That's 18% of Tor bridges. 203 (64%) of PT-enabled bridges with ORPort 443 were TorCloud. I was able to approximately verify these figures using the Internet-wide scans. By grabbing bridge's certificates and calculating their hashed fingerprint I realized I was also discovering a fair amount of private bridges not included in the Onionoo data set. The results aren't too awful, just under 20% of PT-enabled bridges are affected. It's unclear to me if the low number of PT-enabled bridges (and corresponding high number of vulnerable non-PT-enabled bridges) is a historical artifact or a consequence of out-of-date documentation like https://www.torproject.org/docs/bridges.html.en not setting up pluggable transports. Eliminating the ORPort entirely for PT-enabled bridges seems like the ultimate solution to this attack, but the implications of such a change are unclear to me. Another change to mitigate this issue is changing the behavior of ports specified as 'auto' and then changing defaults and documentation to use auto by default. Currently specifying 'auto' in your torrc lets the OS decide the port; however, if tor were to generate a random port on first use that it continued to use across restarts it would it possible to use this for ORPorts and pluggable transports by default (as opposed to the current situation where for bridges you want ORPort auto but constant PT ports and a constant ORPort for relays which is confusing.) I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure. - Vladislav
On 12/13/14 1:33 AM, Vlad Tsyrklevich wrote:
I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure.
IMHO the real point is that Tor, is not employing the techniques that used since decades by the COMSEC solutions in the radio-frequency, that is "frequency hopping". On the internet we have TCP ports, on the radio-spectrum we have frequency. Just apply the various, multiple, available, well documented techniques used to provide additional L1/L2 safety to the radio-frequency transmission techniques to Tor, et voilà, Tor would acquire important resiliency properties against massive scanning. That's just a concept and approach, it would require a bit more of research, but i'm quite confident that would provide very important benefit compared to the minor performance issues introduced. -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
There are even better solutions than this: 1. Port knocking: <https://wiki.archlinux.org/index.php/Port_Knocking> 2. Single-packet authorization: <http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf> ScrambleSuit has implemented something like #2, and its paper (http://www.cs.kau.se/philwint/pdf/wpes2013.pdf) describes its authentication mechanisms as preventing detecting via network-wide scanning. However, I can’t say how it actually got implemented. Aaron
On Dec 13, 2014, at 3:40 AM, Fabio Pietrosanti (naif) - lists <lists@infosecurity.ch> wrote:
On 12/13/14 1:33 AM, Vlad Tsyrklevich wrote:
I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure.
IMHO the real point is that Tor, is not employing the techniques that used since decades by the COMSEC solutions in the radio-frequency, that is "frequency hopping".
On the internet we have TCP ports, on the radio-spectrum we have frequency.
Just apply the various, multiple, available, well documented techniques used to provide additional L1/L2 safety to the radio-frequency transmission techniques to Tor, et voilà, Tor would acquire important resiliency properties against massive scanning.
That's just a concept and approach, it would require a bit more of research, but i'm quite confident that would provide very important benefit compared to the minor performance issues introduced.
-- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Do we currently have any ETAs/timelines/estimates when the next generation of hidden services would be released? There isn't much information that I could find in my search so I can only imagine it will be at least a year? -T -- Activist, anarchist and a bit of a dreamer. Current Fingerprint: E771 BE69 4696 F742 DB94 AA8C 5C2A 8C5A 0CCA 4983 Key-ID: 0CCA4983 Master Fingerprint: DDEF AB9B 1962 5D09 4264 2558 1F23 39B7 EF10 09F0 Key-ID: EF1009F0 Twitter: @CthulhuSec XMPP: thecthulhu@jabber.ccc.de
On Sat, Dec 13, 2014 at 5:47 PM, Thomas White <thomaswhite@riseup.net> wrote:
Do we currently have any ETAs/timelines/estimates when the next generation of hidden services would be released? There isn't much information that I could find in my search so I can only imagine it will be at least a year?
I really, truly hope that it can be some time in 2015. I am competent to implement it, if need be. But right now, it isn't funded, and there isn't a big volunteer base to lead it. So unless that changes, it's uncertain. -- Nick
On Sat, Dec 13, 2014 at 08:54:29AM -0500, A. Johnson wrote:
There are even better solutions than this: 1. Port knocking: <https://wiki.archlinux.org/index.php/Port_Knocking> 2. Single-packet authorization: <http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf>
ScrambleSuit has implemented something like #2, and its paper (http://www.cs.kau.se/philwint/pdf/wpes2013.pdf) describes its authentication mechanisms as preventing detecting via network-wide scanning. However, I can’t say how it actually got implemented.
You could describe ScrambleSuit as single-packet authorisation on the application layer. In the implementation, a client proves knowledge of a shared secret in the first stream of bytes (maybe in one packet, maybe in more), it sends to a bridge. If the client cannot prove knowledge of the secret, the bridge won't respond. obfs4 [0] continues this idea. [0] https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4-... Cheers, Philipp
On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote:
I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure.
You are raising good points here but keep in mind that we also want at least *some* (vanilla) bridges which run on port 443. There are some adversaries such as captive portals which only allow communication over a small set of ports and 443 is one of these ports. While these bridges would easily fall prey to Internet-wide scanning, they would still be useful for users behind captive portals. Cheers, Philipp
I'm not against keeping some around, but this warning is unlikely to turn around the thousands that currently match this configuration--hopefully it'll just encourage future bridge operators to use a 'safer' configuration. The obfs4proxy README shows users how to set-up obfs4 running over port 443 which is probably the most desirable option: those users can evade network restrictions without enabling discovery by scanning. On Sun Dec 14 2014 at 10:35:16 AM Philipp Winter <phw@nymity.ch> wrote:
On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote:
I've attached a patch to warn bridge operators running with ORPort set to 443 or 9001 as a stop-gap measure.
You are raising good points here but keep in mind that we also want at least *some* (vanilla) bridges which run on port 443. There are some adversaries such as captive portals which only allow communication over a small set of ports and 443 is one of these ports. While these bridges would easily fall prey to Internet-wide scanning, they would still be useful for users behind captive portals.
Cheers, Philipp _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi there, On 14 Dec 2014, at 20:06, Vlad Tsyrklevich <vlad@tsyrklevich.net> wrote:
I'm not against keeping some around, but this warning is unlikely to turn around the thousands that currently match this configuration--hopefully it'll just encourage future bridge operators to use a 'safer' configuration. The obfs4proxy README shows users how to set-up obfs4 running over port 443 which is probably the most desirable option: those users can evade network restrictions without enabling discovery by scanning.
I really dislike warnings unless we absolutely need to have them, and this imo is in the category of "change the default, update the docs", especially because just changing the port is not a real solution in my book. Cheers Sebastian
I totally agree with you, the ideal solution is for bridges to be security to by default: Either by getting rid of the ORPort for bridges and requiring the use of PTs, or changing the behavior of 'auto' for ports and having ORPort be set to auto by default. However, these changes don't appear trivial to me. I do plan to also update the documentation to use 'ORPort auto' for bridges, but I think it's also useful to nudge bridge operators to a safer configuration in the short term (the same way tor already does for HS+relay colocation and a couple of other cases.) On Wed Dec 17 2014 at 11:12:01 AM Sebastian Hahn <sebastian@torproject.org> wrote:
Hi there,
On 14 Dec 2014, at 20:06, Vlad Tsyrklevich <vlad@tsyrklevich.net> wrote:
I'm not against keeping some around, but this warning is unlikely to turn around the thousands that currently match this configuration--hopefully it'll just encourage future bridge operators to use a 'safer' configuration. The obfs4proxy README shows users how to set-up obfs4 running over port 443 which is probably the most desirable option: those users can evade network restrictions without enabling discovery by scanning.
I really dislike warnings unless we absolutely need to have them, and this imo is in the category of "change the default, update the docs", especially because just changing the port is not a real solution in my book.
Cheers Sebastian
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, Dec 12, 2014 at 04:33:05PM -0800, Vlad Tsyrklevich wrote:
Hello, while taking a looking at TorCloud I it used static OR and obfs2+obfs3 ports making them trivial to discover by scanning EC2's IP address space. This led me to consider the more general attack of internet-wide scanning to discover Tor bridges. Most Tor relays run their ORPorts on port 443 or 9001 so I began investigating there.
I began by looking at Project Sonar's port 443 SSL certificate database looking for certificates matching the tor certificate pattern. In talking with Eric Wustrow about ZMap, I discovered that he and the other ZMap authors had already published about this attack in their original paper. Eric mentioned that in his discussion with Roger that the response to the attack was going to be the soon-to-be-deployed obfuscated transports which were intended to be run on random high ports; however, the eventual roll out of obfsproxy did not change the fact that bridge's ORPorts continue to be publicly accessible.
While I was analyzing Internet-wide survey-data for port 443 and 9001 (helpfully provided by Project Sonar/H D Moore) I found the Onionoo data set. I was able to quantify the impact of the attack using the Onionoo data and verify it using the ZMap scans. There are 4267 bridges, of them 1819 serve their ORPort on port 443 and 383 serve on port 9001. That's 52% of tor bridges. There are 1926 pluggable-transports enabled bridges, 316 with ORPort 443 and 33 with ORPort 9001. That's 18% of Tor bridges. 203 (64%) of PT-enabled bridges with ORPort 443 were TorCloud. I was able to approximately verify these figures using the Internet-wide scans. By grabbing bridge's certificates and calculating their hashed fingerprint I realized I was also discovering a fair amount of private bridges not included in the Onionoo data set.
Eliminating the ORPort entirely for PT-enabled bridges seems like the ultimate solution to this attack, but the implications of such a change are unclear to me. Another change to mitigate this issue is changing the behavior of ports specified as 'auto' and then changing defaults and documentation to use auto by default. Currently specifying 'auto' in your torrc lets the OS decide the port; however, if tor were to generate a random port on first use that it continued to use across restarts it would it possible to use this for ORPorts and pluggable transports by default (as opposed to the current situation where for bridges you want ORPort auto but constant PT ports and a constant ORPort for relays which is confusing.)
Thanks, these are great results. You're right that disabling the ORPort for PT bridges is the right solution. There are some technical obstacles summarized in this ticket: "Obfsbridges should be able to 'disable' their ORPort" https://trac.torproject.org/projects/tor/ticket/7349 Basically, whatever tests bridges for reachability is ignorant of PTs, so it only tries connecting to the ORPort. Since the bridge appears unreachable, it doesn't go into BridgeDB to be handed out. So there are a few different tasks that need to be unraveled to make it possible. The reachability testing also caused problems for us with obfs2/obfs3. People would set up an obfsbridge, and obfsproxy would pick a random port to listen on, and people didn't know that and so didn't open the port on their firewall. There were a lot of bridges with a reachable ORPort but unreacable obfsport. Because the ORPort was reachable, they were in BridgeDB, even though they were useless as PT bridges. Having an easily findable ORPort definitely makes it easier for those censors that do proactive or reactive scanning to find bridges. (Only the GFW does reactive scanning as far as I know, and I haven't seen evidence for or against proactive scanning like you did.) Even if the ORPort is hidden on some random port, it still gives the censor a good distinguisher for, say, suspected obfs3 streams: When you see something that might be obfs3, scan all the other ports on the IP and see if you find an ORPort. Bridges that are easy to scan for aren't totally useless, because they still work in places where the censor isn't as sophisticated---like the default Tor Browser bridges, which are easily blockable because their addresses are hardcoded in the source code, but for whatever reason aren't blocked in many places that censor vanilla Tor. I wouldn't say that it's always a mistake for a bridge to be running on 443. Sometimes you need it to get through a firewall. And then it depends on the censor's capabilities, whether you want vanilla Tor on 443 or obfs3 on 443. Vanilla Tor is fingerprintable as Tor, but it is at least TLS; while obfs3 doesn't look like Tor but doesn't look like TLS either. One configuration might get past a censor that blacklists Tor; the other might get past one that whitelists TLS. But I think you're right, that a lot more people are exposing ORPorts on 443 or 9001 than are aware. David Fifield
On Wed, Dec 17, 2014 at 08:00:01PM -0800, David Fifield wrote:
Thanks, these are great results. You're right that disabling the ORPort for PT bridges is the right solution. There are some technical obstacles summarized in this ticket: "Obfsbridges should be able to 'disable' their ORPort" https://trac.torproject.org/projects/tor/ticket/7349 Basically, whatever tests bridges for reachability is ignorant of PTs, so it only tries connecting to the ORPort. Since the bridge appears unreachable, it doesn't go into BridgeDB to be handed out. So there are a few different tasks that need to be unraveled to make it possible.
The reachability testing also caused problems for us with obfs2/obfs3. People would set up an obfsbridge, and obfsproxy would pick a random port to listen on, and people didn't know that and so didn't open the port on their firewall. There were a lot of bridges with a reachable ORPort but unreacable obfsport. Because the ORPort was reachable, they were in BridgeDB, even though they were useless as PT bridges.
Having an easily findable ORPort definitely makes it easier for those censors that do proactive or reactive scanning to find bridges. (Only the GFW does reactive scanning as far as I know, and I haven't seen evidence for or against proactive scanning like you did.) Even if the ORPort is hidden on some random port, it still gives the censor a good distinguisher for, say, suspected obfs3 streams: When you see something that might be obfs3, scan all the other ports on the IP and see if you find an ORPort.
I thought of another angle to this, also related to #7349. Because it's impossible to run a PT bridge that both 1) hides its ORPort, and 2) appears in BridgeDB, that means that easily detectable ORPort connections can burn the IP, blocking the PT port in the process. Imagine this: you set up a nice obfs4 bridge. obfs4 is listening on port 20001, and the ORPort is on 45678. Because of #7349, you can't block the ORPort on 45678. Both ports end up in BridgeDB. People get your bridge when they request obfs4, and they are happy. But one day an innocent user requests a vanilla bridge, and connects to port 45678 using plain Tor. The connection is detected by the firewall, and the IP (and with it the obfs4 port) is blocked. The problem is that currently, PT⇒ORPort. So a censor that wants to block plain Tor and PTs, only really needs to be able to detect plain Tor, because it's always running on the same host a PT is running on. (I'm oversimplifying a bit: not always will the ORPort be handed out by BridgeDB.) Maybe I misunderstand something about how PublishServerDescriptor and BridgeDB work? David Fifield
I asked Isis about this on #tor-dev and she confirmed that this is indeed possible. I think a mitigation to only hand-out vanilla ORPorts for non-PT enabled bridges is reasonable, but closing #7349 is the real solution since I think this edge case is less likely to be hit than simply port scanning suspected bridges which is only solvable by #7349. The problems I see with closing #7349 are two-fold: 1) As Isis mentioned on IRC, it makes it easier for an attacker to spam the BridgeAuth with fake bridge entries unless we start keeping the bridge auth updated with new-PTs as they're developed to run test handshakes. This might be painful depending on how frequently/quickly we add new PTs. #6396 will have to be re-thought for a ORPort-less bridge world. 2) #9366 shows one of the first issues you hit with an ORPort-less bridge: there are numerous assumptions about relays having an ORPort enabled in the source and in the specifications. Enumerating all of the affected locations in the client/bridgeauth/directory(/other?) code and coming to a consensus about what form the changes should take will require some work. On Wed Dec 31 2014 at 12:06:19 AM David Fifield <david@bamsoftware.com> wrote:
On Wed, Dec 17, 2014 at 08:00:01PM -0800, David Fifield wrote:
Thanks, these are great results. You're right that disabling the ORPort for PT bridges is the right solution. There are some technical obstacles summarized in this ticket: "Obfsbridges should be able to 'disable' their ORPort" https://trac.torproject.org/projects/tor/ticket/7349 Basically, whatever tests bridges for reachability is ignorant of PTs, so it only tries connecting to the ORPort. Since the bridge appears unreachable, it doesn't go into BridgeDB to be handed out. So there are a few different tasks that need to be unraveled to make it possible.
The reachability testing also caused problems for us with obfs2/obfs3. People would set up an obfsbridge, and obfsproxy would pick a random port to listen on, and people didn't know that and so didn't open the port on their firewall. There were a lot of bridges with a reachable ORPort but unreacable obfsport. Because the ORPort was reachable, they were in BridgeDB, even though they were useless as PT bridges.
Having an easily findable ORPort definitely makes it easier for those censors that do proactive or reactive scanning to find bridges. (Only the GFW does reactive scanning as far as I know, and I haven't seen evidence for or against proactive scanning like you did.) Even if the ORPort is hidden on some random port, it still gives the censor a good distinguisher for, say, suspected obfs3 streams: When you see something that might be obfs3, scan all the other ports on the IP and see if you find an ORPort.
I thought of another angle to this, also related to #7349. Because it's impossible to run a PT bridge that both 1) hides its ORPort, and 2) appears in BridgeDB, that means that easily detectable ORPort connections can burn the IP, blocking the PT port in the process.
Imagine this: you set up a nice obfs4 bridge. obfs4 is listening on port 20001, and the ORPort is on 45678. Because of #7349, you can't block the ORPort on 45678. Both ports end up in BridgeDB. People get your bridge when they request obfs4, and they are happy. But one day an innocent user requests a vanilla bridge, and connects to port 45678 using plain Tor. The connection is detected by the firewall, and the IP (and with it the obfs4 port) is blocked.
The problem is that currently, PT⇒ORPort. So a censor that wants to block plain Tor and PTs, only really needs to be able to detect plain Tor, because it's always running on the same host a PT is running on. (I'm oversimplifying a bit: not always will the ORPort be handed out by BridgeDB.)
Maybe I misunderstand something about how PublishServerDescriptor and BridgeDB work?
David Fifield _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (8)
-
A. Johnson -
David Fifield -
Fabio Pietrosanti (naif) - lists -
Nick Mathewson -
Philipp Winter -
Sebastian Hahn -
Thomas White -
Vlad Tsyrklevich