Subject: [tcpinc] TCP Stealth - possible interest to the WG

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 15 Aug 2014 23:51:47 +0000

Hi,

I just learned about an individual submission, which is probably of interest not only to the members of these two WGs;

http://tools.ietf.org/html/draft-kirsch-ietf-tcp-stealth-00

On a first, casual glance, I am wondering if the authors have realized all the implications of their suggestion;

There seem to be at least two or three major issues that compromise either the working and stability of TCP, or work against the intended "stealthieness" of this modification (making it easy for an attacker to identify such sessions, provided he is able to actively interfere with segments in transit (ie. cause certain segments to be dropped).

Nevertheless, it might be beneficial to discuss the generic idea in a wider forum, among brighter minds than me.

Richard Scheffenegger

---

From: Jacob Appelbaum <[email-masked]>
Date: Mon, 18 Aug 2014 12:50:12 +0000

On 8/15/14, Scheffenegger, Richard <[email-masked]> wrote:
> Hi,
>
> I just learned about an individual submission, which is probably of interest
> not only to the members of these two WGs;
>

Hi,

I'm one of the authors of the draft and I've cc'ed Christian who has
been one of the driving forces behind the draft.

> the implications of their suggestion;

This article we wrote may be of interest to you:

http://www.heise.de/ct/artikel/NSA-GCHQ-The-HACIENDA-Program-for-Internet-Colonization-2292681.html
(English)
http://www.heise.de/ct/artikel/NSA-GCHQ-Das-HACIENDA-Programm-zur-Kolonisierung-des-Internet-2292574.html
(German)

> There seem to be at least two or three major issues that compromise either
> the working and stability of TCP, or work against the intended
> "stealthieness" of this modification (making it easy for an attacker to
> identify such sessions, provided he is able to actively interfere with
> segments in transit (ie. cause certain segments to be dropped).

Could you expand on these thoughts a bit?

> forum, among brighter minds than me.

Thanks for bringing it up!

All the best,
Jacob

---

From: Alfie John <[email-masked]>
Date: Mon, 18 Aug 2014 23:34:35 +0200

On Mon, Aug 18, 2014, at 02:50 PM, Jacob Appelbaum wrote:
> > I just learned about an individual submission, which is probably of
> > interest not only to the members of these two WGs;
> >
> > There seem to be at least two or three major issues that compromise
> > either the working and stability of TCP, or work against the
> > intended "stealthieness" of this modification (making it easy for an
> > attacker to identify such sessions, provided he is able to actively
> > interfere with segments in transit (ie. cause certain segments to be
> > dropped).
>
> > Nevertheless, it might be beneficial to discuss the generic idea in
> > a wider forum, among brighter minds than me.

Let's look at Richard's concerns:

> compromise either the working and stability of TCP

This RFC only modifies the calculation of the SQN number in order to get
port-knockable services. Every other host between just continues to see
the SQN as a random number as it did before. Unless between hops were to
modify the packet's timestamps, this will be completely backwards
compatible.

> work against the intended "stealthieness" of this modification (making
> it easy for an attacker to identify such sessions, provided he is able
> to actively interfere with segments in transit

This is not about hiding from big brother who is listening on the wire.
This is about minimising your visible footprint to the wider internet.
It's on par to your server's firewall dropping all incoming connections
unless you have the shared secret. But with this RFC, you don't need to
know the source IP address before hand.

I think it's a great idea. Nice work.

Alfie

-- 
  Alfie John
  [email-masked]

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 18 Aug 2014 22:07:31 +0000

Hi Alfie,

my concern is with the use of a static ISN for each 4-tuple; this significantly increases the chance of a  collision between sessions (ie. when the sender terminates a sluggish earlier session, some segments of that last session will very likely be in-window for a session that was started a short time later).

(I understand that an application could use some crude time-based salt, to address this concern. But that would mean application/socket level modifications; and additional failure modes - like Kerberos has with the 5 min time window).

Of course, the ephemeral source ports (the remaining 3 fields of the 4 tuple will again be static for a given service) will provide some protection, as each different source port will have a different ISN.

OTOH, detection of this knocking scheme will be rather easy by passive means - currently the probability to two identical ISNs between two different sessions for the same 4-tuple (IP + ports) will be around 2^-32; with this, it is 1; and the number of ephemeral ports is limited so observing a protected web server will be rather straight forwards.

Which probably will flag such a service as a primary target for those adversaries this scheme is supposed to protect against.

Or am I missing something?

Richard Scheffenegger

> -----Original Message-----
> From: Alfie John [mailto:[email-masked]]
> Sent: Montag, 18. August 2014 23:35
> To: Jacob Appelbaum; Scheffenegger, Richard
> Cc: Wesley Eddy; Christian Grothoff; [email-masked]; tcpm
> ([email-masked]); Joe Touch
> Subject: Re: [tcpinc] TCP Stealth - possible interest to the WG
>

---

From: Alfie John <[email-masked]>
Date: Tue, 19 Aug 2014 00:46:31 +0200

On Tue, Aug 19, 2014, at 12:07 AM, Scheffenegger, Richard wrote:
> my concern is with the use of a static ISN for each 4-tuple; this
> significantly increases the chance of a  collision between sessions
> (ie. when the sender terminates a sluggish earlier session, some
> segments of that last session will very likely be in-window for a
> session that was started a short time later).
>
> (I understand that an application could use some crude time-based
> salt, to address this concern. But that would mean application/socket
> level modifications; and additional failure modes - like Kerberos has
> with the 5 min time window).
>
> Of course, the ephemeral source ports (the remaining 3 fields of the 4
> tuple will again be static for a given service) will provide some
> protection, as each different source port will have a different ISN.

Yeah, unless the client is using a fixed source port for whatever
reason, the source port should uniquely identify connections. Maybe this
wouldn't be useful from a high-traffic NAT as source port reuse is a
possibility, but apart from that I'm still all for this.

> OTOH, detection of this knocking scheme will be rather easy by passive
> means - currently the probability to two identical ISNs between two
> different sessions for the same 4-tuple (IP + ports) will be around
> 2^-32; with this, it is 1; and the number of ephemeral ports is
> limited so observing a protected web server will be rather straight
> forwards.
>
> Which probably will flag such a service as a primary target for those
> adversaries this scheme is supposed to protect against.
>

I don't think you're understanding it's main use case. Just like
with vanilla port knocking, it would completely transparent to
someone listening on the wire. But this isn't what it would be used
for. It's purpose is to protect services from the common script
kiddie, but the NSA.

e.g. I wish to setup a web server on my home machine protected by a
     password. The only user is me, but I don't know where I will be
     connecting from so I can't firewall because I don't know my source
     IP address. If this RFC were in place, port 80 would only be
     available to me since I know the shared secret.

     Sure anyone listening on the wire can see that I've got a service
     listening on port 80, but my main concern are the script kiddies
     who try to find open services and then hammer my home server with
     common exploits. This RFC completely protects my web server from
     the script kiddies without me having to setup port knocking (off-
     topic, but port knocking can sometimes be a pain).

Alfie

-- 
  Alfie John
  [email-masked]

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 19 Aug 2014 17:15:43 +0000

On 8/19/14, Hagen Paul Pfeifer <[email-masked]> wrote:
> On 19 August 2014 00:46, Alfie John <[email-masked]> wrote:
>
> For this use case it would be more secure to use TLS client certificates!?

No. I want to protect my TLS service from implementation exploitation.
You cannot probe my TLS service for the next heartbleed without a
shared secret.

>
> I mean
>
> a) TLS is strong crypto with all benefits (authentication, encryption,
> integrity) and
> b) a discovered, open TLS port do not open any security whole at all -
> the only script kiddy conclusion is "a unknown service is running at a
> specific port and that cipher suite 1,2,3 are supported". Nothing is
> more secure then a protocol protected by strong underlying
> cryptography.

This is false - see heartbleed for the most concrete example.

>
> Do I miss something? I mean the benefits of this draft are clear: the
> proposed implementation effort is small, the application setup is one
> additional setsockopt() line, etc. pp. But on the other hand the
> mechanism smells: it address the problem of service discovery by
> abusing TCP's ISN.

It isn't abuse - we're even trying to make it a standard to ensure
that it is well documented non-abusive behavior - rather different
than most other port knocking, I'd add.

>
> Another objection: the mechanism help only for a small fraction of use
> cases. Especially when the server communicate with one or a few
> clients where the "shared secret" is no problem. But especially in
> these setups TLS client certificates could be used without any
> problems.
>

What happens in your example when there is exploitable code in the
client certificate parsing code?

> Anyway, I am little bit ambivalent regarding this ID. It may help in
> some situations and reduce the attack vector. Any effort to improve
> the security should be reviewed! I mean if there are no negative
> impacts: why not? ;-)
>

That was one of our thoughts as well. This does no harm to anyone and
does help specific people who wish to use it. When combined with a
secure protocols, it is even better.

All the best,
Jacob

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 19 Aug 2014 17:20:19 +0000

Hi Hagen,

> Anyway, I am little bit ambivalent regarding this ID. It may help in some
> situations and reduce the attack vector. Any effort to improve the
> security should be reviewed! I mean if there are no negative
> impacts: why not? ;-)

I'm reluctant to conclude that there are no negative impacts.

As an example, think of a lightweight http server running this on a server, an legimtate client (knowing the secret) running on a similar leightweight client without TSopt and only very few ephemeral ports.

For each http session, the very same ISN will be re-used for every identical source port. In that enviornment the chances for a delayed packet to corrupt a TCP stream are non-negligible any more... ( the inverse of the number of ephemeral source ports available).

Also, the client will have to do a fall-back SYN without TSopt, if an intermediate meddlebox modifies the TSopt in any way; and across normalizers (also not completely uncommon) the scheme breaks down. But then, those meddleboxes shouldn't really be messing around to begin with... :)

I guess what I'm saying is that if some randomness (high order bits) could be maintained even when the 4-tuples are identical, that would at least address this concern (such sessions would still be detectable, by checking if the low order bits are identical; unless there is some clever way to randomly distribute the hash-bits and random bits, perhaps also based on a (different?) hash of the 4-tuple...

Best regards,

Richard Scheffenegger

---

From: Jacob Appelbaum <[email-masked]>
Date: Tue, 19 Aug 2014 18:21:51 +0000

On 8/19/14, Hagen Paul Pfeifer <[email-masked]> wrote:
> On 19 August 2014 19:15, Jacob Appelbaum <[email-masked]> wrote:
>
> C'mon Jacob, this smells fishy! Let's assume you protect *your*
> service from one potential TLS bugs, this is (partly) possible with
> the mechanism described in the ID. But what happens in the meantime
> with your https:// browsing, openvpn, ... communications? If you
> assume bugs in TLS you must stop all your communications! TLS and
> strong cryptography is the fundamental building block - when it is
> broken the whole communication system is b0rken.

