Mozilla Updates Security Indicators For Firefox

News
By published

Mozilla, along with other browser makers, has been tightening up the rules around HTTPS connections in its Firefox browser by deprecating certain features for HTTP communication and by encouraging web developers to use HTTPS in a stricter fashion. The latest announcement is mainly user-focused by making it more clear just how much security different HTTPS modes provide.

DV Certificates

Up until now, Firefox has been showing a grey lock icon for sites that use Domain Validated (DV) certificates, and a green lock for those that use Extended Validation (EV) certificates. Mozilla realized that many users might not understand the difference and may think the DV sites aren't as secure. That's why Firefox will now show sites that use DV certificates with a green lock as well.

Mixed Active Content

Mozilla has been showing a grey and white shield alongside the lock icon for sites with Mixed Active Content. These are HTTPS sites that also use content served over HTTP that can interact with the rest of the HTTPS website. This leaves the site vulnerable to malicious attacks.

Mozilla will replace the grey and white shield with a green lock icon and a small grey warning sign to signify that the site isn't as secure as it should be. However, those who visit such sites shouldn't worry too much as Firefox automatically blocks the Mixed Active Content by default. This could cause some problems with some sites and users could deactivate this protection, but Mozilla found only a small number of users ever do that.

Mixed Passive Content

Another category of mixed content is called Mixed Passive Content, which mainly refers to embedded images or video being served over HTTP within an HTTPS website. This type of content isn't blocked by default in Firefox.

This was previously reflected in the browser as a grey warning sign. The icon has been updated to a grey lock icon with a vibrant yellow warning sign to show that the site isn't secure. This sign is also shown when the cryptography used by websites has been deprecated by the browser.

Mozilla announced that it made similar changes for its mobile Firefox browser as well.

Lucian Armasu is a Contributing Writer for Tom's Hardware. You can follow him at @lucian_armasu. 

Follow us on Facebook, Google+, RSS, Twitter and YouTube.

Lucian Armasu
Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
15 Comments Comment from the forums
  • targetdrone
    Firefox will not connect to https://www.tomshardware.com/
    Reply
  • Dan Nelson
    17392289 said:
    Firefox will not connect to https://www.tomshardware.com/

    Tom's needs to buy an SSL cert before that'll happen: "The certificate is only valid for the following names: a248.e.akamai.net, *.akamaihd.net, *.akamaihd-staging.net, *.akamaized.net, *.akamaized-staging.net"
    Reply
  • littleleo
    Firefox will not connect to https://www.tomshardware.com/

    Strange I'm using Firefox and reading Tom's w/o issue must be user error, lol.
    Reply
  • ChronosVRdS
    Firefox will not connect to https://www.tomshardware.com/
    Same goes to chrome (or any browser working correctly), Tom's doesn't have a valid certificate, this is expected and means that firefox is behaving correctly.
    Reply
  • kyzarvs
    FF does not work correctly when it behaves the same way for URLS on the local subnet - routers, firewall webguis - those kinda things are working for me in Chrome, not FF.
    Reply
  • ChronosVRdS
    FF does not work correctly when it behaves the same way for URLS on the local subnet - routers, firewall webguis - those kinda things are working for me in Chrome, not FF.
    How so? I don't understand what you mean by that.

    At least for me, both browsers give me errors when accessing pages with self-signed certificates (kinda of ones used by routers and and local services), if you're using your own certification authority, firefox needs you to manually import the CA, Chrome can get it directly from windows trusted repository.
    Reply
  • kyzarvs
    FF does not work correctly when it behaves the same way for URLS on the local subnet - routers, firewall webguis - those kinda things are working for me in Chrome, not FF.
    How so? I don't understand what you mean by that.

    At least for me, both browsers give me errors when accessing pages with self-signed certificates (kinda of ones used by routers and and local services), if you're using your own certification authority, firefox needs you to manually import the CA, Chrome can get it directly from windows trusted repository.

    Example, I have BitDefender running on my mail server, it has a very useful webgui. FF as of recently stopped working going to https://192.168.1.249:8139 and gives you no option to continue. Chrome comes up with the 'this is dumbass, are you sure?' and lets me continue. This behaviour is perfectly correct for internet domains, but gets in the way in 3 of the 5 systems my business works with on the internal network so we've moved to Chrome.
    Reply
  • ChronosVRdS
    17395722 said:
    Example, I have BitDefender running on my mail server, it has a very useful webgui. FF as of recently stopped working going to https://192.168.1.249:8139 and gives you no option to continue. Chrome comes up with the 'this is dumbass, are you sure?' and lets me continue. This behaviour is perfectly correct for internet domains, but gets in the way in 3 of the 5 systems my business works with on the internal network so we've moved to Chrome.
    Ok I get it, AFAIK the only thing I that firefox block without question is services running SSLv3 or lower, since it's completely broken.
    Reply
  • kyzarvs
    17395722 said:
    Example, I have BitDefender running on my mail server, it has a very useful webgui. FF as of recently stopped working going to https://192.168.1.249:8139 and gives you no option to continue. Chrome comes up with the 'this is dumbass, are you sure?' and lets me continue. This behaviour is perfectly correct for internet domains, but gets in the way in 3 of the 5 systems my business works with on the internal network so we've moved to Chrome.
    Ok I get it, AFAIK the only thing I that firefox block without question is services running SSLv3 or lower, since it's completely broken.

    ...and I completely agree with that for any non-local URL - it is absolutely the right thing to do. I just feel that it is very short-sighted to do the same for local subnet URL - there must be dozens of interfaces around that are fine for local use, but FF isn't being smart enough about it's behaviour to at least give the option to accept their shortcomings.
    Reply
  • ChronosVRdS
    17395864 said:
    ...and I completely agree with that for any non-local URL - it is absolutely the right thing to do. I just feel that it is very short-sighted to do the same for local subnet URL - there must be dozens of interfaces around that are fine for local use, but FF isn't being smart enough about it's behaviour to at least give the option to accept their shortcomings.
    Maybe there is, but sounds like you need to change some options on the about:config page, but that can be too much trouble, easier to stay on chrome
    Reply