←back to thread

Stop Breaking TLS

(www.markround.com)
170 points todsacerdoti | 6 comments | 10 Dec 25 07:06 UTC | HN request time: 0s | source | bottom
Show context
gschizas ◴[10 Dec 25 09:31 UTC] No.46215801[source]▶
The fact that most tools have completely different ways to allow them to add certificates is the biggest pain. Git, Python and Rust also have large issues. Git doesn't default to "http.schannel". Python (or rather requests, or maybe urllib3) only looks at its own certificate store, and I have no idea how Rust does this (well, I use uv, and it has its own problems - I know about the --use-native-tls flag, but it should be a default at the least).
replies(5): >>46215828 #>>46215876 #>>46216017 #>>46216074 #>>46216859 #
1. jeroenhd ◴[10 Dec 25 12:13 UTC] No.46216859[source]▶
On Android, macOS/iOS, and Windows, this is a solved problem. Only on the extremely fragmented Linux/Posix runtimes do these problems surface.

Rust's solution is "it depends". You can use OpenSSL (system or statically compiled) or rustls (statically compiled with your own CA roots, system CA roots, or WebPKI CA roots).

I'm afraid that until the *ix operating systems come out with a new POSIX-like definition that stabilises a TLS API, regardless of whether that's the OpenSSL API, the WolfSSL API, or GnuTLS, we'll have to keep hacking around in APIs that need to be compatible with arbitrary TLS configurations. Alternatively, running applications through Waydroid/Wine will work just fine if Linux runtimes can't get their shit together.

replies(4): >>46217672 #>>46222473 #>>46225695 #>>46229747 #
2. dmm ◴[10 Dec 25 13:48 UTC] No.46217672[source]▶
> Windows, this is a solved problem.

Are you sure? It's been a few years, but last I tried Firefox used its own CA store on Windows. I'm pretty sure openjdk uses "<JAVA_HOME>/jre/lib/security/cacerts" instead of the system store too.

3. dingaling ◴[10 Dec 25 19:33 UTC] No.46222473[source]▶
I absolutely do not want to be constrained to a single system cert store controlled by the OS vendor.
replies(1): >>46227579 #
4. arianvanp ◴[10 Dec 25 23:44 UTC] No.46225695[source]▶
Is it solved in macOS? Curl recently removed macOS keychain support as there are like 7 competing APIs 6 of which are deprecated and number 6 is a complete HTTP replacement so curl can't use it.

Only reason why it works on macOS curl is because they're a few versions behind

5. xp84 ◴[11 Dec 25 04:13 UTC] No.46227579[source]▶
That last part does sound like a bad deal based on recent anti-owner-control habits like sealed immutable system volumes, but I definitely want to be constrained to a single system cert store controlled by the owner of a computer. Which works for the corporate case as well as the personal one.
6. crote ◴[11 Dec 25 10:34 UTC] No.46229747[source]▶
> On Android, macOS/iOS, and Windows, this is a solved problem.

Is it, though? It is absolutely trivial for an Android app (like the one you use for banking) to pin a specific CA or even a specific server certificate, and as far as I'm aware it is pretty much impossible to universally override this.

In fact, by default Android apps don't accept any user-installed certs. It uses separate stores for system-installed CA roots and user-installed CA roots, and since Android 7.0 the default is to only include the system-installed store. Apps have to explicitly opt-in to trusting the user-installed store.