4 ms·

>when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-

by kej 8mo ago

>when attempts were made to push through security-enhancing changes to the Web PKI, CAs would push back on the grounds that there'd be collateral damage to non-Web-PKI use cases Do you (or anyone else) have an example of this happening?

agwa 8mo ago
After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...
- account42 8mo ago
  But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
  - sam_lowry_ 8mo ago
    I believe the explanation. The collateral damage is huge, but Google couldn't care less.
  - Ajedi32 8mo ago
    Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong. Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
    - sam_lowry_ 8mo ago
      European eIDs are knows to disallow encryption, only signature. If software like OpenSSL will starts to ignore intent... Good for us, the citizens.
    - vikkymelani 8mo ago
      [dead]

by kej 8mo ago

agwa 8mo ago

After the WebPKI banned the issuance of new SHA-1 certificates due to the risk of collisions, several major payment processors (Worldpay[1], First Data[2], TSYS[3]) demanded to get more SHA-1 certificates because their customers had credit card terminals that did not support SHA-2 certificates. They launched a gross pressure campaign, trotting out "small businesses" and charity events that would lose money unless SHA-1 certificates were allowed. Of course, these payment processors did billions in revenue per year and had years to ship out new credit card terminals. And small organizations could have and would have just gotten a $10 Square reader at the nearest UPS store if their credit card terminals stopped working, which is what the legacy payment processors were truly scared of. The pressure was so strong that the browser vendors ended up allowing Symantec to intentionally violate the Baseline Requirements and issue SHA-1 certificates to these payment processors. Ever since, there has been a very strong desire to get use cases like this out of the WebPKI and onto private PKI where they belong. A clientAuth EKU is the strongest indicator possible that a certificate is not intended for use by browsers, so allowing them is entirely downside for browser users. I feel bad for the clientAuth use cases where a public PKI is useful and which aren't causing any trouble (such as XMPP) but this is ultimately a very tiny use case, and a world where browsers prioritize the security of ordinary Web users is much better than the bad old days when the business interests of CAs and their large enterprise customers dominated. [1] https://groups.google.com/g/mozilla.dev.security.policy/c/RHBHXJOG8Io/m/5_H_NzZhAQAJ https://groups.google.com/g/mozilla.dev.security.policy/c/RH... [2] https://groups.google.com/g/mozilla.dev.security.policy/c/yhq6QNhEQok/m/9sdadL9kFwAJ https://groups.google.com/g/mozilla.dev.security.policy/c/yh... [3] https://groups.google.com/g/mozilla.dev.security.policy/c/LM9tkZR9mLM/m/ACBIRX7GAAAJ https://groups.google.com/g/mozilla.dev.security.policy/c/LM...

account42 8mo ago
But this has nothing to do with clientAuth as in this case the payment processor uses a server certificate and terminal connect to the payment processor, not the other way around. So this change would not have prevented this and I don't see what browsers can do to prevent it - after all, the exact same situation would have happened if the payment processors used a HTTPS-based protocol.
- sam_lowry_ 8mo ago
  I believe the explanation. The collateral damage is huge, but Google couldn't care less.
- Ajedi32 8mo ago
  Yeah, the more I think about it the more futile this effort starts to look. The industry is investing tons of resources into building and maintaining an open, highly secure PKI ecosystem which allows any server on the public internet to cryptographically prove its identity, and Google wants to try to prevent anyone who's not a web browser from relying on that ecosystem? Seems impossible. The incentives are far too strong. Google is hoping that after this change other TLS clients will go off and build their own PKI entirely separate from the web PKI, but in reality that would take way too much redundant effort when the web PKI already does 99% of what they want. What will actually happen is clients that want to use web certs for client authentication will just start ignoring the value of the extendedKeyUsage extension. The OP says Prosody already does. I don't see how that's an improvement to the status quo.
  - sam_lowry_ 8mo ago
    European eIDs are knows to disallow encryption, only signature. If software like OpenSSL will starts to ignore intent... Good for us, the citizens.
  - vikkymelani 8mo ago
    [dead]