OpenSSL Security Advisory: TLS heartbeat read overrun
1–10 of 88 posts
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#2Ugh, 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.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#3If 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...).
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#4I had to google what "heartbeat extension" does:
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...
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#5"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
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#6"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
Looks like a good use case for Hammer: https://github.com/UpstandingHackers/hammer
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#7"Heartbleed Bug" Q&A: http://heartbleed.com/
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#8In case anyone was wondering why I wrote spiped...
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#9"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
Looks like a good use case for Hammer: https://github.com/UpstandingHackers/hammer
Looks interesting, but static code generation along the lines of Ragel (but more oriented toward binary structures like Protocol Buffers) would be a lot better for performance.
Re: OpenSSL Security Advisory: TLS heartbeat read overrun
#10Check 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