-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Critical-ness of CanSignHttpExchanges extension #238
Comments
Thanks for filing, @irori! My understanding is that this could still be a potential issue for Edge/Safari, unless browser updates are strictly locked to OS updates (since the crypto APIs are controlled by the OS) By making it critical, it ensures no existing application can use Signed Exchange certs in TLS - that is, it forces key separation by technological means. This minimizes risk for cross-protocol issues, and for ecosystem issues, by ensuring that 100% of (well-behaving) clients will reject Signed Exchange certs being used for TLS. However, it presents its own set of compatibility issues - every certificate verifying application has to be updated to recognize this extension - and, in general, OS and cryptographic libraries don't let applications extensibly say "I know and recognize this extension", which means they also have to be updated to recognize this extension. If we make it non-critical, then there's the risk that users can end up deploying their Signed Exchanges key on their TLS endpoint. This doesn't undermine the signature scheme of Signed Exchanges, but it does present certain operational risks - particularly, if your TLS edge is compromised and that key is compromised, folks can MITM users without requiring an active-network presence. We can mitigate that risk by having Signed Exchange supporting TLS clients refuse to connect to TLS servers that present this extension. That is, if the certificate for an on-the-wire exchange contains this extension, fail the connection, in the same way that if a certificate in a signed exchange lacks this extension, the exchange fails validation. This creates the ecosystem disincentive to deploy your signed exchange key at your TLS server - but runs a chicken and egg problem of if a bunch of users do this before browsers start shipping signed exchanges, the ecosystem could end up more broken once they do ship exchanges. Despite this, I think making it non-critical is fine. For example, there's nothing (at present) preventing a CA from issuing a TLS server cert and a "signed exchange server cert" using the same underlying key and CSR - providing two certificates, one with the extension and one without. This has all of the same security problems I just described above, and is not mitigated by the critical extension. More broadly, I think the best way we can capture this is by making sure we have a "Security Considerations" section that details the risks from improper key hygiene, which can cover these scenarios in depth. This is somewhat captured in https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.6.4 and https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#rfc.section.6.2 but may be worth fleshing out more comprehensively as its own bit. |
But warn servers away from using it in TLS servers. Fixes WICG#238.
This updates test certificates for layout tests removing the critical flag of CanSignHttpExchangesDraft extension. Context: WICG/webpackage#238 Bug: 851778 Change-Id: I1cca7d55a4eebd898db45cc212265674a7e9be5a Reviewed-on: https://chromium-review.googlesource.com/1119725 Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Reviewed-by: Kent Tamura <tkent@chromium.org> Commit-Queue: Kunihiko Sakamoto <ksakamoto@chromium.org> Cr-Commit-Position: refs/heads/master@{#573225}
But warn servers away from using it in TLS servers. Fixes WICG#238.
But warn servers away from using it in TLS servers. Fixes #238.
This came up in https://crrev.com/c/1111485.
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html#cross-origin-cert-req
In Chrome, certificate path building and verification is performed using underlying operating systems' API. So, if the CanSignHttpExchanges extension is marked as critical, the OS API will reject the cert, until the OS supports CanSignHttpExchanges extension.
Can we revisit the critical-ness of this extension? What's the security implication of not marking it as critical?
cc: @sleevi @jyasskin
The text was updated successfully, but these errors were encountered: