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.

Latest Videos FromTom's Hardware
Lucian Armasu
Contributor

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