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

[Hagen Paul Pfeifer <[e-mail]>]

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

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.

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.

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.

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


Hagen