1737359 - https-only interstitials on links in ZDNet newsletters due to insecure link-tracking site http://enews.zdnet.com (hosted by mapp.com)

Status: NEW

(Core :: DOM: Security, task, P3)

Description

[Kevin Buchs]

Attachment: har-files.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

In some cases, HTTPS-Only will report that the website isn't available in HTTPS and when I click the "proceed" button it then finishes by loading the website via HTTPS. I think some other issues, security-wise are potentially the cause, but it is clearly not accurate to say the website is not available in HTTPS.

An example of this behavior was just observed with this URL:
https://enews.zdnet.com/ct/59013643:sxb3ppHzN:m:1:2402411662:43295F78B65BFEA3C0C8FCA31E449E4D:r

I have seen it regularly with ZDNet, AWS, and others. I'll attach some HAR files gathered from a recent case. The first file was collected up to the point of the message in "What happened" being displayed. Then I continued to the website and when it was finished loading, I gathered another HAR (persistent logs).

Actual results:

HTTPS-Only Mode Alert
Secure Connection Not Available

Expected results:

I don't know - maybe certificate not valid or something else.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Daniel Veditz [:dveditz]]

We see this quite a lot with email tracking links especially -- the tracking domain is only available over an insecure http:// link, and the https: version either doesn't respond, or as in this case, responds with an invalid certificate

An example of this behavior was just observed with this URL:
https://enews.zdnet.com/ct/59013643:sxb3ppHzN:m:1:2402411662:43295F78B65BFEA3C0C8FCA31E449E4D:r

Not quite: that's already an https link so Firefox https-only doesn't need to upgrade it. If you click it you get the certificate error I was talking about

Nightly does not trust this site because it uses a certificate that is not valid for enews.zdnet.com. The certificate is only valid for *.bluehornet.com.

bluehornet.com was registered by by mapp.com, a marketing services site. Exactly the kind of folks who run https-less email link tracking servers.

If you click the above link with "http:" instead you do get the error page you described. Note that it's telling you that "enews.zdnew.com" is not available over HTTPS, and that is 100% accurate. There is no way for the browser to know it's just a redirector and will eventually get to a secure site after all. And anyway, there's no way to get the redirect destination without fetching it over an insecure link which is what HTTPS-only promises not to do. So really, there's nothing we can do at that point other than ask the user. If the user proceeds they open the insecure enews.zdnet.com which then redirects you to a different origin WWW.zdnet.com, which is available over a secure connection.

Expected results:
I don't know - maybe certificate not valid or something else.

"Certificate not valid", as in this case, is one of the errors that will prompt the interstitial page saying the site is not available securely. We didn't want to show the certificate error in this case because it's relatively common given the way shared hosting works, and it's not helpful for users. A certificate error is a dead end, but the user's desired content is probably available if they're willing to load the link over an insecure connection.

Https-only mode is working as intended here, and our experiments and user feedback make us reluctant to change the UI as you requested. Probably most useful for us to morph this into a bug to reach out to ZDNet, and also mapp.com because this will likely be a problem for all their customers.