On 8/19/14, Hagen Paul Pfeifer <[email protected]> wrote: > On 19 August 2014 00:46, Alfie John <[email protected]> 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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
