LWN.net: “Changes in the TLS certificate ecosystem”

I was glad to come up to speed with what has been happening with TLS in the last couple of years, and I highly recommend reading these articles.

  • https://lwn.net/Articles/663875/
  • https://lwn.net/Articles/664385/

I learned about HTTP Public Key Pinning, Certificate Transparency, and STARTTLS stripping, among other things.

Here’s one of many good quotes:

The core problem of the TLS certificate system is that there exist hundreds of certificate authorities. And unless extra protection measures are in place, each of those can create valid certificates for any domain. Therefore the whole system is only as strong as the weakest of all certificate authorities.

And as for embedded devices that handle encryption:

We are well aware that crypto appears to be something that needs to be field replaceable, and yet we more or less have no clue how to do that in deployed embedded hardware. Indeed, we seem to have a very poor idea in general on how to maintain the software on field deployed embedded hardware. — Perry Metzger

As I’ve worked with Python, I realize that it’s one thing to implement TLS, and another thing to verify server certificates. The Python requests library can be configured to do the right thing, but the python SMTP cannot. It’s still another thing to check on certificate revocation. Python doesn’t implement OCSP or CRLs, and those mechanisms are problematic anyway. It doesn’t yet implement HTTP Public Key Pinning. The state of affairs may not be much better in other programming toolboxes.

So I’d guess that machine to machine internet communication is probably more vulnerable to man in the middle attacks than consumer web browsers.