

Android OpenSSL has heartbeats disabled - sanxiyn
http://code.google.com/p/android/issues/detail?id=34212

======
cube00
Good to know my Android powered web servers are safe. Seriously though, is
there any implication of having a vulnerable version of OpenSSL with
heartbeats enabled on a client?

~~~
sanxiyn
Yes, clients are also vulnerable.

[https://github.com/Lekensteyn/pacemaker](https://github.com/Lekensteyn/pacemaker)

~~~
sp332
And if you trust someone else to exploit you for convenience,
[https://reverseheartbleed.com/](https://reverseheartbleed.com/)

------
zaroth
Just that lucky...?

    
    
      9b4b062 Use OPENSSL_NO_HEARTBEATS for better wpa_supplicant interoperability
    

Google linked to this bug report... [1]

    
    
      This is almost identical to an issue we found with openssl 1.0.1b and Juniper
      SBR version v6.13.4949. In our case we traced it to the heartbeat extension.
      When the extension is sent in the ClientHello PEAP negotiation fails with fatal bad
      certificate alert. By adding # define OPENSSL_NO_HEARTBEATS to opensslconf.h we
      disabled the extension and PEAP negotiation is successful.
    

Similar dumb luck in Node.js disabling heartbeats because advertising it in
the ClientHello apparently causes IIS issues [2]

    
    
      # Heartbeat is a TLS extension, that couldn't be turned off or
      # asked to be not advertised. Unfortunately this is unacceptable for
      # Microsoft's IIS, which seems to be ignoring whole ClientHello after
      # seeing this extension.
      'OPENSSL_NO_HEARTBEATS',
    

[1] -
[http://rt.openssl.org/Ticket/Display.html?id=2825&user=guest...](http://rt.openssl.org/Ticket/Display.html?id=2825&user=guest&pass=guest)

[2] -
[https://github.com/joyent/node/blob/master/deps/openssl/open...](https://github.com/joyent/node/blob/master/deps/openssl/openssl.gyp#L1068)

~~~
cheald
I've yet to see anyone actually indicate where heartbeats are useful. So far,
even outside of Heartbleed, it seems like the module is just a source of bugs.

Why does it exist and who would want to use it, given that TCP more or less
already does the job for you?

~~~
colmmacc
It exists to facilitate MTU discovery for DTLS (which is basically TLS over
UDP). By using heartbeats a sender could send a message to the server and
infer through responses and non-responses (and maybe some kind of binary
search) what the path MTU is.

I'm not clear on why layer-7 level MTU discovery is preferable to regular
ICMP-based pMTUd, which actually does work with UDP (though you have to use
recvmsg in a very complicated way) or why fragmented datagrams would be much
of a problem in the first place - but that's the reason.

It isn't useful for TLS over TCP, except maybe as a network timing channel.

~~~
jmalicki
> I'm not clear on why layer-7 level MTU discovery is preferable to regular
> ICMP-based pMTUd, which actually does work with UDP (though you have to use
> recvmsg in a very complicated way)

One big reason is that it's really, really common for ICMP messages to be
dropped by firewalls, which is really unfortunate. Doing it at the protocol
layer ensures that such misconfigured routers don't cause problems for the
application.

> or why fragmented datagrams would be much of a problem in the first place -
> but that's the reason.

Packet loss. If there is 1% IP packet loss, and datagrams are barely over 1
MTU and thus fragmented into two IP packets (such as when an intermediate link
uses IPsec encapsulation, so the IP packet itself gets a little smaller), you
have 1 - (.99)^2 = 1.99% datagram loss. Splitting up the datagrams gets you
down to 1% datagram loss, same as the IP packet loss. Much worse for larger
datagrams.

