Closed Bug 1661593 Opened 5 years ago Closed 5 years ago

Page info window mistakenly displays certificate information from proxy/vpn for http (non-TLS) sites, implying all of the connection is encrypted when that is not the case

Categories

(Firefox :: Page Info Window, defect)

80 Branch
defect

Tracking

()

VERIFIED FIXED
84 Branch
Tracking Status
firefox84 --- verified

People

(Reporter: 1.800.O.Canada+bugzilla.mozilla.org, Assigned: emz)

Details

Attachments

(2 files, 3 obsolete files)

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

Steps to reproduce:

1.go to http://www.mto.gov.on.ca/english/driver/driving-schools.shtml
2.click 🔒 and it will say "Connection not secure"
3.click ➡️ and it will say "You are not securely connected to this site"
4.click "More Information" and it will say "Connection Encrypted" under "Security" tab "Technical Details"

Actual results:

Please check out the following link:
Government-approved driving schools
http://www.mto.gov.on.ca/english/driver/driving-schools.shtml

Please also check out the screenshots:
https://i.imgur.com/F5QzKDb.png
https://i.imgur.com/shoEsXb.png
https://i.imgur.com/PMQtlfD.png

Please check out the following two links:
http://www.xinhuanet.com/gangao/2020-08/25/c_1126411991.htm
http://www.chinanews.com/tp/hd2011/2020/08-23/952667.shtml

Please also check out the screenshots:
https://i.imgur.com/XHETQUR.jpg
https://i.imgur.com/og9iFKF.jpg
https://i.imgur.com/HUMhJKG.png

https://i.imgur.com/H4njjaB.png
https://i.imgur.com/8Ht6MkK.png
https://i.imgur.com/3bELwGq.png

Expected results:

It has something to do with the GlobalSign nv-ca licensing as they all expire on November 12, 2021.
https://i.imgur.com/3bELwGq.png
https://i.imgur.com/HUMhJKG.png
https://i.imgur.com/PMQtlfD.png
I checked "Page Info" and it's under the "Security" tab:
http://www.xinhuanet.com/gangao/2020-08/25/c_1126411991.htm
http://www.chinanews.com/tp/hd2011/2020/08-23/952667.shtml
http://www.mto.gov.on.ca/english/driver/driving-schools.shtml

I uploaded the wrong screenshot...
Plz check out this one:)

Attachment #9172530 - Attachment is obsolete: true

I am using the latest version:
80.0 (64-bit)

Attachment #9172531 - Attachment is obsolete: true

I can't reproduce - if I open page info on one of these sites, I do not see the globalsign nv-sa mentioned, and nothing says "Connection Encrypted".

Are you using a proxy to connect to the internet? Can you reproduce on a new, clean/empty Firefox profile, without the proxy? (cf. https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles )
Are there any errors in the browser console (open with cmd-shift-j; this is not the regular web console) when you open the page info dialog?

If so, can you maybe provide a screencast showing the exact steps you take, and any errors that show up?

Flags: needinfo?(1.800.O.Canada+bugzilla.mozilla.org)

