All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] TCP: add option for silent port knocking with integrity protection
@ 2013-12-10 18:35 Christian Grothoff
  2013-12-11 20:01 ` David Miller
  0 siblings, 1 reply; 22+ messages in thread
From: Christian Grothoff @ 2013-12-10 18:35 UTC (permalink / raw)
  To: David S. Miller, netdev; +Cc: linux-kernel, knock, Jacob Appelbaum

[-- Attachment #1: Type: text/plain, Size: 22004 bytes --]

Hi!

We've written a patch to add support for a modern variant of silent TCP
port knocking to Linux, and hope to convince you to include it in the
kernel by default.

The motivation is simple: given security services that stockpile
undisclosed exploits, running TCP services on a visible port is asking
for trouble.  Modern port scanners can scan IPv4 in less than an hour
from a single system.  Still, we need to run services, such as SSH or
VPN access on public IP addresses and make (some of) them available to
the global Internet.  Furthermore, even on the LAN it might be good to
have some additional protection against an insider attack.  Some
countries or ISPs may declare the use of certain software illegal, so
again hiding the fact that a service is running might offer some basic
protections.  The same is true for services like Tor bridges that
certain countries may try to enumerate and block.  Finally, if we use
port knocking to hide open ports, we need to guard against
man-in-the-middle attacks, as an adversary may permit and observe the
initial handshake and take over the TCP connection after the knocking
sequence has opened the path to the application.

Naturally, all of this should work with clients behind NAT, be hard to
observe using network analysis tools, and be easy to administer and
deploy.

Our patch does all of this.  TCP applications can activate knocking
using 'setsockopt' with a new TCP_STEALTH option. The knock is included
in the SQN field of the TCP SYN, making it indistinguishable from an
ordinary TCP handshake.  The knock can optionally include bits that
authenticate (!) the first packet of the TCP payload, thus preventing a
man-in-the-middle attack on the first bytes of the client's data stream.
A client sending its public key first and then continuing with encrypted
transmissions signed by that key can thus defeat devices that hijack
connections after the TCP handshake.

The patch is attached to this e-mail.  We've documented the method in
detail at https://gnunet.org/knock, including example client-server
applications and a detailed technical report (in PDF format).

Please let us know if we can do anything else to convince you to include
this patch, or to expedite its adaptation.


Happy hacking!

Maurice Leclair, Julian Kirsch & Christian Grothoff
knock@gnunet.org


Further details (from our website, for those prefering to read inline):


Background
==========

Today, port scanners can scan all IPv4 addresses in less than one hour.
Port knocking is a method for making TCP servers less visible on the
Internet. The basic idea is to make a TCP server not respond
(positively) to a TCP SYN request unless a particular "knock" packet has
been sent first. This can be helpful for security, as an attacker that
cannot establish a TCP connection also cannot really attack the TCP
server. There are a bunch of existing user-space tools, such as Knock
Knock and knockd. Most of these implementations send some other traffic
(such as a UDP packet) to the target host to have it (briefly) open the
server port. A particularly noteworthy recent idea in this domain is the
SilentKnock, which adds the idea of integrating the knock secret in the
initial TCP SYN packet in the SQN field, which is a technique borrowed
from network steganography.


Features of Knock
=================

* Knocking is stealthy: as in SilentKnock, the secret to open the port
is part of the TCP SYN packet's SQN, so there is not a single extra
packet on the wire (one Knock instead of KnockKnock). Thus, using Knock
is indistinguishable on the network from a standard TCP handshake.
Furthermore, as there is only one packet, there is no window of
opportunity for an attacker to use, as would be the case if a first
packet enables the server.
* Knocking is done in the Linux kernel. Applications can activate
Knock with a single additional setsockopt call (in both client and
server). Thus, once Linux has been patched, deployment will be much
simpler compared to other implementations. Also, as Knock operates in
the Kernel, timing attacks should be much harder to do.
* Our Knock optionally does not merely enable opening the connection,
but also can be used to protect the first N bytes of the TCP payload.
Thus, given a sane protocol being run above TCP (one begins with a key
exchange), an active attacker cannot simply take over the TCP connection
after the handshake without also being locked into sending the same TCP
payload. Thus, if the client begins by sending his public key and then
continues to send data that must be authenticated with that key, even an
active man-in-the-middle adversary cannot hijack the connection.
* Knock is designed to work with clients behind NAT. Only NAT
implementations that change the SQN are not supported (those should be
rare, but we have no hard data on this).
* The main disadvantage is that the SQN only has 32 bits, so a
brute-force attack can succeed against Knock. However, an attack
involving (on average) billions of packets is at least more likely to be
noticed. Not to mention that the adversary would still need to know
about the existence of the stealthy TCP server in the first place.
* Knock is free software and provided as a simple Kernel modification
(which should be easy to audit)


Further reading
===============

A 3-page PDF with the full details on Knock is available at
  https://gnunet.org/sites/default/files/knock.pdf

Toy example programs are attached to
  https://gnunet.org/knock as well.



Acknowledgements
================

Knock was designed and implemented by Julian Kirsch, Maurice Leclaire
and Christian Grothoff. We thank Jacob Appelbaum for constructive
discussions on an earlier version of the design.



More comments about the patch:
==============================

- The attached patch is against 3.12, but we also have one
  on the website against 3.10.
- All new code is #ifdef CONFIG_TCP_STEALTH



From: <knock@gnunet.org>


This patch adds three new TCP socket options to enable stealthy
TCP sockets using TCP SQN numbers derived from a shared secret.
The respective system calls store the information in new members
of the TCP socket struct.  If the SQN does not match expectations,
TCP SYN packets are rejected (RST).

New routines were added to check/compute the expected TCP
sequence number to accept connections to stealthy servers.
The expected sequence number is computed with MD5.

If integrity checking is enabled, the first bytes of
payload are hashed and checked against the payload as well.
If they do not match, the connection is dropped.

Signed-off-by: Christian Grothoff <christian@grothoff.org>
---
diff -urNp linux-3.12.4.old/include/linux/tcp.h
linux-3.12.4/include/linux/tcp.h
--- linux-3.12.4.old/include/linux/tcp.h	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/include/linux/tcp.h	2013-12-10 15:47:18.000082837 +0100
@@ -20,6 +20,7 @@

 #include <linux/skbuff.h>
 #include <linux/dmaengine.h>
+#include <linux/cryptohash.h>
 #include <net/sock.h>
 #include <net/inet_connection_sock.h>
 #include <net/inet_timewait_sock.h>
@@ -314,6 +315,19 @@ struct tcp_sock {
 	struct tcp_md5sig_info	__rcu *md5sig_info;
 #endif

+#ifdef CONFIG_TCP_STEALTH
+/* Stealth TCP socket configuration */
+	struct {
+		#define TCP_STEALTH_MODE_AUTH		BIT(0)
+		#define TCP_STEALTH_MODE_INTEGRITY	BIT(1)
+		#define TCP_STEALTH_MODE_INTEGRITY_LEN	BIT(2)
+		int mode;
+		u8 secret[MD5_MESSAGE_BYTES];
+		int integrity_len;
+		u16 integrity_hash;
+	} stealth;
+#endif
+
 /* TCP fastopen related information */
 	struct tcp_fastopen_request *fastopen_req;
 	/* fastopen_rsk points to request_sock that resulted in this big
diff -urNp linux-3.12.4.old/include/net/secure_seq.h
linux-3.12.4/include/net/secure_seq.h
--- linux-3.12.4.old/include/net/secure_seq.h	2013-12-08
17:18:58.000000000 +0100
+++ linux-3.12.4/include/net/secure_seq.h	2013-12-10 15:47:18.004082863
+0100
@@ -10,8 +10,12 @@ extern u32 secure_ipv6_port_ephemeral(co
 				      __be16 dport);
 extern __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
 					__be16 sport, __be16 dport);
+extern __u32 stealth_tcp_sequence_number(__be32 daddr, __be16 dport,
__u8 *secret,
+					 __u16 integrity);
 extern __u32 secure_tcpv6_sequence_number(const __be32 *saddr, const
__be32 *daddr,
 					  __be16 sport, __be16 dport);
+extern __u32 stealth_tcpv6_sequence_number(const __be32 *daddr, __be16
dport,
+					   __u8 *secret, __u16 integrity);
 extern u64 secure_dccp_sequence_number(__be32 saddr, __be32 daddr,
 				       __be16 sport, __be16 dport);
 extern u64 secure_dccpv6_sequence_number(__be32 *saddr, __be32 *daddr,
diff -urNp linux-3.12.4.old/include/net/tcp.h linux-3.12.4/include/net/tcp.h
--- linux-3.12.4.old/include/net/tcp.h	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/include/net/tcp.h	2013-12-10 15:47:18.012082891 +0100
@@ -448,6 +448,7 @@ extern void tcp_parse_options(const stru
 			      struct tcp_options_received *opt_rx,
 			      int estab, struct tcp_fastopen_cookie *foc);
 extern const u8 *tcp_parse_md5sig_option(const struct tcphdr *th);
+extern int tcp_stealth_integrity(u16 *hash, u8 *secret, u8 *payload,
int len);

 /*
  *	TCP v4 functions exported for the inet6 API
diff -urNp linux-3.12.4.old/include/uapi/linux/tcp.h
linux-3.12.4/include/uapi/linux/tcp.h
--- linux-3.12.4.old/include/uapi/linux/tcp.h	2013-12-08
17:18:58.000000000 +0100
+++ linux-3.12.4/include/uapi/linux/tcp.h	2013-12-10 15:51:19.417279938
+0100
@@ -112,6 +112,9 @@ enum {
 #define TCP_FASTOPEN		23	/* Enable FastOpen on listeners */
 #define TCP_TIMESTAMP		24
 #define TCP_NOTSENT_LOWAT	25	/* limit number of unsent bytes in write
queue */
+#define TCP_STEALTH		26
+#define TCP_STEALTH_INTEGRITY	27
+#define TCP_STEALTH_INTEGRITY_LEN	28

 struct tcp_repair_opt {
 	__u32	opt_code;
diff -urNp linux-3.12.4.old/net/core/secure_seq.c
linux-3.12.4/net/core/secure_seq.c
--- linux-3.12.4.old/net/core/secure_seq.c	2013-12-08 17:18:58.000000000
+0100
+++ linux-3.12.4/net/core/secure_seq.c	2013-12-10 15:47:18.028082976 +0100
@@ -72,6 +72,26 @@ __u32 secure_tcpv6_sequence_number(const
 }
 EXPORT_SYMBOL(secure_tcpv6_sequence_number);

+#ifdef CONFIG_TCP_STEALTH
+__u32 stealth_tcpv6_sequence_number(const __be32 *daddr, __be16 dport,
+				    __u8 *secret, __u16 integrity)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+	u32 sec[MD5_MESSAGE_BYTES / sizeof(u32)];
+	u32 i;
+
+	for (i = 0; i < MD5_DIGEST_WORDS; i++)
+		hash[i] = be32_to_cpu(daddr[i]);
+	hash[2] ^= (integrity << 16) | be16_to_cpu(dport);
+	for (i = 0; i < MD5_MESSAGE_BYTES / sizeof(u32); i++)
+		sec[i] = be32_to_cpu(((__be32 *)secret)[i]);
+
+	md5_transform(hash, sec);
+
+	return hash[0] ^ hash[1] ^ hash[2] ^ hash[3];
+}
+#endif
+
 u32 secure_ipv6_port_ephemeral(const __be32 *saddr, const __be32 *daddr,
 			       __be16 dport)
 {
@@ -137,6 +157,29 @@ __u32 secure_tcp_sequence_number(__be32
 	return seq_scale(hash[0]);
 }

+#ifdef CONFIG_TCP_STEALTH
+__u32 stealth_tcp_sequence_number(__be32 daddr, __be16 dport, __u8 *secret,
+				  __u16 integrity)
+{
+	u32 hash[MD5_DIGEST_WORDS];
+	u32 sec[MD5_MESSAGE_BYTES / sizeof(u32)];
+	u32 i;
+
+
+	hash[0] = be32_to_cpu(((__be32 *)secret)[10]);
+	hash[1] = be32_to_cpu(daddr);
+	hash[2] = (integrity << 16) | be16_to_cpu(dport);
+	hash[3] = be32_to_cpu(((__be32 *)secret)[15]);
+
+	for (i = 0; i < MD5_MESSAGE_BYTES / sizeof(u32); i++)
+		sec[i] = be32_to_cpu(((__be32 *)secret)[i]);
+
+	md5_transform(hash, sec);
+
+	return hash[0] ^ hash[1] ^ hash[2] ^ hash[3];
+}
+#endif
+
 u32 secure_ipv4_port_ephemeral(__be32 saddr, __be32 daddr, __be16 dport)
 {
 	u32 hash[MD5_DIGEST_WORDS];
diff -urNp linux-3.12.4.old/net/ipv4/Kconfig linux-3.12.4/net/ipv4/Kconfig
--- linux-3.12.4.old/net/ipv4/Kconfig	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/net/ipv4/Kconfig	2013-12-10 15:47:18.028082976 +0100
@@ -618,3 +618,13 @@ config TCP_MD5SIG
 	  on the Internet.

 	  If unsure, say N.
+
+config TCP_STEALTH
+	bool "TCP: Stealth TCP socket support"
+	default n
+	---help---
+	  This option enables support for stealth TCP sockets. If you do not
+	  know what this means, you do not need it.
+
+	  If unsure, say N.
+
diff -urNp linux-3.12.4.old/net/ipv4/tcp.c linux-3.12.4/net/ipv4/tcp.c
--- linux-3.12.4.old/net/ipv4/tcp.c	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/net/ipv4/tcp.c	2013-12-10 15:47:18.028082976 +0100
@@ -2380,6 +2380,43 @@ static int tcp_repair_options_est(struct
 	return 0;
 }

+#ifdef CONFIG_TCP_STEALTH
+int tcp_stealth_integrity(u16 *hash, u8 *secret, u8 *payload, int len)
+{
+	struct scatterlist sg[2];
+	struct crypto_hash *tfm;
+	struct hash_desc desc;
+	u16 h[MD5_DIGEST_WORDS * 2];
+	int i;
+	int err = 0;
+
+	tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
+	if (IS_ERR(tfm)) {
+		err = -PTR_ERR(tfm);
+		goto out;
+	}
+	desc.tfm = tfm;
+	desc.flags = 0;
+
+	sg_init_table(sg, 2);
+	sg_set_buf(&sg[0], secret, MD5_MESSAGE_BYTES);
+	sg_set_buf(&sg[1], payload, len);
+
+	if (crypto_hash_digest(&desc, sg, MD5_MESSAGE_BYTES + len, (u8 *)h)) {
+		err = -EFAULT;
+		goto out;
+	}
+
+	*hash = 0;
+	for (i = 0; i < MD5_DIGEST_WORDS * 2; i++)
+		*hash ^= h[i];
+
+out:
+	crypto_free_hash(tfm);
+	return err;
+}
+#endif
+
 /*
  *	Socket option code for TCP.
  */
@@ -2410,6 +2447,65 @@ static int do_tcp_setsockopt(struct sock
 		release_sock(sk);
 		return err;
 	}
+#ifdef CONFIG_TCP_STEALTH
+	case TCP_STEALTH: {
+		u8 secret[MD5_MESSAGE_BYTES];
+
+		if (optlen < MD5_MESSAGE_BYTES)
+			return -EINVAL;
+
+		val = copy_from_user(secret, optval, MD5_MESSAGE_BYTES);
+		if (val != 0)
+			return -EFAULT;
+
+		lock_sock(sk);
+		memcpy(tp->stealth.secret, secret, MD5_MESSAGE_BYTES);
+		tp->stealth.mode = TCP_STEALTH_MODE_AUTH;
+		release_sock(sk);
+		return err;
+	}
+	case TCP_STEALTH_INTEGRITY: {
+		u8 *payload;
+
+		lock_sock(sk);
+
+		if (!(tp->stealth.mode & TCP_STEALTH_MODE_AUTH)) {
+			err = -EOPNOTSUPP;
+			goto stealth_integrity_out_1;
+		}
+
+		if (optlen < 1 || optlen > USHRT_MAX) {
+			err = -EINVAL;
+			goto stealth_integrity_out_1;
+		}
+
+		payload = vmalloc(optlen);
+		if (!payload) {
+			err = -ENOMEM;
+			goto stealth_integrity_out_1;
+		}
+
+		val = copy_from_user(payload, optval, optlen);
+		if (val != 0) {
+			err = -EFAULT;
+			goto stealth_integrity_out_2;
+		}
+
+		err = tcp_stealth_integrity(&tp->stealth.integrity_hash,
+					    tp->stealth.secret, payload,
+					    optlen);
+		if (err)
+			goto stealth_integrity_out_2;
+
+		tp->stealth.mode |= TCP_STEALTH_MODE_INTEGRITY;
+
+stealth_integrity_out_2:
+		vfree(payload);
+stealth_integrity_out_1:
+		release_sock(sk);
+		return err;
+	}
+#endif
 	default:
 		/* fallthru */
 		break;
@@ -2651,6 +2747,18 @@ static int do_tcp_setsockopt(struct sock
 		tp->notsent_lowat = val;
 		sk->sk_write_space(sk);
 		break;
+#ifdef CONFIG_TCP_STEALTH
+	case TCP_STEALTH_INTEGRITY_LEN:
+		if (!(tp->stealth.mode & TCP_STEALTH_MODE_AUTH)) {
+			err = -EOPNOTSUPP;
+		} else if (val < 1 || val > USHRT_MAX) {
+			err = -EINVAL;
+		} else {
+			tp->stealth.integrity_len = val;
+			tp->stealth.mode |= TCP_STEALTH_MODE_INTEGRITY_LEN;
+		}
+		break;
+#endif
 	default:
 		err = -ENOPROTOOPT;
 		break;
diff -urNp linux-3.12.4.old/net/ipv4/tcp_input.c
linux-3.12.4/net/ipv4/tcp_input.c
--- linux-3.12.4.old/net/ipv4/tcp_input.c	2013-12-08 17:18:58.000000000
+0100
+++ linux-3.12.4/net/ipv4/tcp_input.c	2013-12-10 15:47:18.028082976 +0100
@@ -4293,6 +4293,31 @@ err:
 	return -ENOMEM;
 }

+#ifdef CONFIG_TCP_STEALTH
+static int tcp_stealth_integrity_check(struct sock *sk, struct sk_buff
*skb)
+{
+	struct tcphdr *th = tcp_hdr(skb);
+	struct tcp_sock *tp = tcp_sk(sk);
+	u16 hash;
+	u16 seq = TCP_SKB_CB(skb)->seq - 1;
+	char *data = skb->data + th->doff * 4;
+	int len = skb->len - th->doff * 4;
+
+	if (len < tp->stealth.integrity_len)
+		return 1;
+
+	if (tcp_stealth_integrity(&hash, tp->stealth.secret, data,
+				  tp->stealth.integrity_len))
+		return 1;
+
+	if (seq != hash)
+		return 1;
+
+	tp->stealth.mode &= ~TCP_STEALTH_MODE_INTEGRITY_LEN;
+	return 0;
+}
+#endif
+
 static void tcp_data_queue(struct sock *sk, struct sk_buff *skb)
 {
 	const struct tcphdr *th = tcp_hdr(skb);
@@ -4303,6 +4328,14 @@ static void tcp_data_queue(struct sock *
 	if (TCP_SKB_CB(skb)->seq == TCP_SKB_CB(skb)->end_seq)
 		goto drop;

+#ifdef CONFIG_TCP_STEALTH
+	if (unlikely(tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY_LEN) &&
+	    tcp_stealth_integrity_check(sk, skb)) {
+		tcp_reset(sk);
+		goto drop;
+	}
+#endif
+
 	skb_dst_drop(skb);
 	__skb_pull(skb, th->doff * 4);

@@ -5157,6 +5190,15 @@ void tcp_rcv_established(struct sock *sk
 			int copied_early = 0;
 			bool fragstolen = false;

+#ifdef CONFIG_TCP_STEALTH
+			if (unlikely(tp->stealth.mode &
+				     TCP_STEALTH_MODE_INTEGRITY_LEN) &&
+			    tcp_stealth_integrity_check(sk, skb)) {
+				tcp_reset(sk);
+				goto discard;
+			}
+#endif
+
 			if (tp->copied_seq == tp->rcv_nxt &&
 			    len - tcp_header_len <= tp->ucopy.len) {
 #ifdef CONFIG_NET_DMA
diff -urNp linux-3.12.4.old/net/ipv4/tcp_ipv4.c
linux-3.12.4/net/ipv4/tcp_ipv4.c
--- linux-3.12.4.old/net/ipv4/tcp_ipv4.c	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/net/ipv4/tcp_ipv4.c	2013-12-10 15:47:18.028082976 +0100
@@ -235,6 +235,20 @@ int tcp_v4_connect(struct sock *sk, stru
 	sk->sk_gso_type = SKB_GSO_TCPV4;
 	sk_setup_caps(sk, &rt->dst);

+#ifdef CONFIG_TCP_STEALTH
+	if (!tp->write_seq && likely(!tp->repair) &&
+ 	    unlikely(tp->stealth.mode & TCP_STEALTH_MODE_AUTH)) {
+		tp->write_seq = stealth_tcp_sequence_number(inet->inet_daddr,
+							    usin->sin_port,
+							    tp->stealth.secret,
+							    tp->stealth.integrity_hash);
+		if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY) {
+			tp->write_seq &= (BIT(16) - 1) << 16;
+			tp->write_seq |= tp->stealth.integrity_hash;
+		}
+	}
+#endif
+
 	if (!tp->write_seq && likely(!tp->repair))
 		tp->write_seq = secure_tcp_sequence_number(inet->inet_saddr,
 							   inet->inet_daddr,
@@ -1776,6 +1790,8 @@ static __sum16 tcp_v4_checksum_init(stru
  */
 int tcp_v4_do_rcv(struct sock *sk, struct sk_buff *skb)
 {
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcphdr *th = tcp_hdr(skb);
 	struct sock *rsk;
 #ifdef CONFIG_TCP_MD5SIG
 	/*
@@ -1806,6 +1822,32 @@ int tcp_v4_do_rcv(struct sock *sk, struc
 	if (skb->len < tcp_hdrlen(skb) || tcp_checksum_complete(skb))
 		goto csum_err;

+#ifdef CONFIG_TCP_STEALTH
+	if (sk->sk_state == TCP_LISTEN && th->syn && !th->fin &&
+	    unlikely(tp->stealth.mode & TCP_STEALTH_MODE_AUTH)) {
+		u32 hash;
+		u32 seq = be32_to_cpu(th->seq);
+		if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY_LEN)
+			tp->stealth.integrity_hash = seq;
+		hash = stealth_tcp_sequence_number(ip_hdr(skb)->daddr,
+						   th->dest,
+						   tp->stealth.secret,
+						   tp->stealth.integrity_hash);
+		if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY_LEN) {
+			if ((seq & ((BIT(16) - 1) << 16)) !=
+			    (hash & ((BIT(16) - 1) << 16))) {
+				rsk = sk;
+				goto reset;
+			}
+		} else {
+			if (seq != hash) {
+				rsk = sk;
+				goto reset;
+			}
+		}
+	}
+#endif
+
 	if (sk->sk_state == TCP_LISTEN) {
 		struct sock *nsk = tcp_v4_hnd_req(sk, skb);
 		if (!nsk)
diff -urNp linux-3.12.4.old/net/ipv6/tcp_ipv6.c
linux-3.12.4/net/ipv6/tcp_ipv6.c
--- linux-3.12.4.old/net/ipv6/tcp_ipv6.c	2013-12-08 17:18:58.000000000 +0100
+++ linux-3.12.4/net/ipv6/tcp_ipv6.c	2013-12-10 15:47:18.032082996 +0100
@@ -296,6 +296,20 @@ static int tcp_v6_connect(struct sock *s
 	if (err)
 		goto late_failure;

+#ifdef CONFIG_TCP_STEALTH
+	if (!tp->write_seq && likely(!tp->repair) &&
+	    unlikely(tp->stealth.mode & TCP_STEALTH_MODE_AUTH)) {
+		tp->write_seq = stealth_tcpv6_sequence_number(np->daddr.s6_addr32,
+							      inet->inet_dport,
+							      tp->stealth.secret,
+							      tp->stealth.integrity_hash);
+		if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY) {
+			tp->write_seq &= (BIT(16) - 1) << 16;
+			tp->write_seq |= tp->stealth.integrity_hash;
+		}
+	}
+#endif
+
 	if (!tp->write_seq && likely(!tp->repair))
 		tp->write_seq = secure_tcpv6_sequence_number(np->saddr.s6_addr32,
 							     np->daddr.s6_addr32,
@@ -1305,7 +1319,8 @@ static __sum16 tcp_v6_checksum_init(stru
 static int tcp_v6_do_rcv(struct sock *sk, struct sk_buff *skb)
 {
 	struct ipv6_pinfo *np = inet6_sk(sk);
-	struct tcp_sock *tp;
+	struct tcp_sock *tp = tcp_sk(sk);
+	struct tcphdr *th = tcp_hdr(skb);
 	struct sk_buff *opt_skb = NULL;

 	/* Imagine: socket is IPv6. IPv4 packet arrives,
@@ -1369,6 +1384,29 @@ static int tcp_v6_do_rcv(struct sock *sk
 	if (skb->len < tcp_hdrlen(skb) || tcp_checksum_complete(skb))
 		goto csum_err;

+#ifdef CONFIG_TCP_STEALTH
+	if (sk->sk_state == TCP_LISTEN && th->syn && !th->fin &&
+	    tp->stealth.mode & TCP_STEALTH_MODE_AUTH) {
+		u32 hash;
+		u32 seq = be32_to_cpu(th->seq);
+		if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY_LEN)
+			tp->stealth.integrity_hash = seq;
+		hash = stealth_tcpv6_sequence_number(ipv6_hdr(skb)->
+						     daddr.s6_addr32,
+						     th->dest,
+						     tp->stealth.secret,
+						     tp->stealth.integrity_hash);
+	    	if (tp->stealth.mode & TCP_STEALTH_MODE_INTEGRITY_LEN) {
+			if ((seq & ((BIT(16) - 1) << 16)) !=
+			    (hash & ((BIT(16) - 1) << 16)))
+				goto reset;
+		} else {
+			if (seq != hash)
+				goto reset;
+		}
+	}
+#endif
+
 	if (sk->sk_state == TCP_LISTEN) {
 		struct sock *nsk = tcp_v6_hnd_req(sk, skb);
 		if (!nsk)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-10 18:35 [PATCH] TCP: add option for silent port knocking with integrity protection Christian Grothoff
@ 2013-12-11 20:01 ` David Miller
  2013-12-11 20:19   ` Christian Grothoff
  0 siblings, 1 reply; 22+ messages in thread
From: David Miller @ 2013-12-11 20:01 UTC (permalink / raw)
  To: grothoff; +Cc: netdev, linux-kernel, knock, jacob

From: Christian Grothoff <grothoff@in.tum.de>
Date: Tue, 10 Dec 2013 19:35:36 +0100

> Only NAT implementations that change the SQN are not supported
> (those should be rare, but we have no hard data on this).

Even Linux's netfilter can and does do this, it is absolutely necessary
for tracking SIP and FTP protocols, and it's also used in our virtual
server load balancing modules.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 20:01 ` David Miller
@ 2013-12-11 20:19   ` Christian Grothoff
  2013-12-11 20:26     ` Stephen Hemminger
  0 siblings, 1 reply; 22+ messages in thread
From: Christian Grothoff @ 2013-12-11 20:19 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, linux-kernel, knock, jacob

On 12/11/2013 09:01 PM, David Miller wrote:
> From: Christian Grothoff <grothoff@in.tum.de>
> Date: Tue, 10 Dec 2013 19:35:36 +0100
> 
>> Only NAT implementations that change the SQN are not supported
>> (those should be rare, but we have no hard data on this).
> 
> Even Linux's netfilter can and does do this, it is absolutely necessary
> for tracking SIP and FTP protocols, and it's also used in our virtual
> server load balancing modules.
> 

We're aware that Linux _can_ do this.  I was not aware it was doing this
for
SIP and FTP specifically; regardless, what implementations can do is less
important than what they are configured to do most of the time, and that's
what we'd need hard data on.  Anyway, I'd be very interested to learn how
you use this for SIP/FTP to evaluate the impact.  Do you have documentation
on this?

As for server load balancing, I suspect that those are not the kinds of
services that one would typically use port knocking for.  Still, again a
good hint as to where trouble might lurk (and we will definitively include
those points in the next revision of the documentation).

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 20:19   ` Christian Grothoff
@ 2013-12-11 20:26     ` Stephen Hemminger
  2013-12-11 20:39       ` Christian Grothoff
  2013-12-11 21:25       ` Andi Kleen
  0 siblings, 2 replies; 22+ messages in thread
