An Ubuntu update would be nice right about now. Outside of disabling everything that uses openssl or compiling a new one manually, there's not much I can do to secure my servers at this moment. Meanwhile, I'm guessing a lot of not so nice people are racing to scan IP ranges for this bug.
OpenSSL Security Advisory: TLS heartbeat read overrun
21–30 of 88 posts
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#22Check for the extension: $ echo -e "quit\n" | openssl s_client -connect google.com:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' TLS server extension "heartbeat" (id=15), len=1 This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.
Keep in mind that you have to run this with OpenSSL v1.0.1 and above. Running it on a stock OS X Mavericks install will not detect the extension because v0.9.8 of OpenSSL is installed.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#23Ouch. Does this mean almost every Debian 7 web server out there is probably vulnerable to having its private data for supporting HTTPS compromised? https://security-tracker.debian.org/tracker/CVE-2014-0160 If so, that must be an awful lot of web servers, with a horrendous cost for everyone to buy new certificates etc. if there's no reliable way to determine what if anything was compromised. Would any of our resident…
All reasonable certificate authorities will — at no cost — revoke your existing certificate and issue you a new certificate with the same expiration date as your old certificate. You'd just need to send the CA a new certificate signing request created from a newly-generated RSA key pair.
If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should find a less horrible CA to throw your money at.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#24Check for the extension: $ echo -e "quit\n" | openssl s_client -connect google.com:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1' TLS server extension "heartbeat" (id=15), len=1 This doesn't tell you that the server uses OpenSSL, or that it is vulnerable, simply that it supports the extension.
I wrote a bash script to check the top 1000 websites and huge percentage of them responded with heartbeat extension (30-40%):
INPUT=websites.csv
OLDIFS=$IFS
IFS=,
[ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }
while read rank website
do
echo "checking $website for heartbeat..."
echo -e "quit\n" | /usr/local/bin/openssl s_client -connect $website:443 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
done Chinese websites timeout on port 443 so you'll have to skip them.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#25Ouch. Does this mean almost every Debian 7 web server out there is probably vulnerable to having its private data for supporting HTTPS compromised? https://security-tracker.debian.org/tracker/CVE-2014-0160 If so, that must be an awful lot of web servers, with a horrendous cost for everyone to buy new certificates etc. if there's no reliable way to determine what if anything was compromised. Would any of our resident…
All reasonable certificate authorities will — at no cost — revoke your existing certificate and issue you a new certificate with the same expiration date as your old certificate. You'd just need to send the CA a new certificate signing request created from a newly-generated RSA key pair. If your CA wants you to buy a new certificate to recover from a key compromise, your CA is taking you for a ride, and you should fi…
I think startssl requires $$$$ to revoke and/or reissue those "free" certs before they expire :-/
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#26If your site is protected by CloudFlare (like HN is), you are automatically protected from this vulnerability (see: http://blog.cloudflare.com/staying-ahead-of-openssl-vulnerab... ).
This is perhaps somewhat misleading. It's possible that this bug was being actively exploited before now, so you should change your keys even if you use a CDN (all the majors have already fixed this as far as I'm aware).
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#27In case anyone was wondering why I wrote spiped...
Well, since you mention it, why did you write spiped? It seems like if you just wanted to protect network services from the internet you could have A) segmented your network, B) used ssh, C) used one of the myriad other existing non-TLS tunneling protocols. Doing A might expose you to less risk than B or C, since with tunnels if your client is owned your server is still vulnerable. Of course if you just wanted to code something for fun I totally understand that too. But it seems like there were already alternatives to stunnel (and I don't really get why people use stunnel to begin with)
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#28"Don't roll your own parsers" should really be up there with "Don't roll your own crypto". This advisory is scant on details, but this extension protocol[0] neither looks complex nor beyond mechanical code generation to me. Just simple enough to be dangerous. And it's pretty new, so this must be recently authored vulnerable code. [0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04
2011-12-31, it looks like, so it's been there for a couple of years already (introduced between 1.0.0f and 1.0.1):
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#29"Heartbleed Bug" Q&A: http://heartbleed.com/
Can we please vote this link higher? It's got a ton of information in it.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#30In case anyone was wondering why I wrote spiped...
Well, since you mention it, why did you write spiped? It seems like if you just wanted to protect network services from the internet you could have A) segmented your network, B) used ssh, C) used one of the myriad other existing non-TLS tunneling protocols. Doing A might expose you to less risk than B or C, since with tunnels if your client is owned your server is still vulnerable. Of course if you just wanted to cod…
Segmenting my network isn't an option when "my network" involves machines on multiple continents.
I avoided ssh because sshd is an effectively unauditable mess, and breaks the "transient network glitches don't kill quiescent connections" assumption.