On 8/20/14, Daniel Borkmann <[email protected]> wrote: > On 08/20/2014 03:43 PM, Jacob Appelbaum wrote: >> On 8/19/14, Florian Westphal <[email protected]> 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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
