1299155 - Can't access techblog.netflix.com, mis-redirect to https

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[pasik]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160819105407

Steps to reproduce:

Using Firefox 48 I can't access anything from http://techblog.netflix.com, for example:
http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html

Browser always gets redirected to https:// url (https://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html), which won't work:

"Secure Connection Failed
The connection to techblog.netflix.com was interrupted while the page was loading."



Actual results:

Firefox 48 somehow uses https:// url even when it is given plain http:// url.


Expected results:

Firefox 47 does NOT get redirected to https:// url, so using Firefox 47 it is actually possible to browse and read http://techblog.netflix.com .

techblog.netflix.com seems to be a CNAME to ghs.google.com .. is this somehow part of the problem? 

I used tcpdump/wireshark to see what's happening and it seems Firefox 48 browser doesn't even try to use http when given http url to that site, already the first connection is made using https / 443..

What might cause this?

Comment 1

[Vlad Bacia-Mociran [:VladB]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

I have tested your issue on latest Firefox release (v48.0) and latest Nightly (Build ID: 20160901030202) and could not reproduce it. I can access both links, http://techblog.netflix.com and http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).

Comment 2

[Vlad Bacia-Mociran [:VladB]]

Marking this as Resolved-WFM due to the lack of response from the reporter.

If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.

Comment 3

[Nathan Williams]

This has been happening for me too.  Any attempt to visit techblog.netflix.com redirects to the https version which fails because they aren't configured for it.

This is in FF 52.0.1 on Windows.  I am only able to reproduce the issue in my main, day-to-day (old as dirt) profile.  If I create a new profile or use FF Developer Edition (which has its own profile anyway), then it works.  When I've encountered the issue in the past, I've just jumped over to Chrome, but it was always a head-scratcher until I remembered that something was broken in FF about it.

I mounted my profile dir in a Docker vm and used find . -name "*" -exec egrep -iq "techblog|netflix" "{}" ";" -print to scour the profile for references.  Everything that came up was related to UI state or cache, and even after clearing all the hits, the problem persists.  But it's clearly tied to the profile, so whatever representation is still causing the redirection must be in a binary form that my crude text search wouldn't find.  I went spelunking through some of the sqlite databases and came up empty.

I thought this was an HSTS pinning issue and tried following https://security.stackexchange.com/a/154176, but either it's something else or FF is taking https://tools.ietf.org/html/rfc6797#section-12.1 very (too) seriously.

I'm guessing I'm just going to have to live with this until I bite the bullet and configure a new profile, but it's seriously weird, and I wanted to provide another data point about it.  If anyone has any other troubleshooting recommendations, I'd be glad to try them.  CC'ing so I'll get pinged if someone replies.