12 ms·

The flipside of the same technical points is https://sslmate.com/blog/post/entrust_distrust_more_disruptive_than_intended https://sslmate.com/blog/post/entrust_

The flipside of the same technical points is https://sslmate.com/blog/post/entrust_distrust_more_disruptive_than_intended https://sslmate.com/blog/post/entrust_distrust_more_disrupti... where some non-browser clients don't handle this, or worse, handle it incorrectly.

tptacek 2y ago
Right; it's imperfect, as everything is. But of course, it's also a huge bit of leverage for the root programs (more accurately, a loss of leverage for CAs) in killing misbehaving CAs; those programs can't be blackmailed with huge numbers of angry users anymore, only a much smaller subset of users. Seems like a good thing, right?
- LegionMammal978 2y ago
  Only insofar as you trust the root programs to use their leverage responsibly, both today and in the medium-to-long-term future.
  - tptacek 2y ago
    The operators of the root programs control the browsers (and, in some cases, the operating systems!), so this doesn't make much sense.
    - LegionMammal978 2y ago
      Any leverage against the root programs in the form of angry users is also leverage against the browser devs, is it not? Either way you look at it, the root programs/browser devs receive less pushback and gain more autonomy. My biggest concern is long-term censorship risk. I can imagine the list of trusted CAs getting whittled down over the next several decades (since it's a privilege, not a right!), until it's small enough for all of them to collude or be pressured into blocking some particular person or organization.
      - tptacek 2y ago
        Your concern is that there will be... too few CAs?
        LegionMammal978 2y ago
        Yes. It would add another potential point of failure to the process of publishing content on the Web, if such a scenario came to pass. (Of course, the best-case scenario is that we retain a healthy number of CAs who can act independently, but also maintain compliance indefinitely.)
        tptacek 2y ago
        I don't know what to say; I think that's the first time I've heard that concern on HN. Thanks!
        throw_a_grenade 2y ago
        To add to this, EU's 2021 eIDAS (the one with mandatory trustlist) was a response to similar lack of availability. Contrary to what most HNers instincively thought it wasn't about interception: EC was annoyed that none of root programs is based in EU, and that causes 100% of trust decisions to be made on the other side of the Big Water. EC felt a need to do something about in, having in regard the fact that TLS certificates are needed for modern business, healthcare, finance etc., they have seen it as economy sovereignity issue. My point is, lack of options, aka availability, is (or may be perceived as) dangerous on multiple layers of of WebPKI.
        dadrian 2y ago
        No, eIDAS 2.0 was an attempt to address the fact that the EU is not one market in ecommerce, because EU citizens don't like making cross-border orders. The approach to solving this was to attach identity information to sites, ala EV certificates. The idea for this model came from the trust model for digital document signatures in PDFs. There are already plenty of CAs across the pond.
- Y_Y 2y ago
  > Right; it's imperfect, as everything is. Is this tautology helpful? For sure it's commonly used, but I honestly have a hard time seeing what information it conveys in cases like this.
dadrian 2y ago
Non-browser clients shouldn't be expected to crib browser trust decisions. Also, the (presumably?) default behavior for a non-browser client consuming a browser root store, but is unaware of the constraint behavior, is to not enforce the constraint. So they would effectively continue to trust the CA until it is fully removed, which is probably the correct decision anyway.
- DSMan195276 2y ago
  To me that's an odd position to take, ultimately if the user is using Mozilla's root CA list then they're trusting Mozilla to determine which certs should be valid. If non-browser programs using the list are trusting certs that Mozilla says shouldn't be trusted then that's not a good result. Now of course the issue is that the information can't be encoded into the bundle, but I'm saying that's a bug and not a feature.
  - dadrian 2y ago
    Mozilla’s list is built to reflect the needs of Firefox users, which are not the same as the needs of most non-browser programs. The availability/compatibility vs security tradeoff is not the same.
  - lxgr 2y ago
    > the information can't be encoded into the bundle Can it not? It seems like this SCTNotAfter constraint is effectively an API change of the root CA list that downstream users have to in some way incorporate if they want their behavior to remain consistent with upstream browsers. That doesn't necessarily mean full CT support – they might just as well choose to completely distrust anything tagged SCTNotAfter, or to ignore it. That said, it might be better to intentionally break backwards compatibility as a forcing function to force downstream clients to make that decision intentionally, as failing open doesn't seem safe here. But I'm not sure if the Mozilla root program list ever intended to be consumed by non-browser clients in the first place.
    - mcpherrinm 2y ago
bigiain 2y ago
Hmmmm, speaking of distrust and Mozilla... I wonder how much I should be concerned about Mozilla's trust store's trustworthiness, given their data grab with Firefox? I've switched to LibreWolf over that (more in protest than thinking I'm personally being targeted). But I'm pretty sure LibreWolf will still be using the Mozilla trust store? I haven't thought through enough to understand the implications of the moneygrubbing AI grifters in senior management positions at Mozilla being in charge of my TLS trust store, but I'm not filled with joy at the idea.
- dadrian 2y ago
  What actual risk are you worried about here? Mozilla changed their data policy, therefore the root store might do what...?
- chicom_malware 2y ago
  WebPKI is a maze of fiefdoms controlled by a small group of power tripping little Napoleons. Certificate trust really should be centralized at the OS level (like it used to be) and not every browser having its own, incompatible trusted roots. It's arrogance at its worst and it helps nobody.
  - tialaramex 2y ago
    > (like it used to be) When are you imagining this "used to be" true? This technology was invented about thirty years ago, by Netscape, which no longer exists but in effect continues as Mozilla. They don't write an operating system (then or now) so it's hard to see how this is "centralized at the OS level".
    - lxgr 2y ago
      It was true for at least Chrome until around 2020: Chrome used to not ship with any trusted CA list and default to the OS for that. Firefox has their own trusted list, but still supports administrator-installed OS CA certificates by default, as far as I know (but importantly not OS-provided ones).