From: Stephen Hemminger @ 2013-12-11 20:26 UTC (permalink / raw)
  To: Christian Grothoff; +Cc: David Miller, netdev, linux-kernel, knock, jacob

On Wed, 11 Dec 2013 21:19:00 +0100
Christian Grothoff <grothoff@in.tum.de> wrote:

> On 12/11/2013 09:01 PM, David Miller wrote:
> > From: Christian Grothoff <grothoff@in.tum.de>
> > Date: Tue, 10 Dec 2013 19:35:36 +0100
> > 
> >> Only NAT implementations that change the SQN are not supported
> >> (those should be rare, but we have no hard data on this).
> > 
> > Even Linux's netfilter can and does do this, it is absolutely necessary
> > for tracking SIP and FTP protocols, and it's also used in our virtual
> > server load balancing modules.
> > 
> 
> We're aware that Linux _can_ do this.  I was not aware it was doing this
> for
> SIP and FTP specifically; regardless, what implementations can do is less
> important than what they are configured to do most of the time, and that's
> what we'd need hard data on.  Anyway, I'd be very interested to learn how
> you use this for SIP/FTP to evaluate the impact.  Do you have documentation
> on this?
> 
> As for server load balancing, I suspect that those are not the kinds of
> services that one would typically use port knocking for.  Still, again a
> good hint as to where trouble might lurk (and we will definitively include
> those points in the next revision of the documentation).

