-
Notifications
You must be signed in to change notification settings - Fork 50
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
Consider removing serverCertificateHashes #623
Comments
I do not understand this comparison. What does Web Push or middleware has to do with serverCertificateHashes?
This is not correct; the motivation for this feature is to provide the ability to connect to endpoints that cannot have a publicly trusted certificate, in order to have feature parity with WebRTC in that regard. The original reasoning for adding it is documented in #18. Since that discussion happened, more motivation came from scenarios like WICG/private-network-access#23. |
The risk that people will just use a shared private certificate across a range of devices just to get this to work without actually caring much about end user security. And while there is definitely a need for some kind of HTTPS for local networks, we should not solve it on a per-API basis. |
WebRTC is peer-to-peer hence the current solution for WebRTC. |
We have discussed this issue previously in #349; this resulted in an expiry requirement being added, as documented in https://w3c.github.io/webtransport/#certificate-hashes. |
I don't see how that addresses the concern. You can generate fresh certificates with a shared private key quite easily, but it's not actually secure. |
I don't believe this is in any way different from regular Web PKI certificates. |
Meeting:
|
@vasilvv regular certificates have all kinds of safeguards, including being able to distrust the root if practices like this were to be discovered. |
As far as I am aware, there isn't anything in CA/B BR that requires CAs to check for private key reuse; furthermore, as far as I am aware, reusing private keys is not uncommon in practice. |
Just a few thoughts: I use the hashes for: Regarding reusing certificates: Support in Firefox: Of course, I would prefer that Webkit support the hashes. But for a web app it may also be an option to recommend other browsers if European DMA results in Gecko and Blink appearing on iOS etc. |
Regarding e-g) I have made it anyway: https://phabricator.services.mozilla.com/D231479 . |
I want to address this, because it is a misconception about this feature. Consider the two cases where a site, "https://some.example" say, initiates a WebTransport connection:
In neither case does the identity of the WebTransport host come from something that the user specifies. The root of trust is the site. In both cases, an attack on the site that results in providing the wrong server identity causes the connection to be vulnerable to interception. The only difference that I've been able to identify is that the identity of the server in the first case will be logged in a CT log somewhere.
The identified remedy is only capable of making the API a modest amount harder to use. It doesn't change the security posture meaningfully. Servers like Caddy or tools like mkcert largely eliminate those differences. Of course, the use of the WebPKI tends to lead to people sharing the same private key across a range of devices as well, so it's a bit meaningless. This feature exists in support of rapid deployment, which includes development scenarios. While I'm somewhat ambivalent about its general utility in a world that includes widespread ACME deployment, I don't think that there's a meaningful security argument for its removal. |
I feel like local network access use cases are not really addressed by ACME, since the server in question would normally not be accessible by a public CA. Right now, I'm aware of four options available to web developers that need to do something like that:
Out of those four options, only 2 and 4 work consistently in all web browsers. 2 has proven sufficiently unpalatable to web developers that they have been willing to settle for 4; this situation does not appear to be desirable state for the ecosystem. I believe that 3 could be a sufficient improvement over 2 (in terms of both developer experience, and safeguards against misuse) that it might steer developers away from 4.
Solving this problem for all forms of HTTP requests in general seems to me like boiling the ocean, mostly due to challenges unique to HTTP (caching, top level navigation, cookies, etc). Solving this on per-API basis is more like boiling a water in a kettle, in the sense that we do know how to do that, and there are at least two implemented APIs (one of which is shipped in every major browser engine) that already do that. |
This does not seem like acceptable discourse. |
Why? It is not insulting, but European legislation about market regulation. It is my reasoning for a small open-source project with no capacity for developing fallbacks for the browsers that do not have newer apis for supporting some critical features (I polyfil for some, but... e.g. webtransport over websocket polyfil, and I have also wrote patches for some browsers). I recommend using the browser that supports the newer features. Only on ios, there is lack of competition, and I would like to support these devices as well fully without much extra work, the option of a switch of browser engine would solve this problem, of course I would prefer to have features on all three engines.... as I am solution oriented, I accept any solution. And serverCertificateHashes is a feature, that I believe is secure and easy to deploy and this ideal for smaller projects. |
@martenrichter Your point is off-topic for this conversation. Let's focus on the technical merits of the proposal and the pros & cons of using WebTransport and its alternatives. |
Without more restrictions this feature could lead to the same kind of problem plaguing Web Push, where messages are not end-to-end encrypted because it's easier to let middleware worry about the complexity of encryption and dealing with the Web Browser Endpoint in general.
I also heard that the main motivation for this feature is local development and testing, which does not meet the high bar we have for web platform features.
As things stand today WebKit does not intend to implement this.
The text was updated successfully, but these errors were encountered: