Hacker News Reader

Comment by richm44 | Hacker News Reader

Note that this library is currently only providing server functionality, and doesn't do certificate validation (in fact it appears to not do any of the X.509 parts of SSL/TLS). It's certainly interesting, but one of the reasons it's so small is that it's missing critical functionality for many use cases.

View on HN

I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.

There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount of code will increase.

Insane complexity is exactly why supporting client certs is a bad idea.

Certainly true if you don't need them. However since code using the library as a TLS client is already partially present, support for certificate verification is definitely going to need to be added.

At the moment, I'm not that impressed with the testing since even making it build actually requires patching it! This is just due to one of the examples, but from the git history it's been broken since January.

No, sorry. The insane complexity is on the requirements. If you need client certs, anything you do to satisfy the need will be at least as complex.

Yes, but 99.999% of web servers don't need client certs.

Source?

Other than the government, nobody trying to do client certs actually runs the CA that issues them that I've seen. Instead, they trust some random set of commercial CAs, ignorant of the fact that openssl s_client -connect will dump out that list to any passer-by. I've even seen them trusting the "domain control validated only" certs, without any indication of "maybe this is a bad idea, because anyone who can buy a cert can auth to us because we don't even check."

So for every case I've seen, they'd have been ahead to issue credentials themselves and just skip client certs.

99.999% of web servers.

I think cperciva's opinion is a sufficiently valid source on this sort of issue, which is probably why you're being down voted.

Thank you for the vote of confidence, but you're wrong. The question of "real world usage of TLS" is one where I would immediately defer to tptacek without question... and you've been around long enough to know that's something I don't do very often.

Of course. But they'll end up implementing it anyway, because of the 00.001%.

Eh, just dumping X509 for something easier-to-parse would cut out a huge chunk of code. Being compatible is hard, but we stick with what we have because of switching cost, not because it's the best we can do.

Practical use of client certs usually implies support for renegotiation too.

Just because you haven't come across client cert validation requirement, it doesn't mean it's wrong.

If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.

If you have a bunch of small services which need to communicate securely, you should be using something like spiped, not TLS.

TLS is the right solution iff you need to communicate with third parties whom you can't securely share code or keys with in advance.

don't throw solutions with confidence like they are silver bullets. spiped is unmaintained, doesn't support revocation, not easy to debug in a big infrastructure, and will require a lot more work compared to https + client cert authentication, and doesn't provide multi platform support.

PKI is used to build a chain of trust. Whether it involves third parties or not is not the point.

you're replying to the author, and maintainer, of spiped.

Reply on news.ycombinator.com