450737 - Secure site, yet gray security bar and "connection ... not encrypted"

Status: VERIFIED INVALID

(Firefox :: Security, defect)

Description

[Graham Leggett]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

When an attempt is made to visit the secure URL https://www.iboxav.co.uk/login.aspx, the browser successfully displays the page without error or warning.

The security bar however stays gray, and the security information claims that the connection is not encrypted.

To an unsophisticated user, they will assume that the website is legitimate because no warnings appeared.

An attempt to connect to the webserver directly using openssl shows that a certificate is present, but it is not clear whether this certificate is signed by a CA (the openssl output is not unambiguous):

[root@chandler ~]# openssl s_client -connect www.iboxav.co.uk:443
CONNECTED(00000003)
depth=0 /C=GB/O=www.iboxav.co.uk/OU=GT07200511/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL(R)/CN=www.iboxav.co.uk
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=GB/O=www.iboxav.co.uk/OU=GT07200511/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL(R)/CN=www.iboxav.co.uk
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=GB/O=www.iboxav.co.uk/OU=GT07200511/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL(R)/CN=www.iboxav.co.uk
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=GB/O=www.iboxav.co.uk/OU=GT07200511/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL(R)/CN=www.iboxav.co.uk
   i:/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTTCCAragAwIBAgIDByhEMA0GCSqGSIb3DQEBBAUAMFoxCzAJBgNVBAYTAlVT
MRwwGgYDVQQKExNFcXVpZmF4IFNlY3VyZSBJbmMuMS0wKwYDVQQDEyRFcXVpZmF4
IFNlY3VyZSBHbG9iYWwgZUJ1c2luZXNzIENBLTEwHhcNMDcxMTE0MTQyMTUwWhcN
MDgxMjE0MTQyMTUwWjCBvDELMAkGA1UEBhMCR0IxGTAXBgNVBAoTEHd3dy5pYm94
YXYuY28udWsxEzARBgNVBAsTCkdUMDcyMDA1MTExMTAvBgNVBAsTKFNlZSB3d3cu
Z2VvdHJ1c3QuY29tL3Jlc291cmNlcy9jcHMgKGMpMDcxLzAtBgNVBAsTJkRvbWFp
biBDb250cm9sIFZhbGlkYXRlZCAtIFF1aWNrU1NMKFIpMRkwFwYDVQQDExB3d3cu
aWJveGF2LmNvLnVrMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDIocbBrdeY
6CZeV93TD3hTP6vxDJ/fzVd0Wmf+QMyLifWmnPWCiVgZz6JyozEb/muW80IN2FUu
CSnNVX8T/1NfidWb+1ukKapwNF0zUSnz2gpMjcWNDm2Q63Xys3TqBvT2sU4Y0z6+
vB364jpk/l0DA4IPUyqC+etYe74cb8uSsQIDAQABo4G9MIG6MA4GA1UdDwEB/wQE
AwIE8DAdBgNVHQ4EFgQUPmRsFLs9Xms7DSwUkVuuui+5Bh8wOwYDVR0fBDQwMjAw
oC6gLIYqaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9nbG9iYWxjYTEuY3Js
MB8GA1UdIwQYMBaAFL6ooHRyUGtEt8kj2Puo/7NXa2hsMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB
ADcJIQCrXFbf2HlwhetQzCJVhOVjhALuwegru+RRYbZfl7pTgnsKZtfFtegc8Rzb
VOpWQI0Hl5kIE0hunjZsGlvfZT1eMb14VwDkXaitJu5Uuti6pBXZPIQ2GLLQviFD
2zMYBTqKF+mCxx1OP/tEgYp7hTy8wMpWbKNQf+RaCoXW
-----END CERTIFICATE-----
subject=/C=GB/O=www.iboxav.co.uk/OU=GT07200511/OU=See www.geotrust.com/resources/cps (c)07/OU=Domain Control Validated - QuickSSL(R)/CN=www.iboxav.co.uk
issuer=/C=US/O=Equifax Secure Inc./CN=Equifax Secure Global eBusiness CA-1
---
No client certificate CA names sent
---
SSL handshake has read 985 bytes and written 315 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: C8230000E9BA0A5A1C4B6A55DBCEAB11AC478887635BFFAA5FD509B21B9DCB8D
    Session-ID-ctx: 
    Master-Key: 1D0E540803F6AF08996090C15165EF2ACBA550A893C045D9809DA7D10114470D48DB2F7B873700A1EA654D6FB17BD8DC
    Key-Arg   : None
    Krb5 Principal: None
    Start Time: 1218800857
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
read:errno=104


Reproducible: Always

Steps to Reproduce:
xxx

Comment 1

[Johnathan Nightingale [:johnath]]

This behaviour is by design.

The site is loaded over https, but several of the resources on the page, including javascript code, are loaded over http - that is, the site has "mixed content."  You can confirm this by clicking "more information" from the site identity popup to get the more technically detailed information.

