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

[Christian Grothoff <[e-mail]>]

On 08/19/2014 11:23 PM, Florian Westphal wrote:
> Jacob Appelbaum <[e-mail]> wrote:
>> 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.
> 
> So you won't accept e.g. smtp STARTTLS on your mail server?
> 
> Also, once this becomes widespread, people will add
> --probe-all-isns switch to their port scanners....

If that makes port scanning 2 billion times more expensive, great.
As we said, that would really Knock down the HACIENDA-style ultra-large
scale port scanning of machines.  So if we get there, for TCP Stealth
that would be mission accomplished.

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

Sorry, did you even see the NSA slide with the brute-forcing of
passwords?  Are _all_ of your passwords longer and/or more complex than
those shown there?  If not, you loose.  Also, even if yours are long
enough, please make sure the same applies to everyone else administering
systems on the planet. You cannot? Then help us deploy TCP Stealth.

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

So what? Then the GCHQ/NSA will use TAO-developed or purchased 0-day
attacks to turn me into an ORB, I don't like my machine to be turned
into an CSEC-bot that then attacks other systems.  You may think that
doesn't matter, but I do.

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

I do really care. But they do scan for SSH (did you see the slides?). So
what if they have an undisclosed vulnerability for SSH?

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

Yes, and TCP Stealth provides a standardized port knocking method that
works reasonably well with NAT and is not easy to detect, so I really
want this.

> 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 didn't post it here, so I cannot answer that.

> [ 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),

Sorry, this is not "obscurity only", with a shared secret this is
defense in depth, not at all security by obscurity.  A detailed
explanation of this point is in Julian's thesis.

> and a few questions:
> 
> - What about timing?  I.e. is response time different regarding
> RST-from-closed-port vs. RST-from-stealth port?

First of all, that's an implementation issue, and one of the reasons why
this should be done in-kernel and with MD5.  But yes, implementors
should be wary of timing attacks.

> - e.g., are hosts required to perform authentication even for
> SYN-to-closed-port, etc?

No, but of course they may choose to do so to defend against timing
attacks.  The calculation is fast enough for this to be feasible.

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

Again, defense in depth. Not every adversary can do passive scans.

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

Yes, the group should be small.  Or you could use the GNU Name System to
share the secret securely via the name system, but that's way too
radical for IETF at this time.

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

This is intended for administrative services with a limited user group.

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

It is an _option_.  I can equally argue VPNs or firewalls are severely
limited and unusable in practice -- but that would only be true if my
mind was not open to use-cases outside of my personal domain.  For me
personally, VPNs and firewalls are useless. Still, I acknowledge that
they may have value for other users.  TCP Stealth is merely one
additional tool for system administrators we propose, and you can say
that for your work others are more appropriate, or you can combine
multiple methods.

> Perhaps it would help to show specific usage examples
> of how this would be deployed/where this is usable?

I login into my machine at my office via SSH dozens of times a day from
all over the world. I am the only user.

We run a build server farm, there are like five users. The handful of
build servers accesses the master server via HTTPS.

I access my personal IMAPS server on another system also from all over
the planet, there are two other users of that IMAPS service.  And
updating certificates and keys after Heartbleat knowing that my mail may
have been compromised in the meantime is not something I like.

>> What happens in your example when there is exploitable code in the
>> client certificate parsing code?
> 
> "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? ]

Once you have a secure transport protocol implementation with smaller
complexity than the TCP Stealth implementation and are getting it
universally deployed (including for legacy services), I'll concede your
point.

> Else, I guess I could argue that running your service via SCTP is "more
> secure" since its "less likely to be found in scan..."

True, but again in the real world there are NATs, so good luck accessing
your SCTP service on the modern ossified Internet.