our (quick) fixes are almost all done:
- recompile openssl where necessary (web, chat, mail, windows binaries) without heartbeat support
- roll related certs and keys ASAP
and then comes the painful process of suggesting all web service users roll their certs and auth.
oh, and rotate personal passwords at other sites that issue a warning about openssl...
DTLS is designed to secure traffic running on top of unreliable
transport protocols. Usually such protocols have no session
management. The only mechanism available at the DTLS layer to figure
out if a peer is still alive is performing a costly renegotiation.
If the application uses unidirectional traffic there is no other way.
TLS is based on reliable protocols but there is not necessarily a
feature available to keep the connection alive without continuous
data transfer.
The Heartbeat Extension as described in this document overcomes these
limitations. The user can use the new HeartbeatRequest message which
has to be answered by the peer with a HeartbeartResponse immediately.
Edit: here is the commit patching the bug https://github.com/openssl/openssl/commit/7e840163c06c7692b7...
[0] http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-04
Even though the code got better with this fix I still wouldn't accept code that looks like this in a review. Why are 1, 2, 3, 16 not defines? What's up with the code duplication between files? Where are the unit-tests?
I'm starting to feel that a lot of software that has been around for 10+ years and is commonly used does not live up to current best practices regarding writing good system-level software.
if (1 + 2 + 16 > s->s3->rrec.length)
if (1 + 2 + payload + 16 > s->s3->rrec.length)
This always makes me cringe during code reviews.
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...
.. and if you do, don't do it in a highly memory-unsafe language. Espcially when it's for a security critical piece of central internet infrastructure!
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 security experts like to suggest best practices under such circumstances?
(Edit: It looks like the page I linked above has been updated and a patch is going into Wheezy security as I write this.)
(Edit 2: Confirmed that Wheezy security updates now include openssl 1.0.1e-2+deb7u5 and related libssl changes.)
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.
However, wouldn't OpenSSH be the thing spiped replaces most of the times? And that has a better security track record (I mean, better than OpenSSL for sure).
What would something simpler, less error-prone which would give the same benefits in a client-server connection?
EDIT: Spiped is one, I got it (I'm on it right now and might even use it actually on a side-project), anything else that we should know about? :-)
I avoided ssh because sshd is an effectively unauditable mess, and breaks the "transient network glitches don't kill quiescent connections" assumption.
$ 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
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 < $INPUT
IFS=$OLDIFS
Chinese websites timeout on port 443 so you'll have to skip them.
$ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1| grep 'TLS server extension "heartbeat" (id=15), len=1'
$ echo -e "quit\n" | openssl s_client -connect chubig.net:993 -tlsextdebug 2>&1 | grep 'TLS server extension "heartbeat" (id=15), len=1'
TLS server extension "heartbeat" (id=15), len=1
$
Although there's still the other 103 weeks this was vulnerable to worry about.
>>There is no total of 64 kilobytes limitation to the attack, that limit applies only to a single heartbeat. Attacker can either keep reconnecting or during an active TLS connection keep requesting arbitrary number of 64 kilobyte chunks of memory content until enough secrets are revealed.
Ubuntu should follow really soon, if not already.
Edit: Ubuntu updated: http://www.ubuntu.com/usn/usn-2165-1/
Could a malicious server attack clients? Perhaps expose a browser's cookie jar or other saved passwords in memory?
The number of installed openssl clients across all devices and computers must be quite large.
The browsers? All Apps running on Dalvik? All apps running on ART?
The binary package name is "libssl1.0.0". You want "sudo apt-get update && sudo apt-get install libssl1.0.0", but I suggest that you take all security and regular updates (or set sources.list to security only updates if you insist). Then you can just run "sudo apt-get update && sudo apt-get dist-upgrade" to pick up all updates, without worrying about package names.
If you want to verify if a particular vulnerability is fixed, look in /usr/share/doc/<package>/changelog.Debian.gz. In this case, you want /usr/share/doc/libssl1.0.0/changelog.Debian.gz. In this file, you'll see CVE-2014-0160 mentioned as fixed, which is the universal identifier of this vulnerability.
Hope everyone had forward secrecy on by now.
(Assuming they are deployed in such a way that their long-term authenticity keys are in the memory space of the network service, and not kept on another system or HSM.)
( export CONFIGURE_OPTS='no-hw no-rdrand \
no-sctp no-md4 no-mdc2 no-rc4 no-fips no-engine'; \
brew install https://gist.github.com/steakknife/8228264/raw/openssl.rb )
I mean, it's not a TLS replacement, as it's based on PSK (thus only useable between two mutually trusting peers like me and myself), not PKI.
(Sorry, I'm just still pissed at HN's simple mindedness and try to get more downvotes: https://news.ycombinator.com/item?id=7549916)
I get the impression that this applies to openssl far more than other software. The code base is a mess, and it's security sensitive. So people dare not touch it.
It's a shame that there isn't a better incentive for this particular code base to be fixed.
So the strawmen arguments about it not replacing TLS is not the point.
stud, nginx, stunnel, f5 load balancers and cloudflare will still be needed for now, until 'moxie0 or someone comes up with a viable CA alternative AND something way, way simpler than TLS (brain-hurt ASN1, even with Wireshark).
https://news.ycombinator.com/item?id=7282005
but the thread is a lot heftier now.