The default bug view has changed. See this FAQ.

When using a HTTPS proxy, HTTP sites incorrectly have lock icon

VERIFIED FIXED in Firefox 33

Status

()

Core
Networking: HTTP
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: snorp, Assigned: mcmanus)

Tracking

unspecified
mozilla34
x86
Mac OS X
Points:
---
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox33 verified, firefox34 verified, firefox35 verified)

Details

(Whiteboard: [spdy])

Attachments

(1 attachment, 1 obsolete attachment)

When a secure proxy is used, such as Janus (https://wiki.mozilla.org/Mobile/Janus), HTTP sites have a lock icon even though there is no end-to-end encryption. I don't think we want to show a lock icon in that case.
(Assignee)

Updated

3 years ago
Component: Location Bar → Networking: HTTP
Product: Firefox → Core
(Assignee)

Updated

3 years ago
Blocks: 378637
(Assignee)

Updated

3 years ago
Whiteboard: [spdy]
(Assignee)

Comment 1

3 years ago
https://tbpl.mozilla.org/?tree=Try&rev=5bdf1d943567
(Assignee)

Comment 2

3 years ago
Created attachment 8463602 [details] [diff] [review]
1040323

its possible for the transport to be secure (in this case TLS fully authenticated in the usual ways) but to be carrying http schemed data that we never want to consider secure from a web ui perspective.

the case here is an http resource being proxied over an https connection on the first hop. it's obviously not secure end to end (as an https resource would be).

I didn't make this change on the connection itself because that can be carrying a variety of schemes across its lifetime.
Assignee: nobody → mcmanus
Attachment #8463602 - Flags: review?(dkeeler)
Comment on attachment 8463602 [details] [diff] [review]
1040323

Review of attachment 8463602 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me.
A couple of nits, however:
* keeping line length under 80 chars would be nice
* the style we're trying to move towards is to use 'Foo* foo' as opposed to 'Foo *foo', but I realize this file is probably very inconsistent in that regard
* do we have an automated test for this?
Also, what about other inherently insecure schemes like ftp?
Attachment #8463602 - Flags: review?(dkeeler) → review+
(Assignee)

Comment 4

3 years ago
(In reply to David Keeler (:keeler) [use needinfo?] from comment #3)


> * do we have an automated test for this?

not yet - we've never had formal proxy tests of any flavor in the CI (adding servers is hard, basically.) and this is sort of the icing on that cake. I'm trying to line up someone to work on that.
(Assignee)

Comment 5

3 years ago
Created attachment 8470852 [details] [diff] [review]
SecureBrowserUI needs to consider scheme, not just security of connection
(Assignee)

Updated

3 years ago
Attachment #8470852 - Flags: review+
(Assignee)

Updated

3 years ago
Attachment #8463602 - Attachment is obsolete: true
(Assignee)

Comment 6

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e13efa1149a1
https://hg.mozilla.org/mozilla-central/rev/e13efa1149a1
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
(Assignee)

Comment 8

3 years ago
Comment on attachment 8470852 [details] [diff] [review]
SecureBrowserUI needs to consider scheme, not just security of connection

Approval Request Comment
[Feature/regressing bug #]:378637
[User impact if declined]: misleading security UI
[Describe test coverage new/current, TBPL]:on m-c
[Risks and why]: feature is on gecko 33 with just this one bug at this time to make it release worthy - needed by the janus project
[String/UUID change made/needed]: none
Attachment #8470852 - Flags: approval-mozilla-aurora?
status-firefox33: --- → affected
status-firefox34: --- → fixed
Attachment #8470852 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: qawanted, verifyme
https://hg.mozilla.org/releases/mozilla-aurora/rev/2bea25f0a82b
status-firefox33: affected → fixed
I was unable to reproduce this issue on Windows 7 64-bit and Mac OS X 10.9.5 using x86 builds of the affected Nightly 2014-07-17 with a HTTPS proxy server.

Patrick, is there something I'm missing here? Per Comment 0, I configured Fx to use my HTTPS server and then accessed a HTTP website such as http://example.net/. The globe icon was displayed at all times.
Flags: needinfo?(mcmanus)
(Assignee)

Comment 11

3 years ago
are you confident your proxy server was being used and being used with tls/ssl?
Flags: needinfo?(mcmanus)
(In reply to Patrick McManus [:mcmanus] from comment #11)
> are you confident your proxy server was being used and being used with
> tls/ssl?

After a short discussion with my Network Admin, it seems that the proxy server I used to test this is in fact *not* using SSL, only my client does for its requests. I'm not quite sure how to work around it, perhaps there's an easier way to test this. Any thoughts?
Patrick, do you have any suggestions here regarding comment 12?
Flags: needinfo?(mcmanus)
(Assignee)

Comment 14

3 years ago
comment 12 does not make any sense. you obviously need a ssl http proxy to test the proxying over ssl feature. squid works.
Flags: needinfo?(mcmanus)
I was able to reproduce the initial bug on Nightly 34.0a1 (Build ID: 20140722030201) using Windows 7 64-bit and Android 4.4.4 with the "Janus Proxy Configurator" add-on.

This is now verified fixed on the mentioned platforms, using:
 * Firefox 33.0b9 (Build ID: 20141002185629),
 * Aurora 34.0a2 (2014-10-06),
 * Nightly 35.0a1 (2014-10-06).
Status: RESOLVED → VERIFIED
status-firefox33: fixed → verified
status-firefox34: fixed → verified
status-firefox35: --- → verified
Flags: qe-verify+
Keywords: qawanted, verifyme
You need to log in before you can comment on or make changes to this bug.