Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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

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.  
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
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 
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 :(
                "Most of the option if SSL_CTX_set_options are used to work around broken peers..." - perhaps on the server side of things. But I regularly use SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and SSL_OP_NO_COMPRESSION on my clients, and they are clearly not bug work arounds. (I don't use SSL_OP_ALL on the server since only two or so apply. And I always use SSL_OP_CIPHER_SERVER_PREFERENCE on the server).
– jww
                Apr 13, 2014 at 15:21
                OK, these are not workaround against broken peers but against broken implementations :) e.g. SSLv3 is bad, SSLv2 worse, compression has bad side effects and the server cipher_server_preference is needed because the client has no idea what proper ciphers are.
– Steffen Ullrich
                Apr 13, 2014 at 15:25
                @Steffen, SSL_CTX_set_options() is a macro that hides a call to SSL_CTX_ctrl(), but I think your comment is useful because it highlights something important: far too many of the options are used to bypass bugs individually, when -as jww says- disabling SSLv2 and SSLv3 will bypass them all but a couple, rendering all these options more or less useless. Food for thought there. :-)
– guilleamodeo
                Apr 13, 2014 at 19:40
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.