The point is that doing it outside of TCP core is safer, less error prone
and more flexible.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 20:26     ` Stephen Hemminger
@ 2013-12-11 20:39       ` Christian Grothoff
  2013-12-11 21:25       ` Andi Kleen
  1 sibling, 0 replies; 22+ messages in thread
From: Christian Grothoff @ 2013-12-11 20:39 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, netdev, linux-kernel, knock, jacob

On 12/11/2013 09:26 PM, Stephen Hemminger wrote:
> On Wed, 11 Dec 2013 21:19:00 +0100
> Christian Grothoff <grothoff@in.tum.de> wrote:
> 
>> On 12/11/2013 09:01 PM, David Miller wrote:
>>> From: Christian Grothoff <grothoff@in.tum.de>
>>> Date: Tue, 10 Dec 2013 19:35:36 +0100
>>>
>>>> Only NAT implementations that change the SQN are not supported
>>>> (those should be rare, but we have no hard data on this).
>>>
>>> Even Linux's netfilter can and does do this, it is absolutely necessary
>>> for tracking SIP and FTP protocols, and it's also used in our virtual
>>> server load balancing modules.
>>>
>>
>> We're aware that Linux _can_ do this.  I was not aware it was doing this
>> for
>> SIP and FTP specifically; regardless, what implementations can do is less
>> important than what they are configured to do most of the time, and that's
>> what we'd need hard data on.  Anyway, I'd be very interested to learn how
>> you use this for SIP/FTP to evaluate the impact.  Do you have documentation
>> on this?
>>
>> As for server load balancing, I suspect that those are not the kinds of
>> services that one would typically use port knocking for.  Still, again a
>> good hint as to where trouble might lurk (and we will definitively include
>> those points in the next revision of the documentation).
> 
> The point is that doing it outside of TCP core is safer, less error prone
> and more flexible.
> 

I'm not sure how you drew that conclusion from what I or David said.
Outside of TCP core doesn't fix the NAT issues at all, having a
dozen user-space implementations with configuration quirks doesn't
really sound less error prone to me, and finally I do not even see
a reasonably sane way of doing the TCP payload authentication in
userspace (even writing a process that relays data won't work, as
then you'd loose the source address for the server process).  So
I'd go as far as saying that some of what we do cannot really be
done in userspace.  Now, maybe you mean something other than
"userspace" with "outside of TCP core", in which case I again totally
fail to relate this to what was said here before.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 20:26     ` Stephen Hemminger
  2013-12-11 20:39       ` Christian Grothoff
@ 2013-12-11 21:25       ` Andi Kleen
  2013-12-11 22:53         ` Christian Grothoff
  1 sibling, 1 reply; 22+ messages in thread
From: Andi Kleen @ 2013-12-11 21:25 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Christian Grothoff, David Miller, netdev, linux-kernel, knock, jacob

Stephen Hemminger <stephen@networkplumber.org> writes:
>
> The point is that doing it outside of TCP core is safer, less error prone
> and more flexible.

Or to put the question differently: what hooks would be needed to make
this efficiently work in user space?

It could be something like this: Firewall the port with forwarding the 
SYN packets using nfqueue, check for the SYN having the right magic,
change a firewall rule, re-inject using nfqueue (not fully sure how
well that works)

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 21:25       ` Andi Kleen
@ 2013-12-11 22:53         ` Christian Grothoff
  2013-12-12  1:23           ` Andi Kleen
  0 siblings, 1 reply; 22+ messages in thread
From: Christian Grothoff @ 2013-12-11 22:53 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Stephen Hemminger, David Miller, netdev, linux-kernel, knock, jacob

On 12/11/2013 10:25 PM, Andi Kleen wrote:
> Stephen Hemminger <stephen@networkplumber.org> writes:
>>
>> The point is that doing it outside of TCP core is safer, less error prone
>> and more flexible.
> 
> Or to put the question differently: what hooks would be needed to make
> this efficiently work in user space?
> 
> It could be something like this: Firewall the port with forwarding the 
> SYN packets using nfqueue, check for the SYN having the right magic,
> change a firewall rule, re-inject using nfqueue (not fully sure how
> well that works)

... and then do the same for the first TCP packet with payload? And you
seriously would consider that "safer" or "less error prone", starting
with the design complexity?  I mean, if this was a patch for GNU Hurd,
I'd at least understand the strong urge to do everything in userspace...

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-11 22:53         ` Christian Grothoff
@ 2013-12-12  1:23           ` Andi Kleen
  2013-12-12 10:19             ` Jacob Appelbaum
  0 siblings, 1 reply; 22+ messages in thread
From: Andi Kleen @ 2013-12-12  1:23 UTC (permalink / raw)
  To: Christian Grothoff
  Cc: Andi Kleen, Stephen Hemminger, David Miller, netdev,
	linux-kernel, knock, jacob

> ... and then do the same for the first TCP packet with payload? And you

That gets passed through by the firewall rule.

> seriously would consider that "safer" or "less error prone", starting

Yes the risk of adding exploitable holes to the kernel is signficantly
lower.

-Andi

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12  1:23           ` Andi Kleen
@ 2013-12-12 10:19             ` Jacob Appelbaum
  2013-12-12 11:43               ` Christian Grothoff
  0 siblings, 1 reply; 22+ messages in thread
