[go: nahoru, domu]

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

Serve https://publisher directly from an edge node? #675

Open
bitdivine opened this issue Sep 7, 2021 · 1 comment
Open

Serve https://publisher directly from an edge node? #675

bitdivine opened this issue Sep 7, 2021 · 1 comment
Labels
SXG Issue related to Signed HTTP Exchanges

Comments

@bitdivine
Copy link

Dear All,

Is there a story for how we might reach a world in which a user enters "https://publisher.com" and the website is served from a CDN SXG file?

Currently such a CDN server would have to have an ssl certificate for publisher.com to terminate the connection, but then the edge node could return any content whatsoever. This is not the ideal I would like to reach!

There seem to be these options:

  • Have a different offline domain that users would have to enter when the site is not directly accessible, e.g. https://publisher.com.archive. This is not very user friendly.
  • Have a different domain for archives, and issue ssl certificates that are restricted to providing redirects. Thus, a server could make an https redirect to https://publisher.com.archive but the certificate would be limited so that the certificate holder is authorized to perform that https redirect only, and nothing else. There is possibly a wider use case for https certificates that are limited in what the holder may return through the pipe, but limiting it to just redirects, or to just serving sxg files for the domain would be enough. As far as I know there are no such X509 extensions.
  • Probably many other options I have not thought of.

I am aware that there are concerns about off-path attacks that would have to be taken into account with any solution. I assume that ultimately the publisher and client should be in control of which paths are acceptable, so if the publisher signs a file stating that a given path is OK, and the client is willing to accept it, the path is OK.

@bitdivine
Copy link
Author

Possible implementation: The proxy certificate OID 1.3.6.1.5.5.7.1.14 would need a new extended key usage limited to serving signed files.

@hayatoito hayatoito added the SXG Issue related to Signed HTTP Exchanges label Sep 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SXG Issue related to Signed HTTP Exchanges
Projects
None yet
Development

No branches or pull requests

2 participants