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". 


sec

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.

 diffieherror

 

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:

security.ssl3.dhe_rsa_aes_128_sha security.ssl3.dhe_rsa_aes_256_sha

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. 

 

 sec

Banner


Top Level Await Now In V8 But Might Not Be What You Think
22/01/2020

One of the irritations of JavaScript's wonderful async and await approach is that you have to use it in a function. This is a limitation hat seems to be about to go away when you read headlines like " [ ... ]



Groovy 3 Adds Parrot Parser
17/02/2020

The latest version of Apache Groovy is available with with a brand new parser (code-named Parrot) among other improvements. Groovy is an optionally typed and dynamic language, with static-typing and s [ ... ]


More News

 

graphics

 



 

Comments




or email your comment to: comments@i-programmer.info

Last Updated ( Friday, 11 September 2015 )