Who do you trust?

I recently found a small issue in some TLS clients. More precisely, it is more of a difference between what happens and what I expect to happen. Let’s dig in!?

When you use TLS, you can decide to use your own certificate authority (CA). Three main reasons:

1. cheaper (arguable nowadays with https://letsencrypt.org/)
2. easier (arguable nowadays with https://letsencrypt.org/)
3. A compromise/malicious CA is in your threat model.

If you pick #3, you should keep reading.

In many TLS clients (curl, wget, httpie…) and libraries, you have options like cacert or capath (or similar). These options are used to trust one or many Certificate Authorities.

When you run clients with one of these options, you pass the certificate or certificates you want to trust. But this is ambiguous, let’s see why.

Some tools will add the CA provided to the list of authorities the system already trusts. Other tools will only trust the CA provided (and no longer trust the authorities that the system already trust).

So if you don’t want to trust your system’s CAs and use your own CA, you should make sure that all your TLS clients will not trust the system CAs even if you pass the « right » option.

You can easily test this by generating a self-signed cert:

If you see an error message, you’re not trusted your system’s CAs (good). If you don’t see an error, you’re trusting your system’s CAs as well as ca.pem (not so good depending on your threat model).

Again not a big deal. Just something that may surprise a few people (including me).

As a developer, I kind of want that only my own CA be trusted when I use one of these options. If I want to trust my system CAs and my own CA, I will probably use different classes/functions for each use case and not mix them.