Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG

[Jacob Appelbaum <[e-mail]>]

On 8/20/14, Daniel Borkmann <[e-mail]> wrote:
> On 08/20/2014 03:43 PM, Jacob Appelbaum wrote:
>> On 8/19/14, Florian Westphal <[e-mail]> wrote:
> [...]
>>> - Your adversary may be able to do full passive monitoring of
>>> all network traffic (also compare "replay" above), so whats the purpose
>>> of "avoiding" active scans?
>>
>> Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC
>> do active scans when their full passive monitoring isn't enough. This
>> hampers that angle of information gathering. It also ensures that even
> [...]
>
> Ok, but for the majority of use cases, lets presume that you'd
> pass one of these secretly hidden taps located at some cooperative
> IX. Assuming the worst case that some passive adversary has access
> to enough taps distributed at convenient locations, did a previous
> active port scan and knows that from your machine port 22 is closed.
> Later, it observes a two-way flow to port 22 to that machine and the
> existence of the service is of course nevertheless revealed.

Sounds good. We've just taken detection of the service from everyone
in the world to a passive wiretapping attacker observing a
sysadmin/user and the service. Otherwise they're going to need to send
~2^32-1 packets per port guess.

>
> You might be able then to 'mitigate' actual access to the service
> a bit, but then again 32 bit is perhaps a limited sense of 'security'.

Sure, I agree. We're limiting against a specific, well scoped specific
issue that is pervasive and a problem. We do not solve every problem
for every attacker. We have deployed code that is running today and it
works, roughly. :)

> It would also be required that machines running more than one service
> have /all/ services somewhat protected by TCP stealth, otherwise an
> attacker moves on with the next service as an attack vector

That would be consistent but it isn't required. Not all services are
created equally - e.g.: OpenSSH ( + ssh keys + TCP Stealth) has root
privileges on a system, even if privilege separated. Not all services
are so enabled.

Another use case is for Tor bridges - in this case - we only care
about active probing. Even in advanced cases like the "great" firewall
of China, they use active probing to confirm their wiretapped machine
learning decisions...

> Again,
> if also services over other transport protocols are used on the
> machines (that cannot make use of TCP stealth), an attacker might
> first probe for these as an easier target to get in.

Of course.

> Key propagation is certainly an issue I assume; you might also want
> to consider to rotate them etc; large public sites most likely cannot
> make use of TCP stealth, and the larger a group becomes, the more weak
> points might arise (including humans) to disclose the shared secret
> somehow.

Per user shared secrets seem to fit the bill here.

> Then again, it might also not be worth it for pubkeys as it
> would significantly increase computational complexity on the server
> side and we're only talking about 32 bit ...
>

I think that the decoy routing field holds some interesting tricks for
public keys. Telex hides a signature in the TLS handshake, for
example. Perhaps for a later version of TCP stealth? :)

> /offtopic here, but wouldn't it then be better to work towards full
> encryption like CurveCP et al is trying to solve ...

I'd like to see that too. We'll get there and this is one step in a
similar direction.

All the best,
Jacob