Hacker News Reader

Comment by kelnos | Hacker News Reader

> There is no API to actually handle trust.

The various TLS libraries already agree on at least one thing: what certificates look like on disk (e.g. PEM and DER formats). There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here. Then the TLS libraries would have to implement it, and return appropriate errors from their validation functions. This could possibly be done in a way without needing applications to also be updated, though that depends on how each TLS library reports validation errors.

But even if a particular TLS library doesn't have a way to express these errors properly, I think it's better to have a user confused as to why they can't connect to a site, than silently connect to a site "protected" by a certificate that shouldn't be trusted.

View on HN

> The various TLS libraries already agree on at least one thing: what certificates look like on disk (e.g. PEM and DER formats).

Java would like a word with you :(

Java uses those formats too.

Java actually solves the complaint in this thread, and has done for a long time. The JDK has its own root store program run by Sun and now Oracle, TLS APIs use the bundled root store automatically, it provides tools to manage that root store, exceptions are easily rendered to users in a generic way, and it provides a mix of high and low level APIs.

What you're probably thinking of is the JKS format. Java defined a way to represent a root store on disk that's Java specific, I think because there was no standard at the time. But it migrated to the PKCS#12 format in recent releases.

Java has the exact opposite of a solution to this, though their intentions were very admirable. PKCS#12 is a terrible solution, and Java does it's best to enforce it, and it's move to adopt it further is the exact opposite direction that everyone has been moving in.

What everyone's realized in recent years is that trust is context-dependent, and that you don't want to use the same roots of trust (or trust anchors, or CAs, though each of those terms has a slightly different meaning) everywhere, nor do you want to co-mingle them. It doesn't make sense to have one file that specifies "Here are all the CAs I trust, and here are rules for each of them"; It makes a lot more sense to have configuration per use-case of "Here are all the CAs for this usecase", and to rely much more on code within the program to disambigutate. Having one file with all those CA certificates and your private keys is... Backwards. Keytool and their custom format at least kept a clear distinction between "these are my private keys" and "these are keys I trust". PKCS#12 has no such distinction, and the tooling around it (Particularly Java's!) makes it hard to disambiguate safebags, so you're left with one giant mess.

It's actually the same problem as Global Variables[1]; Security and trust isn't one object. It's many. One program may act as itself to many providers, but it might also act as three or four different roles within it's scope to the same provider.

[1] https://dl.acm.org/doi/10.1145/953353.953355

Well, but the default of having a bag of certs with a trust store program does make sense - apps want to just be able to talk to random web servers in a secure manner and that's the only way to get that.

In many use cases you could use a store with only a self-signed certificate. That works, the APIs make it straightforward enough. It has many advantages when possible, e.g. you can set the expiry time to so far in the future it never expires, you don't have to muck about with LetsEncrypt and CAs. You do have to control the client and the server. If your frontend is a web app that's a problem. If it's a mobile or desktop app that's easy. Control over the client has other advantages too like not needing HTTP load balancers anymore (in many cases), reducing costs.

That is one bag of trust, yes. "The web CA pool" (there's not just one, there's actually at least four in common use in America (Google/Chrome, Mozilla, Microsoft, and Apple), with several more besides)

But most modern apps don't just connect to the internet, they connect to internal stuff like databases using TLS as well. It's actually a valid strategy to just use the web trust pool for that as well - I personally use it in places, with the certificate managed by CertBot reused for the webserver and the postgres server.

It's not a solution for the modern enterprise, where mutual TLS is sometimes a requirement and is attractive if not. You will want to have at least one non-web CA pool (Trust Bundle) for your enterprise, and sometimes several more for other departments, or other companies you collaborate with.

Unfortunately (in the case of TRUST stores) it uses pkcs12 in a non-standard way. You cannot, for example, use openssl pkc12 to create a p12 store java can read. Java expects some oracle-specific non-standard attributes on the bag.

PKCS12 keystores work fine, however.

Java has always been its own separate world. For instance, recently we had daylight saving issues on a server (we no longer have daylight savings time, but the Java application thought it had just started). The server did have an updated timezone database with the correct rules... but Java uses a separate timezone database, which hadn't been updated.

Java has used the standard PKCS12 format by default since version 9:

* https://openjdk.org/jeps/229

* https://en.wikipedia.org/wiki/PKCS_12

* https://openjdk.org/projects/jdk9/

Yeah, this confused me when working with java because some of the tools just silently changed to generating PKCS12 certificates when the same options used to generate their proprietary format.

> There's no reason why some committee couldn't sit down and standardize a format for ancillary data such as the trust date cutoffs mentioned here

They already have (https://www.rfc-editor.org/rfc/rfc5280.html, https://www.rfc-editor.org/rfc/rfc6960.html) but CRL/OCSP functionality not implemented in most libraries because it's hard and thankless work.

AFAIK those are standards for allowing CAs to revoke certificates. Trust conditions for root stores are a completely different thing.

Or at least, I'm certainly not aware of any mechanism in the CRL standard to "partially revoke" a CA certificate based on complex conditions like "What's the notBefore date on the leaf certificate we're currently validating?".

Ah I see, you're right I guess they didn't contemplate the scenario of "we want to distrust this CA - against its wishes - but we still trust it enough to make it an orderly transition instead of an emergency". I guess it was previously assumed that CA trust would be binary and that CAs would be cooperative - seems like a pretty common evolution that internet standards go through.

The problem is, code that handles these things is safety critical and requires real and sustained investment to be reliable. Given this overhead (and the gaps in CRL/OCSP support that I mentioned), it's unclear if this use case will be common enough to commit to supporting.

Reply on news.ycombinator.com