1461188 - Incorrect security status for HTTPS PDF resources loaded from external applications

Status: RESOLVED WORKSFORME

(Firefox :: PDF Viewer, defect, P3)

Description

[Steven Englehardt [:englehardt]]

Attachment: Incorrect security UI

When a top-level HTTPS PDF load is triggered from an external application (such as a link click in Thunderbird), the resource is marked as if it were an HTTP resource served from `about:blank`: i.e., the site information door hanger shows the hostname `about:blank` and `Connection is not secure` and the site security manager displays no certificate information. We would expect the site information to display the hostname of the PDF resource and the connection status for that resource. See the attached image.

I can reproduce with a fresh profile on 61 and 62, but not 60.
* Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0 (Build: 20180510160705)
* Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0 (Build: 20180512220039)

Links tested:
* https://senglehardt.com/papers/pets18_email_tracking.pdf
* https://www.dni.gov/files/icotr/Section702-Basics-Infographic.pdf

Refreshing the page causes the correct security status to show, as does visiting a link without a scheme specified (which results in a redirect to the secure resource). Note that senglehardt.com uses HSTS, and all future resource loads show the correct status.

I was unable to reproduce for link clicks within Firefox or for other resource types, so it appears to be limited to PDF resources triggered by an external application.

I also tried MITMing the load with a self-signed cert and received the expected error page, so I suspect it's just the security UI.

Comment 1

[Daniel Veditz [:dveditz]]

I can't reproduce using the dni.gov link (which doesn't seem to use HSTS) with a not-fresh profile on nightly 62. In my case the external link clicks came from the slack app and thunderbird.

Comment 2

[Steven Englehardt [:englehardt]]

Attachment: Screencast 2018-05-15 16_59_28.mp4

Comment 3

[Steven Englehardt [:englehardt]]

Attachment: repro.webm

re-upload in webm due to file corruption warnings

Comment 4

[Steven Englehardt [:englehardt]]

I can reproduce on my current (non-fresh) profile, which is FF 61 beta on MacOS.

I can also reproduce on Ubuntu 16.04. See the attached screen capture in https://bugzilla.mozilla.org/show_bug.cgi?id=1461188#c3

Comment 5

[Daniel Veditz [:dveditz]]

Could you try a fresh profile? Or at least try the "safe mode" button from the top of about:support?

If that doesn't clear it up are there any errors or warnings on the Web Console or Browser Console?

If safe mode does clear it up we can start selectively winnowing out your extensions to see if it's caused by any of them.

Comment 6

[Daniel Veditz [:dveditz]]

I can reproduce on windows nightly, both ctrl-clicking the link in this bug and from an external app. Reloading gets the correct certificate state. Don't see any errors anywhere.

Comment 7

[Steven Englehardt [:englehardt]]

I tested with both fresh and non-fresh profile for beta, as well as fresh profiles for nightly. The fresh profiles were new, so they had no extensions installed.

I don't see any errors or warnings in the web or browser console. I see the following log when testing in Nightly build (20180516100125) on MacOS.

"PDF 31438cf55ca9c145a09c4ce01c2ce2aa [1.6 Adobe PDF Library 15.0 / Adobe InDesign CC 2015 (Windows)] (PDF.js: 2.0.491)".

Another observation. On a fresh profile on Nightly build (20180516100125) on MacOS, the site information door hanger shows `about:blank` on the initial load of the PDF. When I switch to another tab and back to the tab containing the PDF, the door hanger shows the hostname of the PDF (in this case, `www.dni.gov`).

Comment 8

[Daniel Veditz [:dveditz]]

I can also reproduce the "about:blank" bit. Mostly I didn't see that because I was opening the link from this bug in a new tab and then having to switch tabs. By time I got there it was already www.dni.gov. But when I open the link from an external app so I go straight to the tab when it's opened then I do see about:blank at first.

I don't think this needs to be hidden. It's incorrect, but not in a dangerous direction.

Comment 9

[Daniel Veditz [:dveditz]]

I think this is far more likely to be due to the games the PDF Viewer plays to show the original URL when it's really on some internal resource page than a "DOM: Security" problem with the site information itself. Moving components.

Comment 10

[Jonathan Kingston [:jkt] he/him]

Just for clarity Stephen mentioned he had "security.insecure_connection_icon.enabled" enabled.

Comment 11

[Steven Englehardt [:englehardt]]

That's what allowed me to discover the bug. But I did reproduce without this pref enabled.

Comment 13

[Kenan]

I cannot reproduce this bug on Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

As this bug is quite old: Can you reproduce it with a recent FF ?

Comment 14

[Marco Castelluccio [:marco]]

Please comment or reopen if you can still reproduce.