User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:18.104.22.168) Gecko/2008070206 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:22.214.171.124) 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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
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.
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.
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.
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
Status: RESOLVED → VERIFIED
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.
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...
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.
You need to log in before you can comment on or make changes to this bug.