Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Certificate Authority root stores have a too simple view of 'trust'

utcc.utoronto.ca

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#111

Post by xmodem »

renonce wrote: post #81

CA authorities can set the date when the certificate was issued to any date they like, bypassing the "trusted until" mechanism. Such a CA can still issue any certificate they like, pass browser checks and do MitM. In this way you still trust them to sign the correct issue date while you want to distrust them. Isn't Mozilla's mechanism kind of weird by being not "too simple"?

They can issue any cert they like, but these days browsers also require that certs are written to certificate transparency logs to be trusted, and if they did that it would be detected immediately.

I don't think using curl and openssl directly check CT, though....

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#112

Post by siebenmann »

mike_hearn wrote: post #22
e12e wrote: post #18

Earlier quoted context omitted.

> There is no API to actually handle trust. We might need something more - but I wonder i trust-stores could be modified so that: - every device get a "host" CA (like a ssh key) - this CA is the only one trusted - in turn, this CA signs issuer/top-level CA (or even cross-signs the intermediary certs directly) (eg with - new/-force_pubkey) Additional logic could be applied in the signing step - say rules to set the va…

Certificates advertise if they're meant to be roots or not and libraries enforce that via things like the path length constraints, so it wouldn't work. But it also just seems kind of complicated - how is that any easier than just updating the root store in a cron job, which is already done via normal package maintenance routines anyway? The reason the Linux root stores don't have a notion of 'trust until' like the ar…

I think it's more that Linux root stores date from an era when everyone approached CA trust as a binary thing (even browsers), and there has never been enough pressure and coordination to evolve them into a more complex system, unlike browsers. My memory is that browsers added conditional distrust and conditional limits on CAs and various similar things when they became convinced that it would be too bad of a user experience to simply remove CAs but also too dangerous to retain them in fully empowered form. Having conditional distrust also gave browsers more power over CAs, because now browsers had more options for dealing with marginal but (semi-)popular ones.

(I'm the author of the linked-to entry.)

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#113

Post by usr1106 »

tinus_hn wrote: post #87
usr1106 wrote: post #57

Earlier quoted context omitted.

When I renewed my Let's Encrypt certifcate the last time I noticed that my postfix was still using the certificate that had expired 3 months later. I don't receive a whole lot of email on that machine, but I did not notice any delivey failures. I started to think (but not check specs): Is it even defined what domain name should be checked? MX records can be different from server names. Maybe certificate checking is j…

Considering you basically can only get a certificate for a domain name that refers to a host (and offering an IP address for an unqualified domain name is an anomaly) I’d expect the required subject to be the hostname. But the RFC does not specify it: The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are:…

Thanks for the reference. But this does not seem to make sense. Email delivery is about interoperability. How can that be achieved if parties make their local decisions?

P.S. As you probably guessed in my previous comment "3 months later" should of course have been "3 months earlier". Sorry about the mistake.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#114

Post by GauntletWizard »

mike_hearn wrote: post #83
GauntletWizard wrote: post #47

Earlier quoted context omitted.

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…

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 th…

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.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#115

Post by raxxorraxor »

NovemberWhiskey wrote: post #46
cmeacham98 wrote: post #35

Earlier quoted context omitted.

Ubuntu has never seemed to take security particularly seriously. So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them.

> So yes shipping a CA known to have intentionally issued false certificates is very on-brand for them. Did TrustCor turn out to have done that? The last time I checked in on that, the distrust was mainly founded on some not-very-trustworthy behavior involving spyware in a related company within the same corporate umbrella. EDIT: Link to the rationale for distrust from Mozilla ... https://groups.google.com/a/mozilla.…

The removal of Symantec was a bit questionable as well. There is reason for strictness here, but I don't think having used their certs a bit longer was a relevant security threat at all.

Trustcor allegedly spread spyware, which I do think makes anyone untrustworthy. But it should be checked if allegations can be confirmed.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#116

Post by tinus_hn »

usr1106 wrote: post #113
tinus_hn wrote: post #87

Earlier quoted context omitted.

Considering you basically can only get a certificate for a domain name that refers to a host (and offering an IP address for an unqualified domain name is an anomaly) I’d expect the required subject to be the hostname. But the RFC does not specify it: The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, some general rules for the decisions are:…

Thanks for the reference. But this does not seem to make sense. Email delivery is about interoperability. How can that be achieved if parties make their local decisions? P.S. As you probably guessed in my previous comment "3 months later" should of course have been "3 months earlier". Sorry about the mistake.

It’s delivering email, there is no way for the receiving site to state a certificate is required anyway. Traditionally it’s just a plaintext connection on port 25 and using and supporting STARTTLS is optional.

I suppose you could write up a way to specify this in DNS but it’d take decades to be implemented and you would have to deal with pushback from the snoops who I’m sure don’t mind they can peep into the email you receive.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#117

Post by jsmith45 »

siebenmann wrote: post #89
DethNinja wrote: post #65

Earlier quoted context omitted.

Do modern browsers check this though? It would introduce a large latency to each request, I bet none of the browsers do that. Moreover, Chrome removed the browser extension API for TLS certificate details, so it is not even possible to do CT log verification via extensions. Only way to do CT log verification would be by customising an existing TLS MITM software. As far as I’m aware no such solution exists at the mome…

Chrome and Safari require that TLS certificates include cryptographic promises of future log inclusion ('SCTs') from N trusted CT logs. As far as I know, neither of them actually contact the log's API endpoints to make sure that this has gone through, but in practice IMHO it's not much of a security gap for various reasons.

The SCT is a promise of the log to include the certificate (or pre-certificate, which is used for embedded SCTs) within a time window. The only way a cert could have a valid embedded SCT is to have actually sent the pre-certificate to the log in question.

The SCT contains a signature over some log related information (which is also included in the SCT itself) and everything in the pre-certificate except the signature and poison (which means everything in the real cert, except the SCTs and signature). This means the browser can reconstruct the signed data and verify the signature.

Thus the only way to have a valid SCT and not have at least the pre-certificate show up in the log (after the merge delay) is if the log operator/software messed up. For transparency purposes, a pre-certificate is basically as good as a full certificate, although if I recall correctly the CAs are also supposed to submit the full certificates too.

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#118

Post by usr1106 »

tinus_hn wrote: post #116
usr1106 wrote: post #113

Earlier quoted context omitted.

Thanks for the reference. But this does not seem to make sense. Email delivery is about interoperability. How can that be achieved if parties make their local decisions? P.S. As you probably guessed in my previous comment "3 months later" should of course have been "3 months earlier". Sorry about the mistake.

It’s delivering email, there is no way for the receiving site to state a certificate is required anyway. Traditionally it’s just a plaintext connection on port 25 and using and supporting STARTTLS is optional. I suppose you could write up a way to specify this in DNS but it’d take decades to be implemented and you would have to deal with pushback from the snoops who I’m sure don’t mind they can peep into the email yo…

I guess the support of TLS was added for confidentiality and integrity on untrusted networks. If you don't verify the certificate a MITM attack is possible. So what is the remaining benefit of using TLS?

Re: Linux Certificate Authority root stores have a too simple view of 'trust'

#119

Post by yrro »

bioemerl wrote: post #66

I hate the concept of certificate authorities in general. I wish we had a way to do robust security without them. The idea that you need the approval of one of these companies to publish to the web without a wall of alerts is just absurd.

If only Kerberos had been adopted as an alternative to TLS for securing have to traffic... things could have been so different (at least for the purposes of an organisation wanting to enable secure communications between its own clients and servers)
Post reply on HN