With the HeartBleed bug effectively killing off SSLv3 and vulnerabilities in cipher block chaining ruling out another whole swathe of SSL ciphers, network engineers may have found themselves trying to connect to a device and either getting no response (Safari), or getting a response like this (Chrome):

Or this (Firefox):

Once upon a time, it was possible to go into settings and enable the old, insecure ciphers again, but in more recent updates, those ciphers no longer exist within the code and are thus inaccessible. So what to do? My answer was to try a proxy.

Charles Proxy

The first proxy I looked at seemed promising. Although not free, Charles Proxy offers a 30 day free trial, and that seemed like a good thing to try. It’s limited additionally by only running for 30 minutes at a time before it has to be reloaded, but for my testing purposes that was not a problem.

During installation I declined to give Charles Proxy permission to configure the system proxy settings. Instead, I manually updated just my Firefox browser to use the proxy which was now listening on port 127.0.0.1:8888. Since I was making an SSL connection, I also had to specifically allow the proxy to act as man in the middle, so added my target device to the list. I like that the default is not to intercept SSL; I think that’s a responsible position to take.

And, well, that’s it. I typed the URL into Firefox, and finally I was able to connect to the evil device with the bad ciphers. Once I had updated the firmware, I was able to remove the proxy and uninstall Charles Proxy because the device finally supported some better ciphers.

My 2 Bits

I doubt I’m the only one in possession of devices which are running old firmware. Even if they’re not in production, I’d bet there are a few devices in storage which have this problem, and if they’re ever pulled out of storage to replace a failed device, this will be a problem. Similarly, some older devices may not be receiving firmware updates any more and may never support newer ciphers, and finding a way to access them is important. It has only taken about two years for browser connectivity to go from no problem to inaccessible. I’d complain, but it’s all for the right reasons.

There’s another concern here though, which is that Charles Proxy works for me in this scenario because it still supports SSL ciphers which are considered to be insecure. I’m very pleased that it does, but it does raise the question of whether other commercial proxy solutions have mirrored the browsers in terms of disabling insecure ciphers. If not, there’s a danger that the proxy may be negotiating insecure ciphers and protocols on your behalf, even though the local side of the connection uses more secure ciphers because that’s all the browsers will support. This scenario could also occur on the server side of load balanced connections (for those VIPs which require re-encrypting to SSL on the server side), where some of the weaker/older ciphers may be preferred for an onward SSL connection because they have a lower impact on the encryption capacity of the device.

Meanwhile, I’ll get back to updating my old devices at home!