In case anyone was wondering why I wrote spiped...
But it's written in C. So it can't be good!
(Sorry, I'm just still pissed at HN's simple mindedness and try to get more downvotes: https://news.ycombinator.com/item?id=7549916)
OpenSSL Security Advisory: TLS heartbeat read overrun
51–60 of 88 posts
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#52In case anyone was wondering why I wrote spiped...
But it's written in C. So it can't be good! (Sorry, I'm just still pissed at HN's simple mindedness and try to get more downvotes: https://news.ycombinator.com/item?id=7549916 )
Please don't post comments to HN that have no real content.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#53Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#54Earlier quoted context omitted.
But isn't spiped mostly irrelevant here? 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.
spiped should be irrelevant here. But there are a lot of people using PKI where they could be using PSK.
Who, exactly? Distributing shared secrets securely is a non-trivial exercise.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#55Is this something I have to worry about as someone who uses AWS ELB SSL offloading? Hard to tell from the docs.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#56Earlier quoted context omitted.
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.
How do transient network glitches kill the connection? I'm not completely familiar with the ssh wire protocol, but to my knowledge TCP is largely responsible for ensuring the reliability of the virtual circuit even in the event of a transient lower-layer failure.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#57Ugh, that's a horrible vulnerability. We found something similar in nginx a few years ago, and the result is that you can repeatedly open up client connections and dump server memory as it changes, revealing keys and, without any real effort, authentication info and cookies.
not sure what you have to maintain, but it sure sucks having to scramble and fix this right away.
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...
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#58Is this something I have to worry about as someone who uses AWS ELB SSL offloading? Hard to tell from the docs.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#59Unfortunately, if you have been using an AWS ELB to terminate SSL traffic, they are vulnerable to this particular exploit. See this forum post: https://forums.aws.amazon.com/thread.jspa?threadID=149690
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#60How does one go about installing this update on Ubuntu? "sudo apt-get upgrade openssl" didn't do it.
The fix has now been released by Ubuntu, so you can upgrade via the normal methods (apt-get update && apt-get upgrade)
Make sure you check running daemons too... apt-get install debian-goodies; checkrestart