Message-ID: <54A6A5D2.1050806@grothoff.org>
Date:	Fri, 02 Jan 2015 15:06:10 +0100
From:	Christian Grothoff <christian@...thoff.org>
To:	Daniel Borkmann <dborkman@...hat.com>
CC:	Julian Kirsch <kirschju@....in.tum.de>, netdev@...r.kernel.org,
	Jacob Appelbaum <jacob@...elbaum.net>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: [PATCH] TCP: Add support for TCP Stealth

On 01/02/2015 01:50 PM, Daniel Borkmann wrote:
> On 01/01/2015 04:32 PM, Christian Grothoff wrote:
> ...
>> That approach is highly vulnerable to timing attacks, and doesn't answer
>> how TCP clients without special capabilities could set the ISN correctly
>> either. Playing with raw sockets is the kind of geeky hack that is
> 
> Right, for client/server side you'd need to have the capabilities and
> then drop them later, which would make that approach less convenient
> for user space applications (despite not having to have a port knocking
> uapi in the TCP core itself). For the server, you might get away with a
> central daemon spawning sockets via IPC, but for the unprivileged
> client to e.g., let it set it's own ISN via setsockopt(2) would be a
> bad idea.
> 
>> unlikely to give us the combination of usability and security required
>> to significantly reduce the ongoing large-scale compromise of network
>> equipment by spy agencies.
> 
> Out of curiosity, when you say you want to significantly reduce the
> large-scale compromise of services by hiding ports, how do you solve
> i) the pre-shared key distribution issue you need for your approach
> (are you mostly targeting administrators for accessing their companies
> router/firewall management interfaces?), 

Our assumption is that this solution will work if SSH access to the
system is limited to a small set of users that can easily agree on an
additional passphrase.  We do not claim to solve the key distribution
issue in general (the GNU Name System can solve it for some application
scenarios, but that's out of scope for Knock).  Like most security
solutions, this works for some scenarios, but not all.

> and ii) the broad adoption of
> this setsockopt(2) in applications? I think for ii) it would be great
> not having to change and recompile every possible client _and_ server
> application if they don't have the change upstreamed in their project.

Correct, for that we have libknockify, a library you can LD_PRELOAD,
setting the passphrase via an environment variable.  Now, this doesn't
work for applications that don't permit LD_PRELOAD (like openssh) or use
some TCP sockets where TCP Stealth should be active, and others where it
should not be.  But for tools like 'netcat', 'telnet', 'wget' and many
other small tools, libknockify will work.

> It feels like a property that goes beyond the scope of a specific,
> individual application, put differently, what about an additional
> central configuration interface?

With our patch for systemd support, we kind of have a 'central'
configuration interface for "next-generation" servers that support
systemd-style listening.  For clients, using libknockify works usually
pretty well as clients usually don't have many different types of TCP
sockets open.

> Other than that, is there a plan for
> key rotations in other words, to have a grace period for a key
> transition as peers might not have synced clocks?

I have no such plans, as it would complicate the system quite a bit and
thus also reduces usability.  It would way complicate the key
distribution issue you mentioned, and also the libknockify-style
integration where currently the PSK can simply be passed via an
environment variable would also have to be done differently (i.e.
contacting some kind of PSK-oracle service via IPC). The result would be
a huge increase in complexity for IMO a rather small gain in security
for possibly only a small set of users.


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists