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

[Florian Westphal <[e-mail]>]

Christian Grothoff <[e-mail]> wrote:
> 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.

Sorry, I think this is a very very poor motivation for an extension
of a widely deployed protocol that will have to be maintained forever,
especially given that your "ultra large scale port scanning machines"
would just be turned into "ultra large scale 3-way-handshake monitoring
machines" (although I am sympathetic to the cause).

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

It depends on the value of the service the password is for.

> enough, please make sure the same applies to everyone else administering
> systems on the planet. You cannot? Then help us deploy TCP Stealth.

Sorry, but I don't see how "everyone administering systems on the planet"
would be capable of using Stealth-TCP, even assuming everyone would want
to use it if implemented.

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

Well, I don't want that either.  But I don't see how STEALTH helps me
preventing that.

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

Then criminals can break into my system.
Again, I fail to understand/see how TCP Stealth would help.

I could use stealth to protect vs. sshd pre-authentication bugs.

I cannot use TCP stealth to protect against bugs in the TLS
implementation.

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

Ugh.  Sorry.  Fat fingers.

... as to why other methods, such as traditional port knocking,
or restricting access by IP, or a source otherwise authenticated, e.g.
TCP-AO, TCP-CRYPT, IPSEC, etc. are infeasible/lacking compared to Stealth-TCP.

> > But even assuming that there is a need for portknocking and/or
> > 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.

Well, I agree its better than "rsh running on port 3242"...

> A detailed
> explanation of this point is in Julian's thesis.

Fair enough.  Lets assume I am wrong on the "obscurity" part.

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

If you're a standards writer you should consider the implementors to be
clueless.

If you think its important, consider using MUST in the spec
(I am not specifically talking about stealth tcp here).

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

Hmmm.  In that case, I really hope this won't go far, sorry :-/

You talk about "state adversaries".

a) How long do you think it takes these to deploy new technique for
service discovery, e.g. via passive monitoring?

b) How many services, in your opinion, will remain rechable -- by
specific intent/requirement?

c) how many feasible attack vectors remain to compromise
a host even if you could not access a single service?

My guesses are
a) not much
b) a h*ll of a lot
c) too many, probably

Perhaps I am too pessimistic but I think you'll lose on the ground that
this game is rigged from the start.

To me problem statement is:

The networks I am connected to are widely used by criminals
trying to obtain access to my systems abusing the services
that I provide, and running latest versions
is insufficent as these criminals might be in possession
of 0-day exploits.

I am afraid the only working solution to this scenario is

don't use the same network

For the scenarios you described above, e.g. IPsec could be used
to form a private network used only by trusted parties.

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

Hm, not following here.  Are you proposing GNS as a possible
side channel to share secret among  the trusted parties?

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

TBH I wouldn't care provided its kept updated & strong secret,
simply on the grounds that I don't have any more trust in the
underlying machine than in sshd.

But ok.  Yes, TCP Stealth would be suitable to hide sshd
from "everyone else".

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

Should be easy to restrict by source ip, right?
But in case of dynamic addresses, ok.

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

I don't like that either.

But *especially* considering Heartbleed I think one should be very
careful as to which features to add.

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

Fair enough. Lets just say I dislike adding more features to already
complex protocol stacks like tcp for this use case.