[HN Gopher] Linux Certificate Authority root stores have a too s...
___________________________________________________________________
Linux Certificate Authority root stores have a too simple view of
'trust'
Author : pabs3
Score : 194 points
Date : 2022-12-06 07:51 UTC (15 hours ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| jamespwilliams wrote:
| Even when Mozilla does fully remove stuff from their root store,
| in some cases it has taken distros a year+ to ship the updated
| version
|
| Not to mention stuff like this:
| https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+b...,
| where Ubuntu just unilaterally reverted Mozilla's removal of a
| cert in their package, because it was breaking nuget... Note that
| this was early 2021 -- Mozilla removed Symantec from their trust
| store in October 2018!
|
| In general it just seems like a bit of a mess.
| nsajko wrote:
| Isn't that just Ubuntu being idiotic as usual?
| cmeacham98 wrote:
| 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.
| ilyt wrote:
| The more I see it the more I think Ubuntu's "job" is "take
| a sensible Debian distribution and just fucking break shit
| in it"
| jefftk wrote:
| That may or may not be the case, but this incident is not
| evidence for it, since Debian did the same thing. See
| upthread: https://news.ycombinator.com/item?id=33879202
| mdeslaur wrote:
| Oh no, our terrible secret is out! :)
| no_time wrote:
| Their strong point has always been design and branding. I
| love their fonts and a few years ago they were the only
| ones with a patched libfreetype that didn't make your
| eyes bleed.
|
| As for engineering decisions, let's just say better stick
| with debian on anything non-desktop.
| jeltz wrote:
| The only issue with Debian is if you want the latest
| version of some application, e.g. Firefox then installing
| it is far from a nice experience. And Debian testing is
| quite unstable (I run it on my laptop so I know).
|
| Love it for my servers but it is not very convenient for
| the desktop.
| chungy wrote:
| Flatpak exists; Nix exists; Guix exists. All of them make
| it easy to have newer software without caring about your
| Debian package versions.
| actionfromafar wrote:
| I wish Debian would release 20.04 LTS, 22.04 LTS and so
| on.
|
| That is the big feature of Ubuntu for me. Can set in my
| calendar when it's time to migrate services to the next
| version.
| lmm wrote:
| There are other issues with Debian. They will radically
| rearrange upstream software to follow their own standards
| (e.g. try using Tomcat on Debian sometime). This is bad
| enough when they apply it to regular software, and
| downright insane when they do the same thing for
| security-critical software. It predictably caused quite
| possibly the worst general-purpose OS bug in history
| (their SSL key generation one). They did not change their
| policy in response to that incident and see nothing
| wrong.
| pferde wrote:
| I have been running Debian Stable on my
| (gaming/coding/general use) desktop and on my work laptop
| for close to a decade now, and I have had very few
| problems, things just work. The last problem of "too old
| system libraries" nature I remember was maybe 5 years
| ago, when Steam client did not work because of too old
| glibc, but one Debian release later the problem was gone.
|
| I don't think it's as bad as most people think it is,
| nowadays.
| NovemberWhiskey wrote:
| > _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.org/g/dev-security-
| polic...
|
| excerpt: _" There is no evidence of TrustCor mis-issuing
| TLS or SMIME certificates."_
| cmeacham98 wrote:
| I was referring to Ubuntu shipping Symantec.
| hamburglar wrote:
| You're 100% right. They were unable to convince the right
| folks that they were trustworthy, and they appear to be
| in a prime position to abuse misplaced trust due to some
| fundamental conflicts of interest, but "known to have
| intentionally issued false certificates" is a false
| accusation.
| Fatnino wrote:
| To be removed, a CA just needs to show it is not worthy
| of trust.
|
| TrustCor met this requirement and got removed.
|
| Other CAs removed in the past also showed they are
| unworthy of trust, but in even more blatant ways.
| NovemberWhiskey wrote:
| Yes - I know - I'm responding to the accusation in the
| quote, which is not at all substantiated.
| Fatnino wrote:
| You misunderstood the accusation as being leveled against
| TrustCor when in fact the commenter was referring to
| Symantec
| mdeslaur wrote:
| > Ubuntu has never seemed to take security particularly
| seriously.
|
| I haven't heard that before. Care to elaborate what we do
| that makes you believe we don't take security seriously?
| [deleted]
| rlpb wrote:
| The bug report quite clearly states that Ubuntu followed the
| same revert that Debian did: "The Debian ca-certificates
| package removed this CA for both TLS (expected) and other
| uses (like timestamping) (unexpected). Trust was added back
| in a subsequent update."
|
| So no, Ubuntu didn't do anything wrong or unreasonable here.
|
| Edit:
|
| Here's the Debian revert that Ubuntu followed:
|
| ca-certificates (20200601~deb10u2) buster; urgency=medium ...
| Revert Symantec CA blacklist (#911289). Closes: #962596,
| #968002.
|
| From https://tracker.debian.org/media/packages/c/ca-
| certificates/...
| zenexer wrote:
| Interestingly, this time around, Ubuntu actually removed
| TrustCor from its root store almost immediately. That
| technically means that some certificates that should still be
| valid are now invalid on Ubuntu.
| rlpb wrote:
| > ...where Ubuntu just unilaterally reverted Mozilla's removal
| of a cert in their package, because it was breaking nuget
|
| It wasn't unilateral. Ubuntu followed Debian here, who did the
| same revert: https://tracker.debian.org/media/packages/c/ca-
| certificates/...
| zzm wrote:
| For those who are interested in more details about this, I
| wrote a paper that examines the delay and trust discrepancies
| between Mozilla and its derivative root stores (e.g., Linux,
| NodeJS, etc.): https://zanema.com/papers/imc21_roots.pdf
| mdeslaur wrote:
| > where Ubuntu just unilaterally reverted Mozilla's removal of
| a cert in their package, because it was breaking nuget... Note
| that this was early 2021 -- Mozilla removed Symantec from their
| trust store in October 2018!
|
| Mozilla actually removed the certs from their trust store in
| February 2021:
| https://hg.mozilla.org/projects/nss/rev/9718a34c84429b1e5dc6...
|
| Debian and Ubuntu had jumped the gun by a few weeks and there
| were certificates still being used that had not been renewed
| yet, so we had to revert temporarily.
|
| Mozilla had used the CKA_NSS_SERVER_DISTRUST_AFTER tag with a
| date to specify newer certs issued by that CA were not valid,
| but as the article above states, the crypto libraries being
| used in Linux don't support that kind of thing.
| jamespwilliams wrote:
| My mistake, I misread "Removal/distrust" in the timeline of
| https://wiki.mozilla.org/CA/Symantec_Issues as meaning
| removal from the trust store.
|
| I can't edit my comment now, but hopefully your correction
| here gets upvoted and is visible to people.
| pifm_guy wrote:
| Note that if you don't trust the CA, you shouldn't trust the
| issue date either. A dishonest CA would backdate any certificates
| signed.
|
| So having an arbitrary cutoff date in software seems unnecessary.
| If you still trust the CA to behave honestly for now, then you
| can simply instruct them not to issue any more certificates.
|
| If you don't trust the CA to act honestly for now, then you need
| to remove them from the trust store entirely (and maybe use a
| whitelist of previously issued certificates if you believe they
| were trustworthy in the past).
| cbzoiav wrote:
| Trust isn't black and white. Removing the cert entirely breaks
| existing applications which comes with its own risk.
|
| Using TrustCor as an example there is no hard evidence they
| have done anything wrong. Is that enough to justify cutting off
| their clients?
|
| What if one of those clients is a major antivirus vendor etc.
| with pinned certs in their software? Or road signs etc.?
| wbl wrote:
| Clients? They only had one client for web certs ever, a
| dynamic DNS service.
| leni536 wrote:
| If they pinned a cert in the application, why use the root
| store at all?
| koolba wrote:
| > Note that if you don't trust the CA, you shouldn't trust the
| issue date either. A dishonest CA would backdate any
| certificates signed.
|
| Dare I say it, but isn't this the exact problem solved by a
| chain of published certificate hashes?
|
| This is pretty much how certificate transparency lists (CTL)
| work too. It's like a blockchain without any proof of work or
| stake, just a merkle tree of hashes that ensures you cannot
| retroactively insert one with an older date.
|
| > ... (and maybe use a whitelist of previously issued
| certificates if you believe they were trustworthy in the past).
|
| Which I guess would be only trusting CTL published certificates
| up until the last point of trust.
| cmeacham98 wrote:
| You're not describing a blockchain here, but rather a Merkle
| tree (also called a hash tree). Or, (because the tree-like
| behavior is actually undesirable here) just an array of
| hashes.
|
| Just because something has a set of hashes in a roughly
| linear timeline doesn't make it a blockchain. For example,
| git isn't a blockchain either.
| notpushkin wrote:
| Clearly you disagree on the definition of the word
| "blockchain". Let's consult Wikipedia, a trustworthy source
| on anything [1].
|
| > A blockchain is a type of distributed ledger technology
| (DLT) that consists of growing lists of records, called
| blocks, that are securely linked together using
| cryptography. [...] Since each block contains information
| about the previous block, they effectively form a chain,
| with each additional block linking to the ones before it.
| Consequently, blockchain transactions are irreversible in
| that, once they are recorded, the data in any given block
| cannot be altered retroactively without altering all
| subsequent blocks.
|
| So far this is exactly what's going on in the Certificate
| Transparency scheme.
|
| > Blockchains are typically managed by a peer-to-peer (P2P)
| computer network for use as a public distributed ledger,
| where nodes collectively adhere to a consensus algorithm
| protocol to add and validate new transaction blocks.
|
| This part deviates from CT (no validation is going on in
| real time, browsers usually just have a few hardcoded CT
| logs and a custom rule on when a certificate is trusted).
| But note the word "typically": this doesn't mean CT can't
| be called a blockchain just because it doesn't use PoW, PoC
| or any other consensus algorithms conventional in the
| cryptocurrency world.
|
| Calling Git a blockchain is arguably more of a stretch
| because the purpose of keeping the old records intact is
| not what we use Git for. Maybe you can build blockchain on
| Git though? (edit: OF COURSE YOU CAN
| https://github.com/CouleeApps/git-power)
|
| ---
|
| [1]: /s
| cmeacham98 wrote:
| You missed very important words. A blockchain is (by your
| own definition) a "distributed ledger".
|
| Given you like Wikipedia so much, here's their definition
| of what a ledger is
| (https://en.wikipedia.org/wiki/Ledger)
|
| > A ledger is a book or collection of accounts in which
| account transactions are recorded.
|
| You'll find similar definitions on non-Wikipedia sources
| as well.
|
| Thus, if it doesn't have accounts and transactions
| between them, it isn't a ledger and thus isn't a
| blockchain.
| bawolff wrote:
| You can trust a CA to be honest but not competent. In which
| case an orderly transition makes sense
|
| After all, backdating certs is really obvious in a world with
| cert transpatency, and you can full distrust immediately if
| they do that.
| jamespwilliams wrote:
| See https://news.ycombinator.com/item?id=33877290
| usr1106 wrote:
| It was not said at all why that CA lost Mozilla's trust. If
| their key were leaked of course backdated certificates could be
| produced at any time.
| kibwen wrote:
| See https://www.theregister.com/2022/12/02/mozilla_microsoft_
| tru... for information about the revocation. It's not about a
| leak, it's about allegations of malfeasance.
| jwilk wrote:
| Related:
|
| https://news.ycombinator.com/item?id=33810755 ("Mozilla,
| Microsoft yank TrustCor's root certificate authority", 5 days
| ago, > 350 comments)
| jannic wrote:
| > Certificates signed by TrustCor that were issued before
| December 1st will still be trusted (for now); certificates issued
| on December 1st or later will not be.
|
| How does this work? If TrustCor is no longer trusted, what keeps
| them from creating certificates which claim to be issued before
| December 1st, even after that date?
| AceJohnny2 wrote:
| Certificate Transparency [1]: Public logs of issued
| certificates.
|
| [1] https://en.wikipedia.org/wiki/Certificate_Transparency
| daveoc64 wrote:
| Assuming the untrusted and unreliable CA actually follows the
| rules and publishes things to the CT log.
| pimterry wrote:
| If you don't then the certificates usually aren't usable at
| all. All modern browsers should reject certs from any root
| CA if the cert isn't correctly included in a CT log.
| est31 wrote:
| Firefox doesn't:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1281469
|
| (But it's the only browser that doesn't support CT)
| DethNinja wrote:
| 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 moment.
|
| Certificate system is actually rather insecure, and
| although solutions are possible to develop, nobody has
| taken time to do it.
| siebenmann wrote:
| 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.
| nmjohn wrote:
| > Do modern browsers check this though? It would
| introduce a large latency to each request, I bet none of
| the browsers do that.
|
| Yes they do. Only firefox doesn't.
| pimterry wrote:
| > what keeps them from creating certificates which claim to be
| issued before December 1st, even after that date?
|
| See https://groups.google.com/a/mozilla.org/g/dev-security-
| polic... for the actions proposed depending on how the TrustCor
| situation plays out:
|
| > If there is reason to believe that the CA has mis-used
| certificates or the CA backdates certificates to bypass the
| distrust-after settings, then remove the root certificates from
| Mozilla's root store in an expedited timeline, without waiting
| for the end-entity certificates to expire.
|
| Right now, they're being slowly removed for poor behaviour in
| general, but there's no direct evidence of abuse of CA powers.
| If any clear evidence of that appears in future, including
| backdating certificates, then they'll be completely removed
| from the trust store immediately.
| est31 wrote:
| There are definitely limitations in GNU/Linux root stores. E.g.
| to my knowledge it's impossible to distinguish between the root
| coming from the distro vs coming from a custom configuration,
| e.g. for corporate MITM proxies. So you can't e.g. require SCTs
| to be present for former but not require them for latter, like
| how Chrome does it for example.
|
| Also, is this additional information even published by Mozilla in
| a standardized format or if it's just put somewhere into Firefox
| source code?
|
| Also note that, given how Firefox doesn't implement SCT
| requirements, TrustCor could also just back-time certificates. So
| Firefox has similar vulnerability properties as users of distros
| that haven't removed TrustCor as a CA.
|
| So ideally you would also make it possible to distinguish between
| OS provided and custom configured certificates, to allow
| libraries to check for SCTs _at all_. Otherwise you haven 't
| gained much from the additional information of limiting a CAs
| ability to issue new certificates.
| mananaysiempre wrote:
| > is this additional information even published by Mozilla in a
| standardized format or if it's just put somewhere into Firefox
| source code?
|
| Not really a single format, but they do write it down:
|
| https://wiki.mozilla.org/CA/Additional_Trust_Changes
| raggi wrote:
| Correct, it is too simple.
|
| The problem is very broad though. CA/B forum is very effective
| for what it does, but equivalents for other uses are less so.
|
| Most places crib and slightly rework the Mozilla CA pack with
| highly variable levels of maintenance and accuracy.
|
| macOS and windows have richer models, but integrations are often
| poor. For many years homebrew had code that seeded an OpenSSL
| compatible pem with explicitly untrusted certs on macOS.
|
| We could do with something as effective as CA/B that covers more
| use cases. Along with it should come some amount of reference
| implementation material and regularly updated test vectors.
|
| Essentially we need the client side of let's encrypt, and it
| can't be let's encrypt that does it.
| resters wrote:
| This is so obvious and so "acceptable" even in security circles
| that I have thought for a while that it is a tacit
| acknowledgement that state actor attacks are "OK".
|
| Trusted CAs should be one of the most scrutinized and
| controversial aspects of system configuration, and OSes should
| support a variety of trust models.
|
| I've run this by a few security "experts" and the response has
| always been that it's a UX issue and the goal is to have websites
| load correctly without the user seeing and complaining about
| opaque security errors.
|
| It's quite absurd. The rewards for compromising a single CA are
| so great that surely most state actors have succeeded in doing it
| at least once.
| ilyt wrote:
| By "Linux" it really means any SSL lib that just uses system's "a
| dir with a bunch of CAs" approach.
|
| That approach _is_ nice for ops (don 't have to worry about
| commands to add/remove certs, just drop files into dir) and
| relatively performant (just one read on cert's fingerprint file
| name in modern distros).
|
| I think simplest one would be just adding meta file with a bunch
| of conditions ?
|
| While we're at it, allow the certs to be imported only for
| certain domain, so ops can, for example, import internal CA of
| their partner but limit it to only partner's domains
| yrro wrote:
| Every TLS library will also have to implement it.
|
| I hate to say it but... I want a systemd-certd that TLS
| libraries can call into saying 'verify this please' and then
| the logic for verifying trust path, validity, revocation status
| etc can be done in one place, consistently and correctly.
| hulitu wrote:
| > Linux Certificate Authority root stores have a too simple view
| of 'trust'
|
| Ok. Which CA should i trust ? And why ?
| psanford wrote:
| I'm surprised systemd hasn't solved this problem already.
| egberts1 wrote:
| I also have a problem with Debian method of compiling a list of
| CAs.
|
| ca-certificates package rolls in Java and Mongo CAs as well as
| Mozilla.
|
| Their tools to do that is also not very clear on how they are put
| together the ca-certs either from 32 different subdirectories.
|
| A (ahem) short write up that also includes suggestion of
| improvements. Debian bug has been filed but the Debian maintainer
| does not seem to be interested in moving this along.
|
| https://egbert.net/blog/articles/ca-certificates-rebuild-on-...
| wjconrad wrote:
| The whole CA model is broken by the OS and browser "every CA is
| trusted for every use case across any TLD or IP range" without
| any sort of context of scope except dates. Why is it every single
| one of the 30+ CA roots that Mozilla or Google trusts can issue
| .com domain certs, not just ones for their local TLDs or local IP
| ranges which would dramatically limit the blast radius for a
| breach? Do you really trust that some of these CAs aren't issuing
| sketchy certificates to their local intelligence agencies, as one
| of the Middle Eastern CAs was caught doing? To pick on Chrome
| since they're the biggest, they've got Turkish and Greek, Chinese
| and Hong Kong and Taiwanese CAs in there, how do you think people
| in those countries feel about trusting TLS certs from the other
| sides of disputes? The high bar to establish a trusted CA root in
| terms of cybersecurity capital investments and audit requirements
| means there's very few developing country root CAs. What if
| LacNIC or AfriNIC could run their own CA roots, but they were
| scoped only to work on IPv4 or IPv6 blocks they managed?
| Meanwhile, in a corporate enterprise use case, how about being
| able to trust a CA only to issue certs for my dev and test .local
| domain, possibly with a scoped range of IPs? At that point, I
| don't care if that internal CA gets compromised and an attacker
| issues fake .com certs, my OSes and browsers I installed the CA
| on would know they're only valid for foobarlab.local on 10.10.x.x
| - 10.100.x.x or some IPv6 equivalent.
| wolrah wrote:
| X.509 technically does support a parameter in CA certificates
| called Name Constraints which allows them to be restricted to
| issuing certificates within a specific set of names.
| Historically this feature has not been well supported though it
| seems like the browsers have added it more recently.
|
| Netflix for example uses this feature internally and built a
| test suite: https://netflixtechblog.com/bettertls-c9915cd255c0
|
| I agree wholeheartedly that this feature should be used more
| widely to restrict CAs where practical, obviously limiting
| government CAs to their respective ccTLD(s) seems like an easy
| one. Personally I'd also like to see this extended to allow for
| a domain owner to get a private CA certificate issued for their
| domain(s) which can then be used to issue individual
| certificates within that/those domain(s) as a more secure
| alternative to wildcard certificates.
|
| There is no substantial technical reason this couldn't be done,
| just a lot of older software that wouldn't understand the
| restrictions and could either reject the certs entirely or
| consider them valid even if they shouldn't be.
| GauntletWizard wrote:
| There's been a ton of discussion on what constitutes "Trust" in
| the modern web world of late, but very little of it seems to have
| borne fruit. One minor advance Kubernetes formally adopting a
| proposal for a trust anchor[1][2]; Which is to say, a set of CAs
| that are equivalent.
|
| Someone mentioned earlier that "At least we all agree that
| they're PEM and DER Formatted", to which someone mentioned that
| Java had it's own world, and ugh... That's a whole thing. Java
| has moved _backwards_ in recent years; Their old Keystore format
| was useful for a single context, in that you could say "Here's
| the keystore for communicating with Google, it's got a list of
| public keys to trust and list of private keys that we are"; And
| that more or less worked with the tooling. The move to PKCS#12
| moves to one unified bag with all your private and public keys
| mixed in and you have to specify which are which, which is
| theoretically better but in practice represents a configuration
| nightmare over just specifying separate files with the trusted
| CAs, our public keys, and our private keys. You still can't
| deliver a single PKCS12 file to all of your servers as a whole,
| because SafeBags aren't; They're DES encrypted, which is to say:
| Not at all[3], but at least it's clear that they aren't.
|
| The right answer is basically what Cloudflare[4] and then Google
| Cloud[5] tried to do and failed: Create a single file-format for
| "Public Key and accompanying Private Key", and make it easy to
| extract the public key from many of those to form a list of CAs.
|
| [1] https://github.com/kubernetes/enhancements/pull/3258 [2]
| https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/ [3]
| The actual Java recommendation is to use a single well-know DES
| key for all PKCS12 operations, which obviates all of the stated
| and even best-case-steelman arguments for why Java made this
| change, to the point that anyone defending the decision should
| probably not be trusted and the proposers were more likely
| malicious than stupid. That's a rant for a different post. [4]
| https://github.com/cloudflare/cfssl [5]
| https://cloud.google.com/docs/authentication/application-def...
| 1vuio0pswjnm7 wrote:
| The choice of what CA certificates to "trust" should, optionally,
| in some circumstances, be the computer owner's decision. For
| example, when the issue with TrustCor was made public, Android
| users could disable the TrustCor certificates. Whether that
| actually works, I cannot say. The certificates are probably still
| there, not removed, not deleted. Same goes for disabling
| certificates within the browser. This is likely an illusion of
| owner control. That a system of "trust" is provided by a company
| that many _do not trust_ is comical by any objective measure.
|
| Personally I rely on a TLS forward proxy that uses the
| certificates in /etc/ssl/certs, as represented by ca-
| certificates.srt. Thus, I can remove certificates, regenerate ca-
| certificates.crt and effectively deny certificates that the
| advertising-supported browser company chooses to accept.
|
| Web browsers from advertising companies, or organisations that
| subsist from advertising company profits, like Mozilla, ignore
| /etc/ssl/certs. They do not allow computer owners to remove and
| delete CA certificates. They refuse to allow the computer owner
| to add their own choices for CA certficates, e.g., certificates
| generated by the owners themselves, without forcing annoyances on
| the owner to try to discourage such owner control.
|
| The "CA system" should be accountable to computer users, not
| advertising companies, or organisations that depend on
| advertising company profits, not "tech" companies. As it stands,
| computer users are locked out of the decision-making process with
| respect to CA certificates. The CA system has become a tool of
| "tech" companies that seek to commercialise every aspect of the
| internet. The fact is, much of the data "protected" by TLS is
| data belonging to or about computer users that is being sent to
| "tech" companies without the user's informed consent. In effect,
| TLS is used to stop the computer owner from seeing what data is
| leaving their computers and networks.
|
| We need a CA system that is governed by computer users, not
| "tech" companies. All computer owners should not be discouraged
| from trusting themselves. The CA certificates computer owners
| generate should not be discriminated against in favour of ones
| approved by "tech" companies. Someone is no doubt going to reply
| to this with something about LetsEncrypt. But that is not letting
| users trust themselves. It requires users to rent domain names
| and ask to be trusted by LE. It is part of the existing CA system
| where users must (cf. may) let third parties decide who is
| trustworthy. curl -4o 1.csv https://ccadb-
| public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat
| grep TrustCor 1.csv
| Blue111 wrote:
| CAs have too much power ...
| bioemerl wrote:
| 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.
| Ajedi32 wrote:
| IMO the correct solution would be one based on DNS. (E.g.
| DNSSEC+DANE or something similar.) Right now (unless we bring
| back extended validation) the entire purpose of certs on the
| web is to tell browsers what private key is associated with a
| domain. It's silly to involve completely unrelated third
| parties in that process when you could just get the information
| from the authoritative source (DNS) directly.
| tptacek wrote:
| No, it's not. One of the important benefits you get from this
| layer of indirection is revocability of trust. CAs can be
| removed from browsers (Google and Mozilla have both removed
| some of the largest CAs), and DNS roots cannot. Browsers and
| root store operators can pressure CAs to adopt safeguards
| like Certificate Transparency --- they simply won't trust CAs
| that don't. There is no DANE Transparency in part because
| nobody can pressure TLD operators to adopt it.
|
| There are a whole variety of other problems with a DNS PKI,
| and with DNSSEC in particular, but when we're talking about
| issues like this thread, revocability is the the big thing.
| Ajedi32 wrote:
| You raise some good points. There are definitely some
| benefits to having a diversity of different trust anchors
| rather than just one. The problem though is that the way
| things are currently set up that diversity is somewhat of
| an illusion; DNS is still a central point of failure for
| all CAs (e.g. via the ACME DNS challenge), and each
| individual CA is also a single point of failure unto itself
| (a CA can issue certs for any domain, not just those of its
| customers).
|
| I also think you may be underestimating the amount of
| leverage browser developers have over DNS, should they
| choose to exercise it. If Google, Apple, Microsoft, and
| Mozilla all agreed tomorrow that they wanted to migrate the
| web to a new set of DNS root servers they could probably do
| it. (Though yes, it would be a huge ordeal for everyone
| involved.) The real reason we haven't gotten DANE
| transparency (or anything similar) is simply because it
| hasn't been a priority for browsers. (Why pressure DNS
| roots to improve a system that you aren't even using in the
| first place?)
|
| Still, I can't deny what you're saying. The CA system is
| probably a lot more flexible than a naively designed DNS-
| based system would be. I'll have to think about that a bit
| more. Maybe it would make sense to have something like SCTs
| in the certificate transparency system, where a number of
| different independently operated organizations all have to
| sign off on the validity of each cert _in addition_ to the
| DNS operator that actually issued the certificate. That way
| you'd get the benefits of diversified trust anchors without
| the downside of having hundreds of distributed single
| points of failure.
| tptacek wrote:
| The browsers absolutely cannot migrate to a different set
| of DNS roots. It's only been in the last 5-10 years that
| they've managed to get as much control over the root
| programs as they have now, and there was a lot of behind-
| the-scenes drama involved in that. And TLS certificates
| are, when you come right down to it, _a browser feature_.
| Ajedi32 wrote:
| That was just a hypothetical example to illustrate how
| much power browser vendors have over the web; they
| wouldn't need to _literally_ migrate to a different DNS
| root in order to effect change in this space, but I
| maintain they absolutely could go that far (again,
| hypothetically) if they all agreed and there were a
| sufficiently compelling reason.
|
| Browsers always had full control over CA root programs,
| it's just a question of how willing they were to actually
| assert themselves in that fashion. I agree they've become
| more bold about that over the years, but what Mozilla
| just did to TrustCo was always an option for the major
| browser vendors, both legally and technically (or at
| least since automatic updates became a thing). DNS is
| also effectively a browser feature these days, as
| evidenced by all the browsers suddenly supporting things
| like DNS-over-HTTPS despite host operating systems
| lacking support. Given a sufficiently smooth transition
| path for users and website operators, browser vendors
| could collectively decide to alter their DNS
| implementations in pretty much any way they want.
| tptacek wrote:
| I don't think this is really true at all, and I think it
| underestimates (significantly) the amount of behind-the-
| scenes work that went into the current WebPKI situation
| with activist root programs. I don't think there's any
| reason at all to believe that browsers would have similar
| success governing a DNS PKI, and there are specific
| reasons --- evidence, even --- to believe they wouldn't.
| We can go round and round on this stuff, but I feel like
| I'm repeating myself at this point.
| Ajedi32 wrote:
| Like I said, I agree with you that a naive, purely DNS-
| based PKI would be less flexible in that regard. That was
| a good point, and well noted.
|
| However, the current status quo is sort of ignoring the
| big DNS-shaped elephant in the room. You can build all
| the validation and transparency solutions you want on top
| of the CA system, but it's still fundamentally dependent
| on the security of a DNS system that currently requires
| no cryptographic assurances that the records the CAs are
| validating against are actually correct.
| ciupicri wrote:
| > If Google, Apple, Microsoft, and Mozilla all agreed
| tomorrow that they wanted to migrate the web to a new set
| of DNS root servers they could probably do it.
|
| They're already pushing DNS over HTTP.
| planede wrote:
| Isn't there an implicit trust on DNS already for domain
| validated certificates?
| tptacek wrote:
| Yes, there is. But all certificate issuance is
| cryptographically logged, and DNSSEC signatures aren't.
| You can spot and react to misissuance of certificates.
| ayende wrote:
| There is no API to actually handle trust. If you are asking
| `curl` or `openssl` to verify the chain, it needs to read it from
| somewhere. By convention, there is `OPENSSLDIR`, for example.
|
| But that just tells us where the root certs are, not much more.
| In the API, I load the root CAs and check validity of the cert,
| nothing beyond that.
|
| And I can do that in multiple different TLS engines.
|
| Given that there is no API for this, all the TLS engines need to
| re-implement this logic. Hell, in most cases, even things like
| validity range checks are handled by the applicative logic.
|
| On Windows, there is the builtin TLS API `schannel` which means
| that you have a lot more structure / order in this. Including the
| ability to express those sort of details.
|
| There is another aspect, as well. You need to be able to
| _express_ those issues as errors, otherwise the user is going to
| be left with a broken box and no idea what is going on.
| kelnos wrote:
| > _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.
| ak217 wrote:
| > 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.
| Ajedi32 wrote:
| 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?".
| ak217 wrote:
| 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.
| blibble wrote:
| > 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 :(
| mike_hearn wrote:
| 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.
| firebird84 wrote:
| 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.
| GauntletWizard wrote:
| 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
| mike_hearn wrote:
| 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.
| throw0101c wrote:
| 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/
| jeltz wrote:
| 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.
| cesarb wrote:
| 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.
| tinus_hn wrote:
| There's a surprising amount of old Unix software like Postfix,
| that by default doesn't actually validate certificates.
| gjvc wrote:
| Postfix is not old. Sendmail is old :-)
| usr1106 wrote:
| 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
| just not defined for SMTP over TLS?
| tinus_hn wrote:
| 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:
| - A SMTP client would probably only want to authenticate an
| SMTP server whose server certificate has a domain
| name that is the domain name that the client
| thought it was connecting to.
|
| However in the case of Postfix there's also the matter of
| connection to services like an ldap server to check things.
| In that case it'll also by default happily connect to an
| ldaps service with a self signed, expired certificate.
| dontbenebby wrote:
| If you reflect on trusting trust too long, you'll drive
| yourself mad.
| cryptonector wrote:
| If you can name a set of trust anchors (e.g., with an
| environment variable, in a configuration parameter, in a
| command-line argument, as a function/method parameter), then
| you've got the power to specify what to trust contextually. The
| problem is that a) apps usually don't give you such a control,
| and b) the names of these sets of trust anchors have to be
| meaningful to users.
|
| (b) is a pretty tough problem!
| e12e wrote:
| > 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 validity, or rules to sign/not-sign. One might
| set a 48h lifetime, and run a crown job every night - allowing
| for "dynamic" "revocation" (cert expiry).
|
| Not sure if this would work out of the box though - I have not
| looked that deep into ca and ca trust.
| mike_hearn wrote:
| 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 article wants is simple - nothing
| stops an untrusted CA just issuing certificates that claim to
| have been issued before the cutoff, so it seems pointless.
| Browsers have ways to tackle that like Certificate
| Transparency or crawling the web to try and identify every
| extant cert, but most apps don't use that.
| xg15 wrote:
| Linux root stores could piggyback on the browsers' efforts
| here though. The attack scenario you described was sensible
| in the past, so it didn't make sense for non-browser
| clients to go ahead with "trust until".
|
| However, now CAs can't really do this anymore, because - as
| you say - they'd risk immediate exclusion from browsers if
| this is detected via CT analysis. So Linux distros can
| actually benefit from CT and browser's impact in the CA
| space in an indirect manner.
|
| There is definitely a power imbalance though. E.g., even if
| a distro implemented "trust until", they could not
| realistically make their own rules that are stricter than
| what browsers do: CAs could backdate certs so they get
| accepted by the distro, but if browsers consider the CA
| fully trusted, they might not care about the backdated
| certificates.
| deathanatos wrote:
| Yeah, TFA seems to make a good argument for a libca-
| certificates, or so.
|
| > _There is another aspect, as well. You need to be able to
| express those issues as errors, otherwise the user is going to
| be left with a broken box and no idea what is going on._
|
| TLS libraries are terrible at this. Part of it is C: the
| "integer is the only error type you'll ever need" cannot convey
| the necessary context, such as _which_ cert is the problem.
|
| Having a library might also help with path building bugs. I've
| seen bugs in both OpenSSL and GnuTLS in building a correct
| path, and both just from when the ISRG cross-sign expired.
|
| ... and maybe a more complicated data structure in /etc/certs
| (or whatever the path is) will keep prying vendors out. I've
| seen a lot of people make out of band changes there, and I
| would suspect those qualify as "undefined behavior", but
| OpenSSL's docs don't seem to answer the question of "what
| happens if vendors do random stuff?" (Like drop non-CA certs
| into the list of CAs, or don't update the symlinks that seem to
| form an index...)
| kelnos wrote:
| > _TLS libraries are terrible at this. Part of it is C: the
| "integer is the only error type you'll ever need" cannot
| convey the necessary context, such as which cert is the
| problem._
|
| Not really; I mean, sure, the validation function will
| probably rely on returning an integer error code, but there's
| no reason that the API couldn't also provide a function to
| retrieve the certificate chain at hand, where an application
| could walk the chain backwards to the root and figure out the
| last one (er, or first one, depending on how you look at it)
| that isn't trusted.
|
| Whether an application would choose to go to the trouble to
| make use of these APIs is another matter, of course. At any
| rate, from perspective of the average user, TLS errors are
| already not so easy to understand, so giving detailed
| information in this case might not be all that helpful
| anyway. Just a simple "we don't trust this website, so you
| shouldn't either" is about as much as most users would
| understand, probably.
| ayende wrote:
| That assumes that the application even _know_ to check the
| "only valid if issued before" flag.
| Timshel wrote:
| On the "Some Linux distributions may choose to drop TrustCor
| entirely from their CA bundle, which is a reasonable decision." -
| https://bugs.launchpad.net/ubuntu/+source/ca-certificates/+b... -
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023945
| LeoPanthera wrote:
| I wonder if it would be possible to configure a browser (or an
| entire OS) to use TOFU on the CA level.
|
| "Hey, this page uses a cert signed by $THIS_CA, would you like to
| trust it?"
|
| Then instead of shipping whitelists, you could ship blacklists,
| which is presumably simpler and more future proof.
| pionar wrote:
| How would I know if I should trust $THIS_CA? That's why it's
| good that the browser vendors do this, they know better than me
| which ones are trustworthy.
| LeoPanthera wrote:
| This whole story seems to prove that that isn't true.
| Hizonner wrote:
| Any "consistent systemwide policy" is a too-simple view of trust.
| There are almost never two different applications that should
| trust the same authorities.
| heinrich5991 wrote:
| https://web.archive.org/web/20221205015024/https://utcc.utor...
| wjconrad wrote:
| The whole CA model is broken by the OS and browser model of
| "Every CA is trusted for every use case across any TLD or IP
| range" without any sort of context of scope except dates. Do you
| REALLY trust that some of these CAs aren't issuing sketchy
| certificates to their local intelligence agencies, as one of the
| Middle Eastern CAs was caught doing? Why is it every single one
| of the 30+ CAs that Mozilla or Google trusts can issue .com
| domain certs, not just ones for their local TLDs or local which
| would dramatically limit the blast radius for a breach? To pick
| on Chrome since they're the biggest, they've got Turkish and
| Greek, Chinese and Hong Kong and Taiwanese CAs in there, how do
| you think people in those countries feel about trusting TLS certs
| from the other? The high bar to establish a trusted CA in terms
| of cybersecurity capital investments and audit requirements means
| there's very few developing country CAs. What if LacNIC or
| AfriNIC could run their own CAs, but they were scoped only to
| work on IPv4 or IPv6 blocks they managed? Meanwhile, in a
| corporate enterprise use case, how about being able to trust a CA
| only to issue certs for my dev and test .local domain, possibly
| with a scoped range of IPs? At that point, I don't care if that
| internal CA gets breached and an attacker issues fake .com certs,
| my OSes and browsers I installed the CA on would know they're
| only valid for foobarlab.local on 10.10.x.x - 10.100.x.x or some
| IPv6 equivalent.
| nmjohn wrote:
| > Do you REALLY trust that some of these CAs aren't issuing
| sketchy certificates to their local intelligence agencies, as
| one of the Middle Eastern CAs was caught doing?
|
| A decade ago, probably. Today, with CT logging being mandatory
| in most browsers? Much less likely.
| renonce wrote:
| 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"?
| upofadown wrote:
| The issue here seems to be that Mozilla/Google/Microsoft are the
| ultimate trust authorities for TLS but that is not reflected in
| how things are structured. If Mozilla/Google/Microsoft certified
| the current root trust authorities then an OS could just download
| the whole mess from Mozilla/Google/Microsoft and could check the
| validity of them on their own taking into account any
| revocations.
| dark-star wrote:
| Yesterday I have removed that certificate from all my Linux
| systems. So far I have not seen any impact in connectivity for
| any applications or websites I use.
|
| And even if, all I'd get is a "this site is not trusted" that I
| can manually override if required.
___________________________________________________________________
(page generated 2022-12-06 23:01 UTC)