Android OpenSSL has heartbeats disabled
code.google.com
code.google.com
9b4b062 Use OPENSSL_NO_HEARTBEATS for better wpa_supplicant interoperability
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.
# 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',
[2] - https://github.com/joyent/node/blob/master/deps/openssl/open...
Why does it exist and who would want to use it, given that TCP more or less already does the job for you?
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.
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.
'defines': [
# No clue what these are for.
'L_ENDIAN',
'PURIFY',
'_REENTRANT',
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.
[2] https://github.com/joyent/node/commit/7eaea7f9e501db0072455f...
Edit: fixed link
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.