tptacek 2y ago

Right; it's imperfect, as everything is. But of course, it's also a huge bit of leverage for the root programs (more accurately, a loss of leverage for CAs) in killing misbehaving CAs; those programs can't be blackmailed with huge numbers of angry users anymore, only a much smaller subset of users. Seems like a good thing, right?

LegionMammal978 2y ago
Only insofar as you trust the root programs to use their leverage responsibly, both today and in the medium-to-long-term future.
- tptacek 2y ago
  The operators of the root programs control the browsers (and, in some cases, the operating systems!), so this doesn't make much sense.
  - LegionMammal978 2y ago
    Any leverage against the root programs in the form of angry users is also leverage against the browser devs, is it not? Either way you look at it, the root programs/browser devs receive less pushback and gain more autonomy. My biggest concern is long-term censorship risk. I can imagine the list of trusted CAs getting whittled down over the next several decades (since it's a privilege, not a right!), until it's small enough for all of them to collude or be pressured into blocking some particular person or organization.
    - tptacek 2y ago
      Your concern is that there will be... too few CAs?
      - LegionMammal978 2y ago
        Yes. It would add another potential point of failure to the process of publishing content on the Web, if such a scenario came to pass. (Of course, the best-case scenario is that we retain a healthy number of CAs who can act independently, but also maintain compliance indefinitely.)
        tptacek 2y ago
        I don't know what to say; I think that's the first time I've heard that concern on HN. Thanks!
        throw_a_grenade 2y ago
        To add to this, EU's 2021 eIDAS (the one with mandatory trustlist) was a response to similar lack of availability. Contrary to what most HNers instincively thought it wasn't about interception: EC was annoyed that none of root programs is based in EU, and that causes 100% of trust decisions to be made on the other side of the Big Water. EC felt a need to do something about in, having in regard the fact that TLS certificates are needed for modern business, healthcare, finance etc., they have seen it as economy sovereignity issue. My point is, lack of options, aka availability, is (or may be perceived as) dangerous on multiple layers of of WebPKI.
        dadrian 2y ago
        No, eIDAS 2.0 was an attempt to address the fact that the EU is not one market in ecommerce, because EU citizens don't like making cross-border orders. The approach to solving this was to attach identity information to sites, ala EV certificates. The idea for this model came from the trust model for digital document signatures in PDFs. There are already plenty of CAs across the pond.
Y_Y 2y ago
> Right; it's imperfect, as everything is. Is this tautology helpful? For sure it's commonly used, but I honestly have a hard time seeing what information it conveys in cases like this.

dadrian 2y ago

Non-browser clients shouldn't be expected to crib browser trust decisions. Also, the (presumably?) default behavior for a non-browser client consuming a browser root store, but is unaware of the constraint behavior, is to not enforce the constraint. So they would effectively continue to trust the CA until it is fully removed, which is probably the correct decision anyway.

DSMan195276 2y ago
To me that's an odd position to take, ultimately if the user is using Mozilla's root CA list then they're trusting Mozilla to determine which certs should be valid. If non-browser programs using the list are trusting certs that Mozilla says shouldn't be trusted then that's not a good result. Now of course the issue is that the information can't be encoded into the bundle, but I'm saying that's a bug and not a feature.
- dadrian 2y ago
  Mozilla’s list is built to reflect the needs of Firefox users, which are not the same as the needs of most non-browser programs. The availability/compatibility vs security tradeoff is not the same.
- lxgr 2y ago
  > the information can't be encoded into the bundle Can it not? It seems like this SCTNotAfter constraint is effectively an API change of the root CA list that downstream users have to in some way incorporate if they want their behavior to remain consistent with upstream browsers. That doesn't necessarily mean full CT support – they might just as well choose to completely distrust anything tagged SCTNotAfter, or to ignore it. That said, it might be better to intentionally break backwards compatibility as a forcing function to force downstream clients to make that decision intentionally, as failing open doesn't seem safe here. But I'm not sure if the Mozilla root program list ever intended to be consumed by non-browser clients in the first place.
  - mcpherrinm 2y ago

bigiain 2y ago

Hmmmm, speaking of distrust and Mozilla... I wonder how much I should be concerned about Mozilla's trust store's trustworthiness, given their data grab with Firefox? I've switched to LibreWolf over that (more in protest than thinking I'm personally being targeted). But I'm pretty sure LibreWolf will still be using the Mozilla trust store? I haven't thought through enough to understand the implications of the moneygrubbing AI grifters in senior management positions at Mozilla being in charge of my TLS trust store, but I'm not filled with joy at the idea.

dadrian 2y ago
What actual risk are you worried about here? Mozilla changed their data policy, therefore the root store might do what...?
chicom_malware 2y ago
WebPKI is a maze of fiefdoms controlled by a small group of power tripping little Napoleons. Certificate trust really should be centralized at the OS level (like it used to be) and not every browser having its own, incompatible trusted roots. It's arrogance at its worst and it helps nobody.
- tialaramex 2y ago
  > (like it used to be) When are you imagining this "used to be" true? This technology was invented about thirty years ago, by Netscape, which no longer exists but in effect continues as Mozilla. They don't write an operating system (then or now) so it's hard to see how this is "centralized at the OS level".
  - lxgr 2y ago
    It was true for at least Chrome until around 2020: Chrome used to not ship with any trusted CA list and default to the OS for that. Firefox has their own trusted list, but still supports administrator-installed OS CA certificates by default, as far as I know (but importantly not OS-provided ones).