Examples are news.ycombinator.com and bugzilla.mozilla.org. They show up as http:// URLs in the location bar. I don't think these sites work at all via http, so I am pretty sure they are actually loaded correctly over https and that this is just a display issue. Disabling the URLProtocol.registerClass(LocalContentBlocker.self) in the AppDelegate fixes things, which gives a hint that this is related to our custom http handler.
I don't see urlSession(_ session:, task:, willPerformHTTPRedirection..) being called at all. That is really weird. I'll setup a local proxy to verify that the requests are actually switching to HTTPS to remove the uncertainty wether this content is loaded over HTTPS or not.
I hooked up mitmproxy to my iPhone and when I open http://bugzilla.mozilla.org (fully typed in the location bar), I correctly see all the loads coming from https://b.m.o/* Interestingly I do not see the initial load for http://b.m.o hit the proxy. Is that a hint? Why would it not get to the proxy? Is it in some global HSTS preload list?
Two things about not seeing the initial load: When I do a clean install of the app, Going to http://bugzilla.mozilla.org opens the HTTPS version without a redirect. This makes me wonder if Apple has included some global HSTS preload list that contains b.m.o. When I do a clean install of the app, going to http://news.ycombinator.com shows me this in the proxy: 301 http://news.ycombinator.com 200 https://news.ycombinator.com So that is just a regular working redirect to HTTPS. After that, ever after clearing the caches, http://n.y.c always immediately goes to https.
This should probably be a separate bug .. we do not clear the HSTS list as part of Clear Data: Library/Caches/org.mozilla.ios.Focus/HSTS.plist Needs some discussion though. It does leak some data about visited sites. On the other hand, it is good to have a HSTS list so that you never hit HTTP later.
TL;DR I think the conclusion here is simple: if a site is in the fixed (shipping with iOS) or dynamic (being built up as you browse) list of sites that support HSTS, we never get a signal that the original load for http:// has changed to https:// Here my findings, comparing a bunch of of HSTS scenarios: http://amazon.com not in HSTS preload list / redirects to HTTPS / does not set STS header 1st: GET http://amazon.com 301 GET https://amazon.com 301 GET https://www.amazon.com/ 200 UI Updated Correctly 2nd: GET http://amazon.com 301 GET https://amazon.com 301 GET https://www.amazon.com/ 200 UI Updated Correctly http://bugzilla.mozilla.org in HSTS preload list / sets STS header 1st: GET https://bugzilla.mozilla.org 200 UI Updated Incorrectly 2nds: GET https://bugzilla.mozilla.org 200 UI Updated Incorrectly http://news.ycombinator.com Not in HSTS preload list / redirects to HTTPS / sets STS header 1st: GET http://news.ycombinator.com 301 GET https://news.ycombinator.com 200 UI Updated correctly 2nd: GET https://news.ycombinator.com 200 UI Updated incorrectly, still shows http
As Stefan mentioned, the issue is that UIWebView was never getting signalled that the URL changed from HTTP->HTTPS. We can fix this by calling client.urlProtocol:wasRedirectedTo on the scheme change. Since urlSession:willPerformHTTPRedirection isn't called in this situation, we have to detect the redirection ourselves by comparing the current request to the original request in the response handler. I think this should cover *all* redirection cases, not just HSTS, so with this change we can remove our urlSession:willPerformHTTPRedirection handler altogether. master: 0f4c995194fd276b5430b5ce24e2e3bee9a12df6
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
And a follow-up: 4aac54a9e2e09dd4ed800a26a16c45066886d269 Redirecting creates a new request, so there's no benefit in trying to flag the old one.
You need to log in before you can comment on or make changes to this bug.