(In reply to :Gijs (he/him) from comment #3)

I can't reproduce - if I open page info on one of these sites, I do not see the globalsign nv-sa mentioned, and nothing says "Connection Encrypted".

Are you using a proxy to connect to the internet? Can you reproduce on a new, clean/empty Firefox profile, without the proxy? (cf. https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles )
Are there any errors in the browser console (open with cmd-shift-j; this is not the regular web console) when you open the page info dialog?

If so, can you maybe provide a screencast showing the exact steps you take, and any errors that show up?

You were right, the cause is because of the VPN.
https://i.imgur.com/jkjHrtA.png

Flags: needinfo?(1.800.O.Canada+bugzilla.mozilla.org)

Are you able to provide any more information about what VPN connection you're using / how we could reproduce this issue? We should probably still fix the issue so it doesn't happen when using a VPN!

Component: Untriaged → Page Info Window
Flags: needinfo?(1.800.O.Canada+bugzilla.mozilla.org)

(In reply to :Gijs (he/him) from comment #6)

Are you able to provide any more information about what VPN connection you're using / how we could reproduce this issue? We should probably still fix the issue so it doesn't happen when using a VPN!

Hotspot Shield 4.0.1 within macOS Catalina 10.15.6 (19G73)
Browsec VPN 3.27.9 within Firefox 80.0 (64-bit)

When I browse the web, I turn both VPN on:)Bon week-end!

Flags: needinfo?(1.800.O.Canada+bugzilla.mozilla.org)

can we unhide this?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Andrew McCreight [:mccr8] from comment #8)

can we unhide this?

It doesn't have a security rating and I don't know what that would be, so I also don't know if we should unhide... Like, it's not ideal that the page info window is providing the "wrong" information here, but equally I think usage of it is such that it's probably not a super big deal given the identity window says the right thing. Do you have a feeling for what we want to do about the security rating here? Maybe sec-vector/sec-other and opening up?

Equally, we haven't spent time figuring out why the page info window is saying this, and if there's other places where we're substituting the VPN/proxy info for the site connection info?

Maybe Florian can help, I think he knows the page info code best.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(florian)
Flags: needinfo?(continuation)

(In reply to :Gijs (he/him) from comment #9)

It doesn't have a security rating and I don't know what that would be, so I also don't know if we should unhide... Like, it's not ideal that the page info window is providing the "wrong" information here, but equally I think usage of it is such that it's probably not a super big deal given the identity window says the right thing. Do you have a feeling for what we want to do about the security rating here? Maybe sec-vector/sec-other and opening up?

Well, if we unhide it, it would because it doesn't need a security rating at all. My thought was just that it seems unlikely that somebody is going to see the URL bar indication, then go digging into multiple layers of menus, and read some text, and then decide they must be getting a safe connection after all. But who knows.

Equally, we haven't spent time figuring out why the page info window is saying this, and if there's other places where we're substituting the VPN/proxy info for the site connection info?

That's true. We should probably do that kind of audit first.

Flags: needinfo?(continuation)

(In reply to Andrew McCreight [:mccr8] from comment #10)

(In reply to :Gijs (he/him) from comment #9)

It doesn't have a security rating and I don't know what that would be, so I also don't know if we should unhide... Like, it's not ideal that the page info window is providing the "wrong" information here, but equally I think usage of it is such that it's probably not a super big deal given the identity window says the right thing. Do you have a feeling for what we want to do about the security rating here? Maybe sec-vector/sec-other and opening up?

Well, if we unhide it, it would because it doesn't need a security rating at all. My thought was just that it seems unlikely that somebody is going to see the URL bar indication, then go digging into multiple layers of menus, and read some text, and then decide they must be getting a safe connection after all. But who knows.

Equally, we haven't spent time figuring out why the page info window is saying this, and if there's other places where we're substituting the VPN/proxy info for the site connection info?

That's true. We should probably do that kind of audit first.

FYI, I updated to Fx 81.0.1, and the same error still...

(In reply to :Gijs (he/him) from comment #9)

(In reply to Andrew McCreight [:mccr8] from comment #8)

can we unhide this?

It doesn't have a security rating and I don't know what that would be, so I also don't know if we should unhide... Like, it's not ideal that the page info window is providing the "wrong" information here, but equally I think usage of it is such that it's probably not a super big deal given the identity window says the right thing. Do you have a feeling for what we want to do about the security rating here? Maybe sec-vector/sec-other and opening up?

Equally, we haven't spent time figuring out why the page info window is saying this, and if there's other places where we're substituting the VPN/proxy info for the site connection info?

Maybe Florian can help, I think he knows the page info code best.

I haven't tried it out on Windows, not sure if it only applies to macOS...

(In reply to :Gijs (he/him) from comment #9)

Maybe Florian can help, I think he knows the page info code best.

I can't find anything obvious, both Page Info and the identity panel seem to take their info from gBrowser.securityUI
https://searchfox.org/mozilla-central/source/browser/base/content/pageinfo/security.js#155 for page info
https://searchfox.org/mozilla-central/source/browser/base/content/browser-siteIdentity.js#690 for the identity panel.

Nihanth, I see you reviewed some of this identity panel code recently, any idea of what might be different between the two?

Flags: needinfo?(florian)

(In reply to Florian Quèze [:florian] from comment #13)

Nihanth, I see you reviewed some of this identity panel code recently, any idea of what might be different between the two?

Flags: needinfo?(nhnt11)

Could you confirm that I am interpreting this right:

  1. Page info matches identity panel with no proxy/vpn
  2. Page info does not match identity panel when a proxy/vpn is active

That sounds really bizarre. I don't know why one of them gets it right and the other doesn't without digging further.

If my interpretation above is right, I can try and spend a few mins later to repro.

Flags: needinfo?(nhnt11) → needinfo?(florian)

I tried the STR while connected through TunnelBear, and was not able to reproduce the bug.

(In reply to Nihanth Subramanya [:nhnt11] from comment #15)

Could you confirm that I am interpreting this right

That's my understanding too. I couldn't reproduce myself.

Flags: needinfo?(florian)

Sorry for the double-posting. I was able to reproduce this using the Browsec addon.

If you click "View Certificate" from within the Page Info dialog, you'll see that the cert seems unrelated to the site that's loaded in the tab.

I think the next steps would be:

  1. Find out exactly what Browsec is doing
  2. Figure out whether we have some special handling in place for the identity panel to work around this.

Browsec's website says:

If I turn Browsec on, is my connection encrypted?

Yes, Browsec uses IPSec IKEv2 with AES-256 (military-grade) encryption on mobile and HTTP Proxy over TLS with AES-256 encryption when using browser extension. Browsec also protects you from MITM (Man-in-the-middle) attacks and WebRTC leaks.

(https://browsec.com/en/faq)

I believe the cert that the page info dialog is showing details for is the http proxy's cert.

Johann, Paul, do you have any ideas around this? Seems like the identity panel is "smart enough" to display the identity state for the site itself rather than the http proxy applied by the browser extension.

Flags: needinfo?(pbz)
Flags: needinfo?(jhofmann)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: sec-low

(In reply to Nihanth Subramanya [:nhnt11] from comment #15)

Could you confirm that I am interpreting this right:

  1. Page info matches identity panel with no proxy/vpn
  2. Page info does not match identity panel when a proxy/vpn is active

That sounds really bizarre. I don't know why one of them gets it right and the other doesn't without digging further.

If my interpretation above is right, I can try and spend a few mins later to repro.

You are exactly right~
Could you reproduce it?:)Bon week-end!

OK, I got it wrong the first time, here is how it really works:

Both, the site identity panel and the page info window use nsISecureBrowserUI https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/netwerk/base/nsISecureBrowserUI.idl

The difference is that the identity panel checks for STATE_IS_SECURE:
https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/browser/base/content/browser-siteIdentity.js#85

while the security section only checks if the state is not STATE_IS_BROKEN: https://searchfox.org/mozilla-central/rev/d25eb00ab4e90cc0130cd18f303a04cc2a2f8409/browser/base/content/pageinfo/security.js#246
That means it will display certificate info for both, the insecure and the secure state, as long as certificate info (in this case from the proxy) is set.

Flags: needinfo?(pbz)
Assignee: nobody → pbz
Status: NEW → ASSIGNED

I think this is fine since it only marks the site as secure if aState & Ci.nsIWebProgressListener.STATE_IS_SECURE or IDENTITY_MODE_UNKNOWN is set.
When we load a HTTP site with a proxy (tested with the browsec addon) we get STATE_IS_INSECURE.

Flags: needinfo?(pbz)

We've looked at other cases where we use TLS info, and page info is the only one that appears to be making this mistake.

With that in mind, I don't see a reasonable way that this could be abused by an attacker, so I think we're better off unhiding the bug report as suggested by Andrew in comment #8.

Dan, you ended up marking sec-low - would you prefer keeping this hidden or can we open up?

Flags: needinfo?(dveditz)
Summary: Contradictory⚠️Is it "Connection not secure" OR "Connection Encrypted"❓ → Page info window mistakenly displays certificate information from proxy/vpn for http (non-TLS) sites, implying all of the connection is encrypted when that is not the case

many sec-low bugs are unhidden. It's fine when the user risk is low and opening a bug might attract volunteers or give folks a warning. I'm going to remove the sec-low in this case because I don't see how it could be used in an attack. It's wrong information, but it's based on the user's own network settings and buried too deep for spoofing.

Group: firefox-core-security
Flags: needinfo?(dveditz)
Keywords: sec-low

@all
will it be fixed in the next coming 🆕 version?😊

Flags: needinfo?(jhofmann)
Pushed by pzuhlcke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ce9199a9c65c pageinfo: Do not show insecure connections as secure when using a proxy. r=johannh,nhnt11
Flags: needinfo?(pbz)
Pushed by pzuhlcke@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a8aadd76602f pageinfo: Do not show insecure connections as secure when using a proxy. r=johannh,nhnt11
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

Now is Fx 82.0.2 and still hasn't been fixed yet...😱

(In reply to ⚜️Québec🇨🇦Canada🍁 from comment #34)

Now is Fx 82.0.2 and still hasn't been fixed yet...😱

The fix is currently in Nightly and will most likely be included in the 84 release.

(In reply to Paul Zühlcke [:pbz] from comment #35)

(In reply to ⚜️Québec🇨🇦Canada🍁 from comment #34)

Now is Fx 82.0.2 and still hasn't been fixed yet...😱

The fix is currently in Nightly and will most likely be included in the 84 release.

Sounds great:)Thanks!

Reproduced the issue using Firefox 82.0a1 (20200827212940) on Windows 1064 using Browsec addon and link from comment 0.
The issue is verified fixed with Firefox 84.0b3 (20201119195818) on Windows 10x64, macOS 10.12, and Ubuntu 18.04.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

(In reply to Alexandru Trif, QA [:atrif] from comment #37)

Reproduced the issue using Firefox 82.0a1 (20200827212940) on Windows 1064 using Browsec addon and link from comment 0.
The issue is verified fixed with Firefox 84.0b3 (20201119195818) on Windows 10x64, macOS 10.12, and Ubuntu 18.04.

but not fixed with Fx 83.0 on macOS 10.15.7

(In reply to ⚜️Québec🇨🇦Canada🍁 from comment #38)

(In reply to Alexandru Trif, QA [:atrif] from comment #37)

Reproduced the issue using Firefox 82.0a1 (20200827212940) on Windows 1064 using Browsec addon and link from comment 0.
The issue is verified fixed with Firefox 84.0b3 (20201119195818) on Windows 10x64, macOS 10.12, and Ubuntu 18.04.

but not fixed with Fx 83.0 on macOS 10.15.7

No, the fix is only in 84. You can tell because under "Tracking", the "Milestone" field is set to 84, and firefox84 to verified.

(In reply to :Gijs (back Dec 1; he/him) from comment #39)

(In reply to ⚜️Québec🇨🇦Canada🍁 from comment #38)

(In reply to Alexandru Trif, QA [:atrif] from comment #37)

Reproduced the issue using Firefox 82.0a1 (20200827212940) on Windows 1064 using Browsec addon and link from comment 0.
The issue is verified fixed with Firefox 84.0b3 (20201119195818) on Windows 10x64, macOS 10.12, and Ubuntu 18.04.

but not fixed with Fx 83.0 on macOS 10.15.7

No, the fix is only in 84. You can tell because under "Tracking", the "Milestone" field is set to 84, and firefox84 to verified.

Thank you:) Now I learn how to read the "Tracking"

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: