Imagine a JavaScript in a web page A has permission to access domain B (that is, CORS is not an issue)
A makes an insecure/http query (websockets, XHR, whatever) to B. It fails.
Is there a way to ascertain, at that point, whether it failed *because HSTS is set on that domain?*
Conversation
Replying to
if it had bc HSTS enabled, wouldn’t the request be automatically upgraded to HTTPS? I have never heard of such an API
1
Replying to
1. The resource being requested is not HTTPS. It is HTTP.
2. If you "upgrade" a port 80 request to HTTPS, you do so by switching to port 443. How exactly does one upgrade an HTTP request on port 9033 to HTTPS? Request again as HTTPS on 9033?
2
1
It preserves the port:
datatracker.ietf.org/doc/html/rfc67
HSTS state is for the domain, not a specific origin based on the domain. If HSTS is enabled for the domain, the browser won't make HTTP requests. There's a special case for port 80 to use port 443 but other ports use the same port.
2
3
Hah, I was just trying to dig that RFC up. Thanks so much! It sounds like the standard took the right approach.
1
3
You can also stick either block-all-mixed-content or upgrade-insecure-requests (forced redirect) in the Content-Security-Policy for the top-level site and it will prevent using non-TLS connections for sub-requests regardless of whether HSTS is used for the other domains, etc.
By the way, it's actually entirely possible to host HTTP and HTTPS on the same port with nginx using the stream ssl preread module:
nginx.org/en/docs/stream
It allows you to proxy to a different upstream based on SNI name, TLS protocol, etc. and "no TLS" is a protocol version.
1
1
3
They have an example there of hosting SSH and HTTPS on the same port (empty "" protocol version means "no TLS"). Could happily host SSH, HTTPS and XMPP on one port with the same domain name using ALPN to distinguish XMPP like their example, or any number of other weird things.
1
2
Show replies