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

[Jacob Appelbaum <[e-mail]>]

On 8/19/14, Hagen Paul Pfeifer <[e-mail]> wrote:
> On 19 August 2014 00:46, Alfie John <[e-mail]> wrote:
>
>>      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).
>
> 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