Very difficult to avoid being upgraded to HTTPS in Chrome Beta

[dadrian]

We're in the process of launching https://github.com/dadrian/https-upgrade in Chrome. Right now, the feature is enabled for 50% of Chrome Beta, although you can also use it in stable (M113) by enabling #https-first-mode-v2 AND #https-upgrades on chrome://flags. We intend to enable this by default eventually, but we're not there yet.

HTTPS Upgrades optimistically upgrade any HTTP navigation to HTTPS. If HTTPS is unavailable, Chrome falls back to HTTP without an interstitial. The feature is not intended to protect against active adversaries.

Users can opt out of the upgrade feature on specific sites by adding the site to the "Insecure Content" "permission" accessible via chrome://settings/content or via the Page Info (Lock) Icon, and then navigating to an HTTP page on that site.

Putting this all together, what does this mean for NeverSSL?

1. Any Omnibox navigation to neverssl.com, regardless of scheme, gets upgraded to HTTPS.
2. Rather than serve a RST, NeverSSL sends a redirect to http://$RANDOM_SUBDOMAIN.neverssl.com
3. The HTTPS Upgrades feature intercepts the redirect to HTTP, and upgrades it to HTTPS.
4. NeverSSL happily serves https://$RANDOM_SUBDOMAIN.neverssl.com and the user is stuck on HTTPS
5. (optional, terrible workaround) The user clicks Page Info (Lock Icon) -> Site Settings -> Insecure Content -> Allowed
6. The user manually changes the scheme back to HTTP and forces a navigation (hits enter)
7. NeverSSL is now accessible over HTTP

Certainly, the UX for disabling upgrades is not good, although it's not entirely clear if there's any good options. What I don't understand is why NeverSSL supports HTTPS at all? I understand you did it to work around the schemeless Omnibox upgrades to HTTPS that landed a couple years ago, but wouldn't it work equally well to have port 443 return a RST, so that Chrome and other browsers immediately fall back to HTTP?

Alternatively, is there some way to serve a RST on the $RANDOM_SUBDOMAIN.neverssl.com on port 443, so that the redirect continues to stay on HTTP?

[colmmacc]

I can make that change, potentially as soon as today; but keep in mind that neverssl itself is not the thing responding when you're in the kind of broken environment where you need to use neverssl. Peversely, the goal isn't to load the Neverssl page, it's to trigger broken MITM boxes to prompt you with their registration/payment flows. So even after I make the change, really it's those other boxes that you need to RST port 443 for things to go well for Chrome users. I suspect a lot of those broken boxes won't do what the users need.

Something that would be cool to see in chrome itself is support for a neverssl like ping to wake up those kinds of systems. Basically when the internet appears to be unreachable, resolve [somethingrandom].[somedomain] and try to reach it over HTTP. That's the only trick neverssl is pulling, but the random domain helps defeat all of the caches that can be in the way ... which range from the browser and OS caches, to corporate security software running on a laptop, etc. Neither Apple's nor Microsofts own internet-wakeup URLs seem to use a random domain, which is a pity.

[dadrian]

Peversely, the goal isn't to load the Neverssl page, it's to trigger broken MITM boxes to prompt you with their registration/payment flows.

I'm not sure I follow. What's the behavior / configuration of a middlebox or captive portal that can successfully intercept the HTTPS connection, but fails if port 443 returned a RST?

Basically when the internet appears to be unreachable, resolve [somethingrandom].[somedomain] and try to reach it over HTTP.

We're separately looking at improving captive portal detection.

[colmmacc]

I think very few middle boxes can successfully intercept a HTTPS connection, because modern browsers are more forceful about the rejecting the invalid certificates they serve and it's harder than ever for users to over-ride that. But many of the middle boxes still listen on 443 and attempt to do it, because they are poorly designed and maintained. That's how users can get stuck in the first place.

In that kind of environment, neverssl helps by forcing a HTTP lookup ... which will display (or trigger a redirect to) the captive portal. I'm just pointing out that changing neverssl on my end won't help users behind those broken portals.