From: Jacob Appelbaum @ 2013-12-12 10:19 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Christian Grothoff, Stephen Hemminger, David Miller, netdev,
	linux-kernel, knock

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 10:19             ` Jacob Appelbaum
@ 2013-12-12 11:43               ` Christian Grothoff
  2013-12-12 12:23                 ` Jacob Appelbaum
  2013-12-12 14:34                 ` Eric Dumazet
  0 siblings, 2 replies; 22+ messages in thread
From: Christian Grothoff @ 2013-12-12 11:43 UTC (permalink / raw)
  To: Jacob Appelbaum
  Cc: Andi Kleen, Stephen Hemminger, David Miller, netdev, linux-kernel, knock


[-- Attachment #1.1: Type: text/plain, Size: 1208 bytes --]

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.

-Christian

[-- Attachment #1.2: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 8705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 11:43               ` Christian Grothoff
@ 2013-12-12 12:23                 ` Jacob Appelbaum
  2013-12-12 14:34                 ` Eric Dumazet
  1 sibling, 0 replies; 22+ messages in thread
From: Jacob Appelbaum @ 2013-12-12 12:23 UTC (permalink / raw)
  To: Christian Grothoff
  Cc: Andi Kleen, Stephen Hemminger, David Miller, netdev, linux-kernel, knock

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

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 11:43               ` Christian Grothoff
  2013-12-12 12:23                 ` Jacob Appelbaum
@ 2013-12-12 14:34                 ` Eric Dumazet
  2013-12-12 15:07                   ` Christian Grothoff
                                     ` (2 more replies)
  1 sibling, 3 replies; 22+ messages in thread
From: Eric Dumazet @ 2013-12-12 14:34 UTC (permalink / raw)
  To: Christian Grothoff
  Cc: Jacob Appelbaum, Andi Kleen, Stephen Hemminger, David Miller,
	netdev, linux-kernel, knock

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



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 14:34                 ` Eric Dumazet
@ 2013-12-12 15:07                   ` Christian Grothoff
  2013-12-12 15:33                     ` Eric Dumazet
  2013-12-12 15:46                   ` Hannes Frederic Sowa
  2014-08-19 19:36                   ` Alexander Holler
  2 siblings, 1 reply; 22+ messages in thread
From: Christian Grothoff @ 2013-12-12 15:07 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Jacob Appelbaum, Andi Kleen, Stephen Hemminger, David Miller,
	netdev, linux-kernel, knock


[-- Attachment #1.1: Type: text/plain, Size: 5261 bytes --]

On 12/12/2013 03:34 PM, Eric Dumazet wrote:
> 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 ?

By doing another setsockopt() on the listen socket, which doesn't affect
existing connections.

> How having a constant initial sequence number can even be valid?

(1) technically, a constant ISN is 'valid', it is just not a good idea
    for various reasons which I suspect we don't need to discuss here.
(2) however, our ISNs are not necessarily constant, as
    (a) clients/servers may change the secret (see above), for example
        SilentKnock suggested using one-time secrets; our implementation
        does not preclude this;
    (b) alternatively, the scheme optionally includes TCP payload in
        what is being hashed; assuming a sane TCP protocol is used
	where the payload is reasonably random, this will result in
	a reasonably random ISN

Still, your concern that ISNs may not be sufficiently random for certain
applications using a global secret and no payload protection is valid.
There is an easy fix if TCP timestamps are available (throw the
timestamp into the MD5 hash operation), but we did not implement this
(yet). However, this might be a good idea.

> What about TCP timestamps being not available at all?

We're currently not using TCP timestamps; if we assumed that they were
always available, we would be able to better address your ISN issue
above, even for applications that use no payload protection and do not
change the secret.  That should be a minor modification to the existing
patch, but I read your point as you not wanting to use timestamps.

> How typical servers can be behind a load balancer?
> Or am I missing something?

I already agreed earlier that setups using a DNAT that changes SQNs for
load balancing won't work with this (and this is now documented on the
website).  Note that the patch requires the server to explicitly enable
this option, so in setups where it fundamentally doesn't work, the
simple answer is to not use it and the patch will do no harm.

Also, I'm not aware of any Tor bridges or GNUnet peers behind a load
balancer. The only SSH servers that are behind a load balancer that I'm
aware of are for HPC systems, and those have stronger protections from
Internet visibility than what Knock would possibly offer.  So the
use-cases I had in mind are not affected by the DNAT limitation.

> 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.)

Sounds much like the GNU Hurd to me, which is a nice design. Still, I'm
not sure this (relatively tiny) patch really warrants moving TCP into
user land.

> 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 ?

I'm not sure I see the relationship to TCP fast open.

> 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.

I'm already having fun with IETF and pTLDs right now, one war at a time
;-).  I also figured it might be easier to have a reasonable working
reference implementation first and then standardize.  After all, with my
recent draft some people at IETF suggested I should get 1,000,000+ users
first and then ask again.

Happy hacking!

-Christian


[-- Attachment #1.2: 0x48426C7E.asc --]
[-- Type: application/pgp-keys, Size: 8705 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 15:07                   ` Christian Grothoff
@ 2013-12-12 15:33                     ` Eric Dumazet
  0 siblings, 0 replies; 22+ messages in thread
From: Eric Dumazet @ 2013-12-12 15:33 UTC (permalink / raw)
  To: Christian Grothoff
  Cc: Jacob Appelbaum, Andi Kleen, Stephen Hemminger, David Miller,
	netdev, linux-kernel, knock

On Thu, 2013-12-12 at 16:07 +0100, Christian Grothoff wrote:

> I'm already having fun with IETF and pTLDs right now, one war at a time
> ;-).  I also figured it might be easier to have a reasonable working
> reference implementation first and then standardize.  After all, with my
> recent draft some people at IETF suggested I should get 1,000,000+ users
> first and then ask again.

Honestly, breaking the detection of old packets (PAWS) is not going to
fly. Its not even mentioned in your doc.

If a client uses the same ISN for two consecutive connexions to a
server, how the server can decide the 2nd SYN is not a duplicate ?

You really need more than 3 pages to fully investigate all the pros/cons
of this idea.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 14:34                 ` Eric Dumazet
  2013-12-12 15:07                   ` Christian Grothoff
@ 2013-12-12 15:46                   ` Hannes Frederic Sowa
  2013-12-13  3:07                     ` Hannes Frederic Sowa
  2014-08-19 19:36                   ` Alexander Holler
  2 siblings, 1 reply; 22+ messages in thread
From: Hannes Frederic Sowa @ 2013-12-12 15:46 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

On Thu, Dec 12, 2013 at 06:34:24AM -0800, Eric Dumazet wrote:
> 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.)

Maybe this knocking scheme is implementable with a socket filter and we could
add a switch to tweak drop behaviour.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 15:46                   ` Hannes Frederic Sowa
@ 2013-12-13  3:07                     ` Hannes Frederic Sowa
  0 siblings, 0 replies; 22+ messages in thread
From: Hannes Frederic Sowa @ 2013-12-13  3:07 UTC (permalink / raw)
  To: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

On Thu, Dec 12, 2013 at 04:46:37PM +0100, Hannes Frederic Sowa wrote:
> On Thu, Dec 12, 2013 at 06:34:24AM -0800, Eric Dumazet wrote:
> > 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.)
> 
> Maybe this knocking scheme is implementable with a socket filter and we could
> add a switch to tweak drop behaviour.

Just fyi, maybe it is useful. I haven't tested it:

For the sending side one could craft the handshake by hand (raw/packet
sockets) and splice in an already established socket via tcp connection
repair.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2013-12-12 14:34                 ` Eric Dumazet
  2013-12-12 15:07                   ` Christian Grothoff
  2013-12-12 15:46                   ` Hannes Frederic Sowa
@ 2014-08-19 19:36                   ` Alexander Holler
  2014-08-20  8:24                     ` Hagen Paul Pfeifer
  2 siblings, 1 reply; 22+ messages in thread
From: Alexander Holler @ 2014-08-19 19:36 UTC (permalink / raw)
  To: Eric Dumazet, Christian Grothoff
  Cc: Jacob Appelbaum, Andi Kleen, Stephen Hemminger, David Miller,
	netdev, linux-kernel, knock

Am 12.12.2013 15:34, schrieb Eric Dumazet:

A bit late, but I've just stumbled over that feature which I do like a lot.

> 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 ?

Impossible because you already need a channel if you want to identify 
the client. But that isn't the intention of the patch. You still have 
the usual authentication stuff in the service you want to hide. It's 
about hiding (from someone outside a closed group) the possibility to 
authenticate.

> 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 ?

It doesn't have to work in every environment and it doesn't have to 
solve all existing problems in the world. ;)

But it enables people to protect a bit more against malicious people or 
governments.

And it is really very easy to use. It took me around half an hour to 
find the places in openvpn and openssh where I had to add the 
setsockopt() call and it can be used even easier with preloading 
libknockify.so.

There can be found much more useless options in the kernel. At least I 
like it and it fits my needs too.

Regards,

Alexander Holler

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2014-08-19 19:36                   ` Alexander Holler
@ 2014-08-20  8:24                     ` Hagen Paul Pfeifer
  2014-08-20  9:07                       ` Alexander Holler
  0 siblings, 1 reply; 22+ messages in thread
From: Hagen Paul Pfeifer @ 2014-08-20  8:24 UTC (permalink / raw)
  To: Alexander Holler
  Cc: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

On 19 August 2014 21:36, Alexander Holler <holler@ahsoftware.de> wrote:

> It doesn't have to work in every environment and it doesn't have to solve
> all existing problems in the world. ;)
>
> But it enables people to protect a bit more against malicious people or
> governments.
>
> And it is really very easy to use. It took me around half an hour to find
> the places in openvpn and openssh where I had to add the setsockopt() call
> and it can be used even easier with preloading libknockify.so.
>
> There can be found much more useless options in the kernel. At least I like
> it and it fits my needs too.

It's not about to add another "useless options", it's about changing
the major transport protocol. You should probably join the IETF
tcpm/tcpinc mailing list where TCP stealth is currently actively
discussed. TCP stealth has problems and you can probably help to
address them on a *technical level* if you like the mechanism.

Hagen

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2014-08-20  8:24                     ` Hagen Paul Pfeifer
@ 2014-08-20  9:07                       ` Alexander Holler
  2014-08-20  9:28                         ` Hagen Paul Pfeifer
  0 siblings, 1 reply; 22+ messages in thread
From: Alexander Holler @ 2014-08-20  9:07 UTC (permalink / raw)
  To: Hagen Paul Pfeifer
  Cc: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