A site which loads insecure javascript has no integrity of content or transmitted data, since the javascript can be altered in-flight, and used to change the page in arbitrary ways.

Technologically, there is a difference between "unencrypted" and "some components encrypted", but in terms of the decisions users make, there isn't.  In both cases, all content on the page should be treated as unprotected.

We don't display errors or warnings on pages that are all http, so we won't display them on ones that are partially https.  However, we will also not provide any of the UI feedback to suggest that the site is protecting your data from eavesdroppers, or comes from a verified source.

Comment 2

[Graham Leggett]

This is fundamentally and completely broken.

A website with mixed content is a broken website, and should be treated with the exact same level of security paranoia as a website with a broken certificate, just as browsers have done since SSL was first introduced.

I would suggest you spend some time with real ordinary everyday users to gauge what the real understanding is about online security. Users respond to big scary warnings, not subtle changes of colour on a tiny part of the screen.

And the messages "This website does not supply identity information" and "Your connection to this website is not encrypted" are completely bogus - the real error is one of mixed content.

How on earth are end users supposed to trust online sites if their web browser is incapable of giving them an accurate assessment as to the security status of the website? This is the kind of brain dead security issue I would expect to find in a Microsoft web browser, not Mozilla.

Comment 3

[Johnathan Nightingale [:johnath]]

I'm sorry that the issue causes this much bile for you, but I hope you'll understand that while I spend a lot of time thinking about precisely these questions and am always interested in finding better solutions in discussion with the security community, I have substantially less interest in being abusively lectured, and less still in being insulted.  I commend your zeal, security is a hard thing to get right and there's more nuance than absolute truth much of the time, as I'm sure you appreciate, but I'm just not going to have a discussion that starts with the assumption that throwing feces at each other is a good way to communicate.

Comment 4

[Graham Leggett]

Let me paint the bigger picture here.

A significant amount of money is invested in the internet ecommerce industry, and this industry stands and falls based on the trust end users have for online commerce.

The web browser represents a key part of the end user's experience, and the user puts a significant amount of trust into the proper operation of their web browser to warn them clearly and unambiguously when a security issue exists that they should be aware of.

In practical reality, this means that end users are trusting the *developers* of their web browser to be doing "the right thing" when it comes to security. That means that end users are trusting *you*.

When someone takes the trouble to put together a bug report, you don't fob that end user off with "This behaviour is by design" and immediately mark it as "resolved invalid". You did not wait for anybody else on the long list of CCed people to respond with their comments, you just slammed the phone down on the discussion in the rudest way possible. So expect nothing less than annoyance in return.

So back to the point at hand.

Right now, FF will happily show a mixed content page to an end user without any errors or warnings at all. In addition, when such a site is encountered, FF will claim that the connection was not encrypted when it was partially encrypted, and that no identity information exists when identity information does exist for some elements on the page.

To sum up, FF cannot be trusted to give a clear, unambiguous and accurate assessment of the security risk faced by the end user, and I believe this represents major breakage.

Comment 5

[Matthias Versen [:Matti]]

If you searched in the database you would have known that this is not the first report about that issue. Why do you think that this is the first discussion about this issue in 3 years and why Do you think that the developers didn't think about this issue before they implemented it ?
Marking invalid is the right solution, from the status description :
" INVALID
    The problem described is not a bug."
Johnathan gave you a long explanation why this bug is invalid, just adding a comment "this is by design" would be enough here in bugzilla.

Many users don't know what "mixed content" means and the decision from the Mozilla developers is to show only "secure" or "not secure" and a mixed content page is not secure. There is from the security point of view not difference between unencrypted and mixed content.
If you are want to know why this is not secure then use the more information button. 

verified invalid

Comment 6

[Graham Leggett]

I am quite confident that the developers didn't think about this issue before they implemented it. The evidence is clear: any attempt at discussion is cut off immediately, and despite this issue being raised by many people, you choose to continue to ignore it.

You have yet to answer the following challenge:

- In the light of the fact that end users do not know what "mixed content" means or why it is dangerous, please justify why it is acceptable for a website hosted on a secure webserver to contain mixed content and *not* show a clear and unambiguous warning to the end user, as is done when an untrusted or invalid certificate is present.

"We discussed it internally" is not a justification, nor is "it is by design".

Try again.

Comment 7

[Eddy Nigg (StartCom)]

Well, Johnathan, perhaps we should treat pages with mixed content the same as with all other SSL errors...

OR

...simply don't connect and don't include any resource which aren't over SSL. This could be an interesting solution...

Comment 8

[Matthias Versen [:Matti]]

Don't including content that is not from https would break the whole page in many cases (no css or JS).

Displaying a ssl error would be wrong because there is no ssl error. 
The security state of a mixed content page is the same as a http page.