Skip to content
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

Open
annevk opened this issue Dec 3, 2024 · 9 comments
Open

Consider removing serverCertificateHashes #623

annevk opened this issue Dec 3, 2024 · 9 comments
Labels
Discuss at next meeting Flags an issue to be discussed at the next WG working

Comments

@annevk
Copy link
Member

annevk commented Dec 3, 2024

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.

@vasilvv
Copy link
Contributor

vasilvv commented Dec 3, 2024

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 do not understand this comparison. What does Web Push or middleware has to do with serverCertificateHashes?

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.

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.

@annevk
Copy link
Member Author

annevk commented Dec 3, 2024

I do not understand this comparison. What does Web Push or middleware has to do with serverCertificateHashes?

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.

@youennf
Copy link

youennf commented Dec 3, 2024

in order to have feature parity with WebRTC in that regard

WebRTC is peer-to-peer hence the current solution for WebRTC.
WebTransport being client/server, it seems more consistent to stick with what other client/server networking stacks like HTTP or WebSocket are doing.

@vasilvv
Copy link
Contributor

vasilvv commented Dec 3, 2024

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.

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.

@annevk
Copy link
Member Author

annevk commented Dec 3, 2024

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.

@vasilvv
Copy link
Contributor

vasilvv commented Dec 3, 2024

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.

@wilaw wilaw added the Discuss at next meeting Flags an issue to be discussed at the next WG working label Dec 3, 2024
@jan-ivar
Copy link
Member

jan-ivar commented Dec 4, 2024

Meeting:

@annevk
Copy link
Member Author

annevk commented Dec 4, 2024

@vasilvv regular certificates have all kinds of safeguards, including being able to distrust the root if practices like this were to be discovered.

@vasilvv
Copy link
Contributor

vasilvv commented Dec 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discuss at next meeting Flags an issue to be discussed at the next WG working
Projects
None yet
Development

No branches or pull requests

5 participants