No, it isn't. It isn't a zero sum game. We are trying to protect
against people port scanning - that an authorized user may abuse a
service is another issue - we do not protect against it, except that
you may revoke that user's ability to exploit the service, of course.

>
> The other way, if you trust TLS you can also trust the TLS client
> certificates mechanism as well.

This is false. I use heartbleed as the example.

>
> I understand your objection but the "fix" feels wrong. We should do
> everything we can to make TLS fast, clean and strong. But to repeat
> myself: I see advantages and benefits and _if_ there are no major
> disadvantages we can push things forward. Well, no need to answer
> here, I got your point in detail and I want to make sure we discuss
> all possibilities, using TLS client certificates is one alternative.
>

We should do both. It would be nice if TCP helped us with this
realistic issue - services are exploitable, let us mitigate the
problem with authentication for specific services at a different
layer. We can authenticate the use of a service in a forward
compatible manner and that is what the draft seeks to standardize.

> The ISN has 32 bits, reduce this space leads to problems in the past.
> We must do everything to not open any other attack vectors regarding
> TCP by mistake. If you *prove* that this will not lead to problems, I
> will never ever mention the word "abuse" in an email to you! ;-)

The ISN is still 32bits. We do not reduce the space and the entropy of
the space does not change. There are corner cases where a passive
observer may replay a packet as if it was normal TCP. Thus in the
worst case, we're as bad as TCP is in every case, all the time.

All the best,
Jacob

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 19 Aug 2014 21:16:47 -0700

Hi Jacob,

I've read the draft. My concern is some middlebox update ISN (due to ISN
randomizations or transparent proxy, etc).
When ISN is modified, I don't know how TCP Stealth server can fall back to
normal TCP.

According to ( http://dl.acm.org/citation.cfm?id=2068834 ), you might run
into ISN modification around over 4%. In case of port 80, you'll see more
modifications, which is over 15%. I'm not very sure if this ratio is too
small to ignore.

Also, I am hesitant to say that this draft is compatible with other
standard RFCs.
Please see RFC6528. Also, It is not compatible what RFC793 mentions on ISN.

Thanks,
--
Yoshi

On Mon, Aug 18, 2014 at 5:50 AM, Jacob Appelbaum <[email-masked]>
wrote:

> interest
> > On a first, casual glance, I am wondering if the authors have realized
> all
> > the implications of their suggestion;
> >
>
> either
> > Nevertheless, it might be beneficial to discuss the generic idea in a
> wider
> > forum, among brighter minds than me.
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 20 Aug 2014 11:23:41 +0000

Jacob, Christian,

To add some constructive discussion points:

As the editor of RFC7323 (soon to be released), which is the update to 1323, and the discussion I looked at over at http://thread.gmane.org/gmane.linux.network/294386 and of course here, I was wondering if you might have it backwards...

I have not seen a convincing enough argument, that running a fixed ISN for a 4-tuple is really safe. (And yes, re-use of a 4-tuple should be rare, but it can happen).

Also, you want to add some additional "randomness" by adding the TSval into the hash, if available.

However, TSval is not random, it's in most implementations a pretty accurate uptime indicator (that this in itself is a bad idea, is known for a long time. That it would make sense to randomize the TSval in the same way as the ISN is now much more prominently stated in RFC7323).

So, I could not help myself from wondering, if you haven't got your fields backwards....

If you want undetectable knocking, which authenticates a particular user, why not transport that hash as TSval (or optionally, the unused/empty TSecr; however, that would be detectable to someone with a sniffer, as early Win95 is not really that common any more). That would leave TCP ISN alone  - and as a true core component, arguing for a modification there has to come with very good arguments. Also, it would serve to randomize the TSval - as ISN is supposed to be choosen randomly - thus help close another indirect exploit vector.

And as you already stated that connections across Meddleboxes (those that tweak around with ISN or TSval) are out of scope and may fail, you don't really reduce the population of sessions that could benefit from this.

Finally, as TSopt is optional, modifications there have a much lower bar for acceptance, compared to a modification like the ISN; a server implementing the scheme would still be free to silently discard TCP SYNs without TSOpt, or the wrong TSval / TSecr... (As you could instruct your firewall to block empty, non-related RSTs). 

Finally, the combination of TSval/TSecr would yield 64 bits, btw. But only on the SYN...

Richard Scheffenegger

> From: Christian Grothoff [mailto:[email-masked]]
> Sent: Dienstag, 19. August 2014 21:04
> To: Hagen Paul Pfeifer
> Cc: Jacob Appelbaum; [email-masked]; Scheffenegger, Richard;
> [email-masked]; tcpm ([email-masked]); Joe Touch
> Subject: Re: [tcpm] [tcpinc] TCP Stealth - possible interest to the WG
> 
> On 08/19/2014 08:59 PM, Hagen Paul Pfeifer wrote:
> > On 19 August 2014 20:27, Christian Grothoff <[email-masked]>
> wrote:
> >
> >> You clearly also deliberately missunderstand the difference between
> >> design / specification / mechanism, and the reality of an
> implementation.
> >
> > No, I don't. But you are right, we should talk about implementation
> issues.
> >
> >> Prove is a strong word.  Now, I would not mind if the standard included
> >> some strong wording on using a random TSval in combination with TCP
> >> Stealth by default.  But, as was pointed out, due to some NATs messing
> >> with TSvals, we decided to keep it optional, as opposed to mandatory.
> >> But I think that is a point I would be open to discuss, as it is really
> >> a trade-off.
> >
> > TSvals *are* optional, you propose TCP stealth should depend on an
> > "optional option"?
> 
> What I said is that if possible, clients should use TCP stealth in
> combination with this optional option. As it is an option, we did not
> make it mandatory, but I think it is totally acceptable to recommend
> using the option.
> 
> > I clearly see problems here because they can be
> > filtered, disabled or simple the limited option space is exhausted by
> > other options.
> 
> We do have a measurement study on this in Julian's master's thesis. Yes,
> it does happen, but it is uncommon.
> 
> > What about PAWS? What about ISN duplicates and how are
> > these handled (and differentiated)?
> 
> We discuss TCP SYN retransmissions in the draft.

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 20 Aug 2014 12:13:03 +0000

Hi Christian,

> We do that, did you even read the draft?

I did, but my wording was unfortunate; Let me rephrase: The use of TSopt is optional in your draft. Why not make it mandatory?

> 
> > However, TSval is not random, it's in most implementations a pretty
> > accurate uptime indicator (that this in itself is a bad idea, is known
> > for a long time. That it would make sense to randomize the TSval in
> > the same way as the ISN is now much more prominently stated in
> > RFC7323).
> 
> We do agree that the TSval should be randomized.
> > 
> Right now, TSval is rarely chosen at random by implementations (see our
> measurement study in Julian's thesis).  So putting the authenticator into
> the TSval would have provided an easy distinguisher, which we wanted to
> avoid.  However, I would in principle support _also_ using the TSval, that
> way we could get 64 bits.  But, as said before, this is a trade-off with
> respect to how many middleboxes will work, as some fiddle with TSval but
> not the ISN (and vice versa).

Well, OpenBSD does proper randomization; also, when someone follows RFC7323, proper randomization of TSval should become the norm over time... And as you mentioned earlier, full protection against someone able to both sniff and selectively drop packets is not intended, if I read the draft correctly.

> Right, but the SYN is what matters most IMO.  We could use 32 bits of the
> ISN for the content integrity protector, and another 32 bits of the
> timestamp for the authenticator part, that would be fine.  But, as I said,
> the problem is that this means that handshakes doing so would stand out
> from current traffic.  So really this is a bit of a trade-off between
> passive detection of the knock in the current environment and getting a
> few more bits of security.

Nothing really prevents you from mandating a SYN+TSOPT as basis for TCP Stealth. When putting the authenticator into TSval (with ISN as additional bits of randomness), all those sessions don't look any different from an OpenBSD box connecting - except for some passive TCP option fingerprinting perhaps. But again, all you want to do is not react to SYNs from people that can not observe and meddle with functioning sessions between two third parties...

> Another issue maybe that some current OSes don't use TSval at all, so I
> figured just changing the ISN calculation might be the more conservative
> suggestion, but again, this is clearly a trade-off and if IETF decided to
> instead to ISN+TSval or even just TSval, I would still consider this a big
> progress.

I'd be in full support for your proposal, when ISN is kept unmodified, and the authenticator bits put into TSval or TSecr of a SYN. Again, putting bits in TSecr would make your traffic stand out, not that those implementations that were broken in that respect, have vanished.

Best regards,
   Richard

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 20 Aug 2014 12:21:35 +0000

Hi Hagen,

Actually, the initiator (sender) of a session could roll the dice multiple times (select different ISNs), until the hashed TSopt fulfills the PAWS requirement of being larger than the last TSopt sent in the previous session to that host/port/4-tuple... 

Would require a bit more state within that host, but would be manageable (using the system uptime really always was a kludge IMHO ).

To paraphrase:
TSecr SHOULD be zero on SYN, (even though some implementations didn't adhere to this), and MUST NOT be interpreted when ACK is not set.  

In my opinion, the only reason to not use the TSopt/TSecr combination would be to have this steganographic property to mislead a more advanced adversary that can sniff traffic in between two third parties.

Richard Scheffenegger

> From: Hagen Paul Pfeifer [mailto:[email-masked]]
> Sent: Mittwoch, 20. August 2014 14:03
> To: Scheffenegger, Richard
> Cc: Christian Grothoff; Jacob Appelbaum; [email-masked];
> On 20 August 2014 13:23, Scheffenegger, Richard <[email-masked]> wrote:
> 
> > If you want undetectable knocking, which authenticates a particular
> user, why not transport that hash as TSval (or optionally, the
> unused/empty TSecr; however, that would be detectable to someone with a
> sniffer, as early Win95 is not really that common any more). That would
> leave TCP ISN alone  - and as a true core component, arguing for a
> modification there has to come with very good arguments. Also, it would
> serve to randomize the TSval - as ISN is supposed to be choosen randomly -
> thus help close another indirect exploit vector.
> 
> Sounds better then messing with the ISN. One show stopper still
> exists: the TSval is required to strong monotonicity increasing for PAWS
> protection. To lower the barrier one more time: why not just use TSecr?
> 
> This relax just nearly all headaches and 32 bits are still enough for this
> mechanism?!
> 
> Hagen

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 13:43:07 +0000

On 8/19/14, Florian Westphal <[email-masked]> wrote:
> Jacob Appelbaum <[email-masked]> wrote:
> So you won't accept e.g. smtp STARTTLS on your mail server?

That is likely a public service that is never going to be restricted
with TCP Stealth.

>
> Also, once this becomes widespread, people will add
> --probe-all-isns switch to their port scanners....
>

That sounds fantastic - it suggests that a person is willing to send
2^32 packets to a single port. That will stick out like a sore thumb
and of course, a system can detect this probing and take reasonable
precautions.

> It looks to me like this (I apologize In advance if this seems
> offensive):
>
> Q: - I want to run $service, but I don't want anyone to see it!
> A: - don't run it.

That isn't an option.

>
> Q: - But I need to access the service sometimes from random locations!
> A: - protect it with a password/some other form of secret.
>

That is exactly what is done here - we protect it with "some other
form of secret."

> Q: - But then its visible to port scanners!
> A: - So what?

Defense in depth - we don't need to run faster than the bear, only
faster than everyone else. :)

>
> Q: - But it allows people who have detected service presence
> to try running exploits against it!
> A: - If you really care, tunnel via ssh perhaps?

Using a VPN or something like a VPN is one option, yes. When that edge
software has issues, it would be nice to ensure that a casual attacker
will not even discover this software is running.

>
> Q: But I really really want to hide the presence of all services,
> i.e. all tcp ports should appear to be closed
>
> A1: - There are portknock schemes to add obfuscation if you really want
> this.
>

That is exactly what TCP Stealth aims to standardize.

> Q: - But I cannot use portknocking because....?
> A: - ?
>
> I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00,
> but did not find any.  It talks about "pitfalls" of applications
> trying to "reimplement tcp in user space".  Perhaps there
> should be a paragraph as to why ra
>

...?

> But even assuming that there is a need for portknocking and/or
> TCP Stealth:
>
> - How does this relate to TCP-AO?
> (The draft mentions tcp md5sig only, then disregards it as it
> doesn't work in NATted environments)
>
> [ I realize TCP AO has other issues esp. vs. the proposed stealth
>   scheme, especially wrt. complexity.  Anything else? ]
>
>
> Problems I see with the proposal (ignoring the TCP related issues
> others pointed out and the "obscurity only" approach),
> and a few questions:
>
> - What about timing?  I.e. is response time different regarding
> RST-from-closed-port vs. RST-from-stealth port?

This will vary by implementation and configuration. At the moment, I
think that it is minimal over the internet but I wouldn't be surprised
if there was a detectable jitter. I defer to Christian about specifics
on this measurement though. Perhaps we can put up a service as a demo?
:)

> - e.g., are hosts required to perform authentication even for
> SYN-to-closed-port, etc?
>
> - Your adversary may be able to do full passive monitoring of
> all network traffic (also compare "replay" above), so whats the purpose
> of "avoiding" active scans?
>

Exactly the purpose - we wish to avoid active scans. The GCHQ/NSA/CSEC
do active scans when their full passive monitoring isn't enough. This
hampers that angle of information gathering. It also ensures that even
if they are monitoring with a passive/active tap - we can authenticate
the first bytes of a secure protocol setup. This is good news - it
means that even a sniffer can't wait for a sysadmin to ssh into the
server and then hijack the session.

> - Key Propagation (either your group is very very small, or I can
> probably find the secret-secret-word via a web search...)

The first is certain for many services, the second assumes a totally
public service. There is no reason that the second must be true, even
if the first assertion is correct.

>
> - Seems most services cannot use it since they have to accept
> connections from (almost) anyone

Huh?

>
> In fact, this is one of the main problems that I see with the proposal;
> its use seems severely limited; up to the point where its unusable in
> practice.
>
> Perhaps it would help to show specific usage examples
> of how this would be deployed/where this is usable?

I think gnunet.org is a good example of where it is currently deployed.

> "What happens in your example when there is exploitable code in the
> payload protection verification?"
>
> [ Its rhetoric question.  I am aware of complexity difference. The point
> is, do your really think its worth to add yet another layer -- which can
> have issues both in the specification and the implementation -- rather than
> e.g. slim down/fix security transport protocol specs and implementations? ]
>
> Else, I guess I could argue that running your service via SCTP is "more
> secure" since its "less likely to be found in scan..."
>

There is specific cryptographic complexity in TCP Stealth and that is
not the case with SCTP in your example.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 20 Aug 2014 16:00:17 +0000

On 8/20/14, Daniel Borkmann <[email-masked]> wrote:
> On 08/20/2014 03:43 PM, Jacob Appelbaum wrote:
> [...]
> [...]
> Ok, but for the majority of use cases, lets presume that you'd
> pass one of these secretly hidden taps located at some cooperative
> IX. Assuming the worst case that some passive adversary has access
> to enough taps distributed at convenient locations, did a previous
> active port scan and knows that from your machine port 22 is closed.
> Later, it observes a two-way flow to port 22 to that machine and the
> existence of the service is of course nevertheless revealed.

Sounds good. We've just taken detection of the service from everyone
in the world to a passive wiretapping attacker observing a
sysadmin/user and the service. Otherwise they're going to need to send
~2^32-1 packets per port guess.

>
> You might be able then to 'mitigate' actual access to the service
> a bit, but then again 32 bit is perhaps a limited sense of 'security'.

Sure, I agree. We're limiting against a specific, well scoped specific
issue that is pervasive and a problem. We do not solve every problem
for every attacker. We have deployed code that is running today and it
works, roughly. :)

> It would also be required that machines running more than one service
> have /all/ services somewhat protected by TCP stealth, otherwise an
> attacker moves on with the next service as an attack vector

That would be consistent but it isn't required. Not all services are
created equally - e.g.: OpenSSH ( + ssh keys + TCP Stealth) has root
privileges on a system, even if privilege separated. Not all services
are so enabled.

Another use case is for Tor bridges - in this case - we only care
about active probing. Even in advanced cases like the "great" firewall
of China, they use active probing to confirm their wiretapped machine
learning decisions...

> Again,
> if also services over other transport protocols are used on the
> machines (that cannot make use of TCP stealth), an attacker might
> first probe for these as an easier target to get in.

Of course.

> Key propagation is certainly an issue I assume; you might also want
> to consider to rotate them etc; large public sites most likely cannot
> make use of TCP stealth, and the larger a group becomes, the more weak
> points might arise (including humans) to disclose the shared secret
> somehow.

Per user shared secrets seem to fit the bill here.

> Then again, it might also not be worth it for pubkeys as it
> would significantly increase computational complexity on the server
> side and we're only talking about 32 bit ...
>

I think that the decoy routing field holds some interesting tricks for
public keys. Telex hides a signature in the TLS handshake, for
example. Perhaps for a later version of TCP stealth? :)

> /offtopic here, but wouldn't it then be better to work towards full
> encryption like CurveCP et al is trying to solve ...

I'd like to see that too. We'll get there and this is one step in a
similar direction.

All the best,
Jacob

---

From: Alfie John <[email-masked]>
Date: Wed, 20 Aug 2014 23:29:23 +0200

On Wed, Aug 20, 2014, at 03:43 PM, Jacob Appelbaum wrote:
> > I tried to find explanation in draft-kirsch-ietf-tcp-stealth-00, but
> > did not find any.  It talks about "pitfalls" of applications trying
> > to "reimplement tcp in user space".  Perhaps there should be a
> > paragraph as to why ra
> >
>
> ...?

When you're on a network that filters everything but DNS, HTTP and
HTTPS, you don't have the option of port knocking.

Alfie

-- 
  Alfie John
  [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Aug 2014 21:16:01 -0700

On 8/18/2014 3:07 PM, Scheffenegger, Richard wrote:
> significantly increases the chance of a collision between sessions (ie.
> when the sender terminates a sluggish earlier session, some segments of
> that last session will very likely be in-window for a session that was
> started a short time later).

+1, and I haven't seen a satisfactory answer to this yet.

FWIW, the doc refers to TCP MD5, which has been deprecated and replaced 
by TCP-AO. TCP-AO has an experimental extension to support NAT traversal.

Additionally, responding with a TCP RST isn't the best response if 
you're trying to hide from port knocking. Silence is best in that case.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Aug 2014 10:01:47 -0700

On 8/21/2014 9:22 AM, Christian Grothoff wrote:
> On 08/21/14 06:16, Joe Touch wrote:
>>
>>
> Well, several people seem to suggest that making the use of TSval
> _mandatory_ with TCP Stealth would solve this and other concerns; so if
> we put that into the draft, would you be happy?

You still have the ISN validity to deal with. TSval helps differentiate 
wrap - i.e., first use of a sequence number space vs. future use. Your 
ISN calculation could easily generate an ISN that's valid for the TSval 
used.

> That depends on what the system does for a closed port.

No, it depends on what the system does for a port for which no process 
is listening. CLOSED is a TCP state. RST says something is listening on 
the connection but doesn't want to talk to you given the SYN parameters 
you gave.

ICMP destination unreachable/port unreachable seems more what you're 
aiming for if you want to prevent someone from trying again.

Joe

   The draft says
> the system should react in the same way as it usually does, and usually
> MY servers respond with TCP RST if the port is closed. If you usually
> drop, you should drop.  If this is about hiding, the key thing is to not
> change the behavior for the stealth-open port in relation to the
> behavior of a closed port.
>