Some sites do not correctly display as https in the location bar

RESOLVED FIXED

Status

Focus-iOS
General
P1
normal
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: st3fan, Assigned: st3fan)

Tracking

Details

(Whiteboard: [MobileAS])

(Assignee)

Description

a year ago
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.
(Assignee)

Comment 1

a year ago
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.
(Assignee)

Comment 2

a year ago
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?
(Assignee)

Comment 3

a year ago
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.
(Assignee)

Comment 4

a year ago
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.
(Assignee)

Comment 5

a year ago
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.