Hacker News Reader

Comment by therein | Hacker News Reader

Because we are introducing a third party into a situation that didn't require a third party.

And if you just rely on the default trust stores you’re actually introducing over 100 third parties, some of which are known to be controlled by (or at least work with) the NSA, China, etc.

With certificate pinning, that is not a high risk.

If you’re talking about services that you’re accessing via a browser, true. If you actually do pinning (properly).

For service-to-service stuff and APIs the number of TLS clients that respect pinning is approximately zero.

Either way, the other problems remain, and running an internal PKI is really pretty easy.

Very few sites use certificate pinning. Chrome dropped support for dynamic certificate pinning. Web based certificate pinning is often recommended against because it's very hard to do right.

Also, using Let's Encrypt doesn't stop you from certificate pinning.

Certificate pinning (HPKP) is browsers is effectively dead, and was never a good idea to begin with.

There are far too many ways to self-DoS accidentally with HPKP. Also, an attacker who briefly gains control of your public DNS or web server can DoS a hostname semi-permanently.

Won't all the client machines already have hundreds of 3rd party CAs (including Let's Encrypt) loaded onto them anyway?

Yea, by default anyways, but that doesn’t mean you need to use/trust them for a particular request. I’m talking mostly about service-to-service traffic fwiw, not browsers.

Reply on news.ycombinator.com