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

[Jacob Appelbaum <[e-mail]>]

On 8/19/14, Florian Westphal <[e-mail]> 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?

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.

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