Am 20.08.2014 10:24, schrieb Hagen Paul Pfeifer:
> On 19 August 2014 21:36, Alexander Holler <holler@ahsoftware.de> wrote:
>
>> It doesn't have to work in every environment and it doesn't have to solve
>> all existing problems in the world. ;)
>>
>> But it enables people to protect a bit more against malicious people or
>> governments.
>>
>> And it is really very easy to use. It took me around half an hour to find
>> the places in openvpn and openssh where I had to add the setsockopt() call
>> and it can be used even easier with preloading libknockify.so.
>>
>> There can be found much more useless options in the kernel. At least I like
>> it and it fits my needs too.
>
> It's not about to add another "useless options", it's about changing
> the major transport protocol. You should probably join the IETF
> tcpm/tcpinc mailing list where TCP stealth is currently actively
> discussed. TCP stealth has problems and you can probably help to
> address them on a *technical level* if you like the mechanism.

As written above, it doesn't have to be perfect and it doesn't have to 
work in every environment.

And I didn't say it is useless. At least that was not my intention (I'm 
no native english speaker). In fact I find it very useful. Such useful 
that I would like it to be already  included in the kernel. It doesn't 
do any harm if disabled, besides a few more lines of (unused) source 
code. Thats why I've written my mail (to support inclusion).

For sure it could be better, but I'm already happy with the current 
imperfect solution which I can use now and not some perfect solution 
which might be available in some years.

Regards,

Alexander Holler

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2014-08-20  9:07                       ` Alexander Holler
@ 2014-08-20  9:28                         ` Hagen Paul Pfeifer
  2014-08-20  9:47                           ` Alexander Holler
  0 siblings, 1 reply; 22+ messages in thread
From: Hagen Paul Pfeifer @ 2014-08-20  9:28 UTC (permalink / raw)
  To: Alexander Holler
  Cc: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

On 20 August 2014 11:07, Alexander Holler <holler@ahsoftware.de> wrote:

> For sure it could be better, but I'm already happy with the current
> imperfect solution which I can use now and not some perfect solution which
> might be available in some years.

Alexander, to make it clear: we cannot include mechanisms which
probably open other (security) issues. This is not how things work
out. TCP had so many issues in the past - regarding security,
implementation f*ups, etc. pp. It is utterly important that there is
no problem with an extension. Please join the discussion ob tcpm if
you will drive things forward. That's all what I can say - sorry!

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2014-08-20  9:28                         ` Hagen Paul Pfeifer
@ 2014-08-20  9:47                           ` Alexander Holler
  2014-08-20 10:20                             ` Alexander Holler
  0 siblings, 1 reply; 22+ messages in thread
From: Alexander Holler @ 2014-08-20  9:47 UTC (permalink / raw)
  To: Hagen Paul Pfeifer
  Cc: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
> On 20 August 2014 11:07, Alexander Holler <holler@ahsoftware.de> wrote:
>
>> For sure it could be better, but I'm already happy with the current
>> imperfect solution which I can use now and not some perfect solution which
>> might be available in some years.
>
> Alexander, to make it clear: we cannot include mechanisms which
> probably open other (security) issues. This is not how things work
> out. TCP had so many issues in the past - regarding security,
> implementation f*ups, etc. pp. It is utterly important that there is
> no problem with an extension. Please join the discussion ob tcpm if
> you will drive things forward. That's all what I can say - sorry!

Maybe I first should send a million syn-packets to a box where I've 
enabled that feature. ;)

Anyway, I still think there should be some room for experimental 
features in the kernel. It makes them more visible to possible 
contributors and helps to drive further development.

Not necessarily in my case (as most people, I can't and don't want to 
participate in all parties), but ...

Regards,

Alexander Holler

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [PATCH] TCP: add option for silent port knocking with integrity protection
  2014-08-20  9:47                           ` Alexander Holler
@ 2014-08-20 10:20                             ` Alexander Holler
  0 siblings, 0 replies; 22+ messages in thread
From: Alexander Holler @ 2014-08-20 10:20 UTC (permalink / raw)
  To: Hagen Paul Pfeifer
  Cc: Eric Dumazet, Christian Grothoff, Jacob Appelbaum, Andi Kleen,
	Stephen Hemminger, David Miller, netdev, linux-kernel, knock

Am 20.08.2014 11:47, schrieb Alexander Holler:
> Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
>> On 20 August 2014 11:07, Alexander Holler <holler@ahsoftware.de> wrote:
>>
>>> For sure it could be better, but I'm already happy with the current
>>> imperfect solution which I can use now and not some perfect solution
>>> which
>>> might be available in some years.
>>
>> Alexander, to make it clear: we cannot include mechanisms which
>> probably open other (security) issues. This is not how things work
>> out. TCP had so many issues in the past - regarding security,
>> implementation f*ups, etc. pp. It is utterly important that there is
>> no problem with an extension. Please join the discussion ob tcpm if
>> you will drive things forward. That's all what I can say - sorry!
>
> Maybe I first should send a million syn-packets to a box where I've
> enabled that feature. ;)
>
> Anyway, I still think there should be some room for experimental
> features in the kernel. It makes them more visible to possible
> contributors and helps to drive further development.
>
> Not necessarily in my case (as most people, I can't and don't want to
> participate in all parties), but ...

And as I've just read the archives of tcpm, I don't think it would help. 
Jacob Appelbaum already expressed everything I like to use this feature 
for, so most of the time I just had to send a +1 to Jacobs comments, 
which would be somewhat annoying. ;)

Regards,

Alexander Holler



^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2014-08-20 10:21 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-10 18:35 [PATCH] TCP: add option for silent port knocking with integrity protection Christian Grothoff
2013-12-11 20:01 ` David Miller
2013-12-11 20:19   ` Christian Grothoff
2013-12-11 20:26     ` Stephen Hemminger
2013-12-11 20:39       ` Christian Grothoff
2013-12-11 21:25       ` Andi Kleen
2013-12-11 22:53         ` Christian Grothoff
2013-12-12  1:23           ` Andi Kleen
2013-12-12 10:19             ` Jacob Appelbaum
2013-12-12 11:43               ` Christian Grothoff
2013-12-12 12:23                 ` Jacob Appelbaum
2013-12-12 14:34                 ` Eric Dumazet
2013-12-12 15:07                   ` Christian Grothoff
2013-12-12 15:33                     ` Eric Dumazet
2013-12-12 15:46                   ` Hannes Frederic Sowa
2013-12-13  3:07                     ` Hannes Frederic Sowa
2014-08-19 19:36                   ` Alexander Holler
2014-08-20  8:24                     ` Hagen Paul Pfeifer
2014-08-20  9:07                       ` Alexander Holler
2014-08-20  9:28                         ` Hagen Paul Pfeifer
2014-08-20  9:47                           ` Alexander Holler
2014-08-20 10:20                             ` Alexander Holler

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.