netdev - Re: [PATCH] TCP: Add support for TCP Stealth

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 02 Jan 2015 13:50:56 +0100
From:	Daniel Borkmann <dborkman@...hat.com>
To:	Christian Grothoff <christian@...thoff.org>
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/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?), 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.
It feels like a property that goes beyond the scope of a specific,
individual application, put differently, what about an additional
central configuration interface? 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?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html