linux-kernel - Re: [PATCH] TCP: add option for silent port knocking with integrity protection

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:	Thu, 12 Dec 2013 06:34:24 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Christian Grothoff <grothoff@...tum.de>
Cc:	Jacob Appelbaum <jacob@...elbaum.net>,
	Andi Kleen <andi@...stfloor.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, knock@...net.org
Subject: Re: [PATCH] TCP: add option for silent port knocking with integrity
 protection

On Thu, 2013-12-12 at 12:43 +0100, Christian Grothoff wrote:
> On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
> > I think that generally, I would prefer if the code didn't use MD5 but
> > otherwise, I don't see any real risk of adding an exploitable hole. It
> > seems silly to disable it by default though - ideally, I'd like a sysctl
> > to ensure that Tor could use this without making the user recompile
> > their kernel. That is more of a pain than running a userspace helper, I
> > think.
> > 
> > All the best,
> > Jacob
> 
> Given that the output is truncated to 32 bits and that performance (SYN
> flood) is also a concern, AND that the original TCP SQN generation is
> also MD5-based (and we want to look the same), what disadvantage do you
> see over MD5?  Given the truncation to 32 bits, I don't think a stronger
> hash would do anything for us.
> 
> As for it being disabled by default, we did this with respect to
> kernel submission guidelines which we understood said that features
> should _initially_ always be submitted with disabled-by-default
> (presumably so that until they have stabilized, nobody is harmed
> unless they explicitly activate the code).
> 
> I don't see the point in having a sysctl, as applications have to
> explicitly request it anyway.

Wait a minute.

Your implementation looks like another TCP MD5 thing, but with a single
secret. Check at git history to discover how many bugs we had to fix.
Ask yourself how wrong was TCP MD5 being implemented in the kernel.

Very soon you'll need to support different secrets. You do not want all
clients share a common secret, do you ? How can a server change its
secret without disrupting clients ?

How having a constant initial sequence number can even be valid ?
What about TCP timestamps being not available at all ?
How typical servers can be behind a load balancer ?
Or am I missing something ?

With various proposals (like TCP minion), maybe its time to be able to
implement part of TCP stack in user land (Keep the mux inside the
kernel, and forward raw incoming packets to user land where all the
crazy things can be done without kernel patching.)

To me your idea is very close from TCP fast open. The only difference
would be for the server to not send its cookie in SYNACK ?

Sorry, you seem to hurry to get this facility, I do not see how it can
really save the world. If it does, you definitely should get feedback
from TCP community at IETF.

Thanks


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/