Comment by zaroth | Hacker News Reader

Comment by zaroth | Hacker News Reader

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...

[2] - https://github.com/joyent/node/blob/master/deps/openssl/open...

Also from the node.js code, four lines up:

  'defines': [
    # No clue what these are for.
    'L_ENDIAN',
    'PURIFY',
    '_REENTRANT',

Lovely. According to https://www.openssl.org/support/faq.html, PURIFY is used to "get rid off the warnings" when using Valgrind. That sounds remarkably similar to the original Debian PRNG openssl bug (wasn't non-PURIFY code deleted just to "get rid off some warnings" with Valgrind? - http://research.swtch.com/openssl)

Node statically links OpenSSL and uses gyp (the chromium build system) to build it.

Initially we used the chromium project OpenSSL fork which had these flags set [1]; when we moved to maintain our own gyp-ified fork we kept these flags [2], under the assumption that the chromium folks would know what they're doing.

You may argue that this is naive and you may be right.

However, just looking at that FAQ, OpenSSL provides a justification why it is safe to ignore the specific valgrind error that -DPURIFY surpresses, so I currently see no reason to change it.

    When OpenSSL's PRNG routines are called to generate random numbers the   
    supplied buffer contents are mixed into the entropy pool: so it 
    technically does not matter whether the buffer is initialized at this 
    point or not. Valgrind (and other test tools) will complain about this. 
    When using Valgrind, make sure the OpenSSL library has been compiled with 
    the PURIFY macro defined (-DPURIFY) to get rid of these warnings.

[1] https://github.com/joyent/node/blob/e80cac622569dda0f6753b45...

[2] https://github.com/joyent/node/commit/7eaea7f9e501db0072455f...

Edit: fixed link

Does PURIFY get rid of the warnings by suppressing them, or by disabling code temporarily for debugging purposes (since it mentions macros)? The FAQ seems unclear on that point.

You can see the code affected by the PURIFY define here:-

https://github.com/joyent/node/search?q=PURIFY

Specifically it is these two files:-

https://github.com/joyent/node/blob/5fcd6e40385f45bc90916893...

https://github.com/joyent/node/blob/c20b209dbb7e2f3ac8a75a87...

In the first it just does a memset of the buffer so that the values are not unset.

In the second it doesn't use a (possibly only partially filled) buffer as a source of entropy.

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?

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.

> 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.

It's potentially useful for TLS over UDP, aka DTLS, which is A Thing. I've seen DTLS used for VPNs, but I think it can be used with things like SIP and WebRTC. I don't know if TLS heartbeats are used in any of these protocols, though.

Reply on news.ycombinator.com