strict-transport-security headers (HSTS) on main domain affect HTTP-only connectivity-check / captive-portal urls negatively
- /e/OS version: v3.1
- Device model(s): FP3
- Impacted Application: all
- Affected application/URL: connectivity-check URLs (204.murena.io, connectivity.murena.io, ..)
- Browser/client and version: any
The problem
Android has http-only connectivity checks that rely on redirects to captive portal pages. Redirects cannot occur on https connections as they cannot be interfered with without breaking the trust chain.
By issuing strict transport security headers for the main domain of murena.io, those http-only connectivty check subdomains are in principle dysfunctional at least from a browser perspective that visited murena.io before - even if Android can ignore the HSTS for their own non-user-visible captive portal check. Firefox will show:
https://204.murena.io has a security policy called HTTP Strict Transport Security (HSTS), which means that Firefox can only connect to it securely. You can't add an exception to visit this site.
To help users in a multitude of public wifis and find the sign-up page, a http only connectivity check needs to work in every circumstance.
Technical details
see includeSubDomains and preload in:
$ curl -s https://murena.io -X GET -I | grep -i strict-transport
strict-transport-security: max-age=63072000; includeSubDomains; preloadforum feedback when users ran into issues:
- https://community.e.foundation/t/error-connecting-to-public-wi-fi-due-to-http-strict-transport-security/73507
- https://community.e.foundation/t/error-connecting-wifi-connecting-to-connectivity-murena-io/66213
related to:
either do not includeSubDomains or use a dedicated main domain for captive portal urls
Workaround
to provoke a http redirect in a captive portal setting, use http://httpforever.com or Googles CC at http://connectivitycheck.gstatic.com/generate_204