Is SSL_CTX_set_options() the reason why OpenSSL folk used a compile time OPENSSL_NO_HEARTBEATS to disable TLSv1 Heartbeats?

Question

Soon after learning that recompiling with -DOPENSSL_NO_HEARTBEATS will disable TLSv1 Heartbeats in OpenSSL 1.0.1e, I wondered why it was not a run-time option instead, maybe called something like SSL_OP_NO_TLS_HEARTBEATS.

Therefore I looked into SSL.H and discovered that 'options' is an unsigned long bitmask, which would be 32 or 64 bits depending on the compiling platform/mode, but it seemed that the OpenSSL code assumes is 32 bits, and -more importantly- it means it only has 32 possible options, which seems to have been exhausted already, all except the bit 0x00000400L, I copied them from SSL.H:

/* Option bits for SSL_CTX_set_options() */

#define SSL_OP_MICROSOFT_SESS_ID_BUG                    0x00000001L
#define SSL_OP_NETSCAPE_CHALLENGE_BUG                   0x00000002L
#define SSL_OP_LEGACY_SERVER_CONNECT                    0x00000004L
#define SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG         0x00000008L

#define SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG              0x00000010L
#define SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER               0x00000020L
#define SSL_OP_MSIE_SSLV2_RSA_PADDING                   0x00000040L
#define SSL_OP_SSLEAY_080_CLIENT_DH_BUG                 0x00000080L

#define SSL_OP_TLS_D5_BUG                               0x00000100L
#define SSL_OP_TLS_BLOCK_PADDING_BUG                    0x00000200L

   /***** 0x00000400L SEEMS TO BE THE ONLY OPTION BIT FREE *****/

#define SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS              0x00000800L

#define SSL_OP_NO_QUERY_MTU                             0x00001000L
#define SSL_OP_COOKIE_EXCHANGE                          0x00002000L
#define SSL_OP_NO_TICKET                                0x00004000L
#define SSL_OP_CISCO_ANYCONNECT                         0x00008000L

#define SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION   0x00010000L
#define SSL_OP_NO_COMPRESSION                           0x00020000L
#define SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION        0x00040000L
#define SSL_OP_SINGLE_ECDH_USE                          0x00080000L

#define SSL_OP_SINGLE_DH_USE                            0x00100000L
#define SSL_OP_EPHEMERAL_RSA                            0x00200000L
#define SSL_OP_CIPHER_SERVER_PREFERENCE                 0x00400000L
#define SSL_OP_TLS_ROLLBACK_BUG                         0x00800000L

#define SSL_OP_NO_SSLv2                                 0x01000000L
#define SSL_OP_NO_SSLv3                                 0x02000000L
#define SSL_OP_NO_TLSv1                                 0x04000000L
#define SSL_OP_NO_TLSv1_2                               0x08000000L

#define SSL_OP_NO_TLSv1_1                               0x10000000L
#define SSL_OP_NETSCAPE_CA_DN_BUG                       0x20000000L
#define SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG          0x40000000L

#define SSL_OP_CRYPTOPRO_TLSEXT_BUG                     0x80000000L

Do you think is this the reason why they decided to do -DOPENSSL_NO_HEARTBEATS instead SSL_OP_NO_TLS_HEARTBEATS ? If so, why didn't they use 0x00000400L for SSL_OP_NO_TLS_HEARTBEATS ? I would like to know your opinion on this. Actually, whatever is the output on this survey, it seems that OpenSSL needs to fix their option system, as it seems already exhausted. Please let me know if I am worng there too.

Answer 1

You got it: as [the option system] seems already exhausted.

The last assigned option was for Apple's SecureTransport ECDSA bug (SSL_OP_SAFARI_ECDHE_ECDSA_BUG). It was a previously used value. You can read about the discussion (and the value reuse) at:

• Apple are, apparently, dicks...
• [PATCH] Safari broken ECDHE-ECDSA workaround

---

If so, why didn't they use 0x00000400L for SSL_OP_NO_TLS_HEARTBEATS

I believe SSL_OP_SAFARI_ECDHE_ECDSA_BUG uses it. From [PATCH] Safari broken ECDHE-ECDSA workaround:

+#define SSL_OP_SAFARI_ECDHE_ECDSA_BUG 0x00000400L 

---

I would like to know your opinion on this.

I don't believe its an opinion ;)

Answer 2

Most of the option if SSL_CTX_set_options are used to work around broken peers, so disabling heartbeat does not really fit into the concept yet, e.g. there was probably no SSL stack known which croaked on the existence of offering the acceptance of heartbeats inside the extension part of the hello message.

So the right way might probably be a SSL_ctrl or SSL_CTX_ctrl and actually there is a SSL_CTRL_SET_TLS_EXT_HEARTBEAT_NO_REQUESTS setting. This notifies the peer within the hello message, that it will not accept heartbeat requests. But, it looks like that if the peer just ignores this setting and sends a heartbeat anyway it will dutifully reply to the heartbeat request :(