What is the behaviour of Chromium (latest/stable) when HSTS max-age is over?
Reported by
avinesh...@gmail.com,
Nov 4
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; CrOS x86_64 11021.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.76 Safari/537.36 Platform: 11021.56.0 (Official Build) beta-channel eve Steps to reproduce the problem: 1. Connect to a secure AP (Access Point) 2. Visit a website with HSTS (with max-age; no preload) 3. Close the connection and let the max-age to mature 4. Kill the browser process and start it back 5. Connect to an ssl-stripping AP (rogue, perhaps using brav0hax/easy-creds) 6. What happens? What is the expected behavior? What went wrong? N/A Did this work before? N/A Chrome version: 70.0.3538.76 Channel: stable OS Version: 11021.56.0 Flash Version: 31.0.0.122 I expect some behavioural clarification around this (I assume since this is Chromium, it should be platform independent).
,
Nov 6
When a dynamic HSTS entry has expired (that is, the amount of time elapsed since an STS header for that domain was seen is greater than the max-age in the header), then that dynamic HSTS entry is deleted. This means that http requests to such a domain will no longer get upgraded to https, but https requests will continue to go over https. Was there a particular buggy behavior that you're seeing that doesn't match with that?
,
Nov 7
So I was testing some bug and while doing that I was intrigued to test what happens when hsts expires and I connect to an SSL stripping access point. For any HTTP request it will not be upgraded to HTTPS which makes sense. However, for any HTTPS request, it seems that a specific response from the access point was sufficient to actually let Chrome bypass the SSL tunnel formation and talk like a regular HTTP i.e. talking like HTTP over 443. I have not been able to find time to reproduce this but just thought of sharing this in case something sounds impossible before I actually invest any time. Also, someone working on bug bounties actively can check it out.
,
Nov 7
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 7
Fwiw, if this is stupid, I guess, I apologize for wasting time. I figured I could share to let this thing surface for clarification first. Either way, something like this would be an interesting one.
,
Nov 9
If a network attacker were to respond to Chrome's TLS ClientHello with a (plaintext) HTTP response, Chrome should show an error page with ERR_SSL_PROTOCOL_ERROR. I'd be really surprised if Chrome sent a plaintext HTTP request on port 443 when navigating to an https URL. If you're able to reproduce the behavior that you describe, we'd love to hear about it. In the meantime, I'm going to close this bug. |
||||
►
Sign in to add a comment |
||||
Comment 1 by dtapu...@chromium.org
, Nov 5