Firefox, Chrome & Opera Block Access To Routers |
Written by Ian Elliot | |||
Wednesday, 09 September 2015 | |||
Due to a heavy-handed approach to security Firefox, Chrome and Opera are causing problems. They block access to routers with inadequate SSL reporting the cryptic message, "Server has a weak ephemeral Diffie-Hellman public key". Web browsers are becoming increasingly authoritarian in their approach to implementing security. The latest step to protect the innocent user is causing a lot of trouble for network administrators. Chrome 45, Firefox 40 and Opera 30 have all started to block HTTPS connections to servers using 512-bit Diffie-Hellman key exchange. The reason is that back in May a group of computer scientists discovered an attack that makes any TLS connection downgrade to 512 bits which can then be cracked in a reasonable time. LOGJAM - Can The NSA Break 1024-bit DHM Keys? Put simply, a 512-bit key is not secure against a serious attack. At the moment it is estimated that it would take a 24-core machine 90 seconds to crack such a key. Moving up to 1024 bits changes the problem to something that needs 45M core years - which is supposed to be within the reach of state agencies. As a response Google, Mozilla and Opera have modified their browsers to detect when 512-bit key TLS connections are possible with a server. However, and this is where the problems begin, rather than simply warning the user, all three browsers simply refuse to go any further until the problem is corrected on the server.
There is a way to temporarily make Firefox proceed with the unsafe connection, but so far no fix has been found for Chrome and Opera. I say "fix" because many users are regarding this behaviour as a bug. The reason is that the end user isn't always able to make the correction to the server and simply blocking access is too draconian a measure. To get around the problem in Firefox, first browse to about:config and search for security.ssl3.dhe and change the two options that appear:
to false.
There are horror stories of users trying to get important documents from faulty servers and being unable to do so because of the block and suffering financial or even legal penalties as a consequence. The most problematic cases, however, are with HTTPS connections to devices, mainly routers, that are behind firewalls and perfectly safe, in the option of their expert users. In these cases the browser simply refusing to connect means that the devices cannot be managed and without access to the management interface they cannot be updated either. There is usually no option to drop back to an HTTP connection and Telnet is normally turned off by default. The only option is to find a browser that will connect- currently IE and Edge will both warn the user but continue with the connection if required. Even then there is often no way to change the connection security. This problem is affecting routers from a wide range of manufacturers including Netgear and Cisco. Some of the routers don't have a management option to change the security of the management connection and in this case the users have no choice but to drop Chrome, Firefox and Opera and work with IE or Edge. If Microsoft goes with the herd and decides to implement the same "protection" then there could be a lot of unusable routers and other devices out there in the near future. Equally if Microsoft doesn't do this then watch out for IE and Edge rising in popularity. The final blow is that often routers, vpn boxes, WiFi access points etc. are left alone doing their jobs for long periods of time until something goes wrong. When such a crisis happens the user is also immediately confronted with another problem in that they are locked out of the management UI and it couldn't happen at a worse time. It is time that browser builders realized that they can and should protect innocent users, but they should not do so by force. There should always be an option to continue into dangerous territory if the user is sure that it is safe, or is willing to risk the small possibility that there might be an ongoing man-in-the-middle attack that would compromise their "secure" connection. The "Server has a weak ephemeral Diffie-Hellman public key" currently signals a bug in the browser rather than the server and it needs to be put right as a matter of urgency. There are a lot of angry people out there wanting a browser that works and at the moment it looks like only IE/Edge fits the description.
More InformationRelated ArticlesLOGJAM - Can The NSA Break 1024-bit DHM Keys? Rowhammer - Changing Memory Without Accessing It What Does The NSA Think Of Cryptographers? Poodle Is A Very Different Sort Of Security Breach Heartbleed - The Programmer's View ShellShock - Yet Another Code Injection Vulnerability Stick Figure Guide To AES Encryption
To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin, or sign up for our weekly newsletter.
Comments
or email your comment to: comments@i-programmer.info |
|||
Last Updated ( Friday, 11 September 2015 ) |