Get MbedTLS to use system trusted roots

[aviks]

instead of bundling a stale mozilla root? Is it not a security issue if we cannot regularly update the roots after install?

At least on Windows, mac and some linuxen, the system trusted root should be well defined.

[staticfloat]

We tried to do this (you can read some of the history here: https://github.com/JuliaLang/julia/issues/13399) but it's really hard to get this to work well, because there is a wide variety across systems as to where these things are stored (even on Linux). We also ended up running into problems where the system roots were so out of date that you couldn't connect to anything on the web. (Note that it's entirely possible for old linux systems to be in this state, yet Chrome and Firefox continue to work, because Chrome and Firefox ship their own certificate bundles).

I think ideally what we want is:

• Have MbedTLS.jl ship with certificates, not just Base julia. That way, we can update them through Pkg, independent of base Julia.

• Allow for the inspection of the currently running system, and integration of custom certificates. I think this is 99% of the reason people want the system certificates used instead of the "official" bundle from Mozilla.

Honestly, this could be a nice little micro-package. Something that allows us to syndicate trusted updates to the certificate store, and also provides a way to say "hey, you want more certificates used? Plop them in ~/.julia/config/ca_certs" or something like that. We could of course have logic in that package to automatically snarf certificates from the system store, and only use certificates from that store that are newer than whatever we have bundled locally.

[aviks]

On my Mac, Chrome uses system certificates, as far as I can see (the Chrome certificate management setting open up Keychain Access). I believe that to be the case on windows as well.

[staticfloat]

Chrome does a kind of "integration" of things it ships with itself, and what is already on the system: https://www.chromium.org/Home/chromium-security/root-ca-policy

[aviks]

Yeah, so I read that as Chrome using Windows and Mac system roots, and bundled mozilla root on linux. It then overlays a custom "distrust" list on top. But trust always flows from the system roots on mac and windows. (disregarding EV, which we don't care about). We don't have to implement a distrust layer ourselves, since in most cases, the OS roots also ban the certs that chrome bans.

Given this, and the fact that all the issues listed in #13399 are on linux, following Chrome's lead seems to me to be the best option.

[staticfloat]

For Mac and Windows, I agree that in general the system store should be fine. Note that even on those systems, Chrome and Firefox ship an overlay of trusted sites (not just distrust) in the form of static HPKP (there's a big .json file with ~69K domains listed that get pinned along with all their subdomains) but that's hardly the entire internet. Just enough to make sure that the average user can still get around the internet and be served ads, I would guess. ;)

[dhanak]

It might be time to bump this issue. Since 2019, the core Julia implementation has moved on, and NetworkOptions, for example, now successfully locates the system-wide storage of root certificates. The Julia package manager itself has no issues dealing with servers that use certificates signed by a custom CA authority. Up until Julia 1.3, the root certificate of such authorities had to be added to /share/julia/cert.pem`. Well, not anymore.

MBedTLS.jl, and thus HTTP.jl, has the same issue as Julia versions prior to 1.3. So perhaps MBedTLS.jl should rely more on the Julia stdlib to do the heavy lifting.

The solution, in fact, is very simple, I'll submit a PR for fixing this.