netdev - 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 12:23:54 +0000
From:	Jacob Appelbaum <jacob@...elbaum.net>
To:	Christian Grothoff <grothoff@...tum.de>
CC:	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

Christian Grothoff:
> 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.

If we believe that MD5 is not secure, we should not use it. That others
use it is not a strong reason to use it. Everyone should stop using MD5
- especially truncated MD5. :)

> 
> 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 think that is a fine reason at submission time but this should not be
the default state for very long.

> I don't see the point in having a sysctl, as applications have to
> explicitly request it anyway.

To have it supported and to have it enabled in the kernel are not
exactly the same thing. It would be nice if it was available to everyone
by default (likely with some CAP) and to enable it on a systemwide
basis, one could simply flip a sysctl. One also needs to use it in an
application, obviously.

All the best,
Jacob
--
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