91–100 of 120 posts
Earlier quoted context omitted.
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.
Yes - I know - I'm responding to the accusation in the quote, which is not at all substantiated.
"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.
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.…
Earlier quoted context omitted.
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.
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 addit…
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.
Earlier quoted context omitted.
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 n…
Isn't there an implicit trust on DNS already for domain validated certificates?
Earlier quoted context omitted.
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 n…
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 fo…
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.
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 som…
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.
Earlier quoted context omitted.
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 fo…
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 .
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.
Earlier quoted context omitted.
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 .
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 quest…