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 10:19:43 +0000
From:	Jacob Appelbaum <jacob@...elbaum.net>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Christian Grothoff <grothoff@...tum.de>,
	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

Andi Kleen:
>> ... and then do the same for the first TCP packet with payload? And you
> 
> That gets passed through by the firewall rule.
> 
As an application developer, I find it very common for our users to have
difficulty synchronizing userspace program needs and firewall rules.
This option would greatly enable hiding of Tor bridges and other
services where mere presence on the network is in itself a vulnerability.

>> seriously would consider that "safer" or "less error prone", starting
> 
> Yes the risk of adding exploitable holes to the kernel is signficantly
> lower.

In the case of a Tor bridge, when people are able to scan the entire
internet, as they are, they find Tor bridges and then add those bridges
to a database or to various national firewalls.

Increasing scanning resistance improves the security of such bridges -
though a passive (eg: sniffing) adversary may still discover such a
bridge for blocking, this kernel modification has a second benefit - it
will prevent most exploitable conditions from having an avenue of
attack. Such an attacker, even if they know the IP of a bridge will need
to find a way to break TLS or any of our other transport layer security
protocol that we're using.

I think that generally, I would prefer if the code didn't use MD5 but
otherwise, I don't see any real disk 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
--
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