Re: [tor-dev] Internet-wide scanning for bridges

2014-12-17 Thread David Fifield
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 t

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-17 Thread Vlad Tsyrklevich
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 trivi

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-17 Thread Sebastian Hahn
Hi there, On 14 Dec 2014, at 20:06, Vlad Tsyrklevich 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 >

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-14 Thread Vlad Tsyrklevich
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

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-14 Thread Philipp Winter
On Sat, Dec 13, 2014 at 08:54:29AM -0500, A. Johnson wrote: > There are even better solutions than this: > 1. Port knocking: > 2. Single-packet authorization: > > > ScrambleSuit has

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-14 Thread Philipp Winter
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

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-13 Thread A. Johnson
There are even better solutions than this: 1. Port knocking: 2. Single-packet authorization: ScrambleSuit has implemented something like #2, and its paper (http://www.cs.kau.se/phil

Re: [tor-dev] Internet-wide scanning for bridges

2014-12-13 Thread Fabio Pietrosanti (naif) - lists
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

[tor-dev] Internet-wide scanning for bridges

2014-12-12 Thread Vlad Tsyrklevich
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 o