[tor-dev] HTTPS Server Impersonation

[Tom Ritter]

On 30 September 2013 07:01, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
> On Mon, Sep 30, 2013 at 01:03:14AM -0700, Rohit wrote:
>> This should satisfy most goals.
>> - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS traffic and Tor->Bridge. (Both use TLS)
>
> This seems false to me; it's not too hard to distinguish Tor-over-TLS
> from HTTP-over-TLS, right?


Difficulty is relative. From an academic standpoint - no it's not too
difficult.  From an engineering standpoint, I think it's difficult
enough to be worth pursuing.

Brandon Wiley tested bypassing protocol assignment on a lot of
real-world DPI hardware[0]. It's extremely rare for any of them to
make a protocol assignment on anything other than the first packet of
a stream.  It's fast, it's not stateful, it takes less memory, it
works in 99.9% of cases. For the few remaining cases, it's extremely,
extremely rare (if not 'never') for a device to do statistical
analysis to classify a protocol.

So while it's _possible_ for someone to detect the difference, the
amount of engineering that's required in a deployment situation is
much greater than the amount needed to build a POC. And even if
someone does build a way to detect it, it will be a statistical
classification (probably), so by altering Tor's behavior we could
break their classifier (for example, by using AlSabah and your's
traffic splitting approach, but applied to mimic normal browser
resource loads). And, I think, the goal isn't to achieve a 100%
bypass, but rather to raise their false positive rate high enough that
it's undeployable without extreme backlash[1].

-tom

[0] https://github.com/blanu/Dust
[1] I'd love to get a better handle on this, but I've heard that when
China blocked Github, the outrage was enough to get it unblocked in
short enough order.