I’ve had my attention drawn to Randall Munroe’s take on the openssl coding change problem.
Beautiful.
Archive for the ‘security’ Category
xkcd on the openssl fiasco
Thursday, June 5th, 2008debian and the openssl flaw
Monday, June 2nd, 2008Ben Laurie wrote about the Debian SSL problem a couple of weeks ago. That particular post has attracted a huge response which is well worth reading if you care about free open source software and/or privacy/security issues (or even if you don’t). The key point to take from the discussion is that about two years ago the Debian development team “fixed” a perceived problem in openssl and in so doing actually introduced a fairly serious vulnerability. The net result of this change was that anyone using Debian or a related distribution such as Ubuntu to generate a cryptographic key based on the “fixed” opensssl libraries actually left themselves open to compromise. To quote from the Debian advisory “the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable…….. affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections.”
Fortunately, it seems that GPG keys are not affected (and in any case, my own key was generated some time ago and not on a Debian based system) but this is pretty serious nonetheless and means that a great many people (myself included) have been relying on keys which it turns out are vulnerable to attack. I have now regenerated all the keys I suspect were vulnerable, but that does not leave me feeling very comfortable about past usage.
I don’t want to denigrate the Debian team in any way, but I can’t help but agree with Ben Laurie’s view that the proper place to fix any perceived flaw in an open source product, particularly one as important as a security critical component, is in the upstream package – not in the distribution.
ssh through http proxy
Saturday, March 1st, 2008On a mail list I subscribe to I have recently been involved in a discussion about the restrictions sometimes placed on users of WiFi hotspots or hotel networks (to say nothing of the restrictions placed on corporate networks). Some of the suggested solutions involve tunnelling ssh connections over http(s). Other solutions assume that the network is simply restricting access with packet filters so that you may just need to connect to a non-standard port (such as 80 or 443). If this is the case, then you simply have to configure your target ssh daemon to listen on that port. However, some networks force you through a proxy, in which case you need a utility like corkscrew. I had not previously heard of this neat little utility – but it turns out to merit some exploration if you find yourself needing such a tool.
Corkscrew is relatively simple to set up, but if you have problems, take a look at Andrew Savory’s blog entry of 27 February 2008.
