SSL_CTX_set_options.pod revision 261037
12696SN/A=pod 22696SN/A 32696SN/A=head1 NAME 42696SN/A 52696SN/ASSL_CTX_set_options, SSL_set_options, SSL_CTX_clear_options, SSL_clear_options, SSL_CTX_get_options, SSL_get_options, SSL_get_secure_renegotiation_support - manipulate SSL options 62696SN/A 72696SN/A=head1 SYNOPSIS 82696SN/A 92696SN/A #include <openssl/ssl.h> 102696SN/A 112696SN/A long SSL_CTX_set_options(SSL_CTX *ctx, long options); 122696SN/A long SSL_set_options(SSL *ssl, long options); 132696SN/A 142696SN/A long SSL_CTX_clear_options(SSL_CTX *ctx, long options); 152696SN/A long SSL_clear_options(SSL *ssl, long options); 162696SN/A 172696SN/A long SSL_CTX_get_options(SSL_CTX *ctx); 182696SN/A long SSL_get_options(SSL *ssl); 192696SN/A 202696SN/A long SSL_get_secure_renegotiation_support(SSL *ssl); 212696SN/A 2211936Sgdamore@opensolaris.org=head1 DESCRIPTION 232696SN/A 242696SN/ANote: all these functions are implemented using macros. 252696SN/A 269484Sgarrett.damore@Sun.COMSSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>. 279484Sgarrett.damore@Sun.COMOptions already set before are not cleared! 282696SN/A 292696SN/ASSL_set_options() adds the options set via bitmask in B<options> to B<ssl>. 302696SN/AOptions already set before are not cleared! 312696SN/A 322696SN/ASSL_CTX_clear_options() clears the options set via bitmask in B<options> 332696SN/Ato B<ctx>. 342696SN/A 352696SN/ASSL_clear_options() clears the options set via bitmask in B<options> to B<ssl>. 362696SN/A 372696SN/ASSL_CTX_get_options() returns the options set for B<ctx>. 382696SN/A 392696SN/ASSL_get_options() returns the options set for B<ssl>. 409484Sgarrett.damore@Sun.COM 419484Sgarrett.damore@Sun.COMSSL_get_secure_renegotiation_support() indicates whether the peer supports 429484Sgarrett.damore@Sun.COMsecure renegotiation. 439484Sgarrett.damore@Sun.COM 449484Sgarrett.damore@Sun.COM=head1 NOTES 459484Sgarrett.damore@Sun.COM 469484Sgarrett.damore@Sun.COMThe behaviour of the SSL library can be changed by setting several options. 479484Sgarrett.damore@Sun.COMThe options are coded as bitmasks and can be combined by a logical B<or> 489484Sgarrett.damore@Sun.COMoperation (|). 499484Sgarrett.damore@Sun.COM 509484Sgarrett.damore@Sun.COMSSL_CTX_set_options() and SSL_set_options() affect the (external) 519484Sgarrett.damore@Sun.COMprotocol behaviour of the SSL library. The (internal) behaviour of 529484Sgarrett.damore@Sun.COMthe API can be changed by using the similar 539484Sgarrett.damore@Sun.COML<SSL_CTX_set_mode(3)|SSL_CTX_set_mode(3)> and SSL_set_mode() functions. 549484Sgarrett.damore@Sun.COM 559484Sgarrett.damore@Sun.COMDuring a handshake, the option settings of the SSL object are used. When 569484Sgarrett.damore@Sun.COMa new SSL object is created from a context using SSL_new(), the current 579484Sgarrett.damore@Sun.COMoption setting is copied. Changes to B<ctx> do not affect already created 589484Sgarrett.damore@Sun.COMSSL objects. SSL_clear() does not affect the settings. 599484Sgarrett.damore@Sun.COM 609484Sgarrett.damore@Sun.COMThe following B<bug workaround> options are available: 619484Sgarrett.damore@Sun.COM 629484Sgarrett.damore@Sun.COM=over 4 639484Sgarrett.damore@Sun.COM 649484Sgarrett.damore@Sun.COM=item SSL_OP_MICROSOFT_SESS_ID_BUG 659484Sgarrett.damore@Sun.COM 669484Sgarrett.damore@Sun.COMwww.microsoft.com - when talking SSLv2, if session-id reuse is 679484Sgarrett.damore@Sun.COMperformed, the session-id passed back in the server-finished message 689484Sgarrett.damore@Sun.COMis different from the one decided upon. 699484Sgarrett.damore@Sun.COM 709484Sgarrett.damore@Sun.COM=item SSL_OP_NETSCAPE_CHALLENGE_BUG 719484Sgarrett.damore@Sun.COM 729484Sgarrett.damore@Sun.COMNetscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte 739484Sgarrett.damore@Sun.COMchallenge but then appears to only use 16 bytes when generating the 749484Sgarrett.damore@Sun.COMencryption keys. Using 16 bytes is ok but it should be ok to use 32. 759484Sgarrett.damore@Sun.COMAccording to the SSLv3 spec, one should use 32 bytes for the challenge 769484Sgarrett.damore@Sun.COMwhen operating in SSLv2/v3 compatibility mode, but as mentioned above, 779484Sgarrett.damore@Sun.COMthis breaks this server so 16 bytes is the way to go. 789484Sgarrett.damore@Sun.COM 799484Sgarrett.damore@Sun.COM=item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG 809484Sgarrett.damore@Sun.COM 819484Sgarrett.damore@Sun.COMAs of OpenSSL 0.9.8q and 1.0.0c, this option has no effect. 829484Sgarrett.damore@Sun.COM 839484Sgarrett.damore@Sun.COM=item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG 849484Sgarrett.damore@Sun.COM 859484Sgarrett.damore@Sun.COM... 869484Sgarrett.damore@Sun.COM 879484Sgarrett.damore@Sun.COM=item SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER 889484Sgarrett.damore@Sun.COM 899484Sgarrett.damore@Sun.COM... 909484Sgarrett.damore@Sun.COM 919484Sgarrett.damore@Sun.COM=item SSL_OP_SAFARI_ECDHE_ECDSA_BUG 929484Sgarrett.damore@Sun.COM 939484Sgarrett.damore@Sun.COMDon't prefer ECDHE-ECDSA ciphers when the client appears to be Safari on OS X. 949484Sgarrett.damore@Sun.COMOS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers. 959484Sgarrett.damore@Sun.COM 969484Sgarrett.damore@Sun.COM=item SSL_OP_SSLEAY_080_CLIENT_DH_BUG 979484Sgarrett.damore@Sun.COM 989484Sgarrett.damore@Sun.COM... 999484Sgarrett.damore@Sun.COM 1009484Sgarrett.damore@Sun.COM=item SSL_OP_TLS_D5_BUG 1019484Sgarrett.damore@Sun.COM 1029484Sgarrett.damore@Sun.COM... 1039484Sgarrett.damore@Sun.COM 1049484Sgarrett.damore@Sun.COM=item SSL_OP_TLS_BLOCK_PADDING_BUG 1059484Sgarrett.damore@Sun.COM 1069484Sgarrett.damore@Sun.COM... 1079484Sgarrett.damore@Sun.COM 1089484Sgarrett.damore@Sun.COM=item SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS 1099484Sgarrett.damore@Sun.COM 1109484Sgarrett.damore@Sun.COMDisables a countermeasure against a SSL 3.0/TLS 1.0 protocol 1119484Sgarrett.damore@Sun.COMvulnerability affecting CBC ciphers, which cannot be handled by some 1129484Sgarrett.damore@Sun.COMbroken SSL implementations. This option has no effect for connections 1139484Sgarrett.damore@Sun.COMusing other ciphers. 1149484Sgarrett.damore@Sun.COM 1159484Sgarrett.damore@Sun.COM=item SSL_OP_ALL 1169484Sgarrett.damore@Sun.COM 1179484Sgarrett.damore@Sun.COMAll of the above bug workarounds. 1189484Sgarrett.damore@Sun.COM 1199484Sgarrett.damore@Sun.COM=back 1209484Sgarrett.damore@Sun.COM 1219484Sgarrett.damore@Sun.COMIt is usually safe to use B<SSL_OP_ALL> to enable the bug workaround 1229484Sgarrett.damore@Sun.COMoptions if compatibility with somewhat broken implementations is 1239484Sgarrett.damore@Sun.COMdesired. 1249484Sgarrett.damore@Sun.COM 1259484Sgarrett.damore@Sun.COMThe following B<modifying> options are available: 1269484Sgarrett.damore@Sun.COM 1279484Sgarrett.damore@Sun.COM=over 4 1289484Sgarrett.damore@Sun.COM 1299484Sgarrett.damore@Sun.COM=item SSL_OP_TLS_ROLLBACK_BUG 1309484Sgarrett.damore@Sun.COM 1319484Sgarrett.damore@Sun.COMDisable version rollback attack detection. 1329484Sgarrett.damore@Sun.COM 1339484Sgarrett.damore@Sun.COMDuring the client key exchange, the client must send the same information 1349484Sgarrett.damore@Sun.COMabout acceptable SSL/TLS protocol levels as during the first hello. Some 1359484Sgarrett.damore@Sun.COMclients violate this rule by adapting to the server's answer. (Example: 1369484Sgarrett.damore@Sun.COMthe client sends a SSLv2 hello and accepts up to SSLv3.1=TLSv1, the server 1379484Sgarrett.damore@Sun.COMonly understands up to SSLv3. In this case the client must still use the 1389484Sgarrett.damore@Sun.COMsame SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect 1392696SN/Ato the server's answer and violate the version rollback protection.) 1409484Sgarrett.damore@Sun.COM 1419484Sgarrett.damore@Sun.COM=item SSL_OP_SINGLE_DH_USE 1429484Sgarrett.damore@Sun.COM 1439484Sgarrett.damore@Sun.COMAlways create a new key when using temporary/ephemeral DH parameters 1449484Sgarrett.damore@Sun.COM(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>). 1459484Sgarrett.damore@Sun.COMThis option must be used to prevent small subgroup attacks, when 1469484Sgarrett.damore@Sun.COMthe DH parameters were not generated using "strong" primes 1479484Sgarrett.damore@Sun.COM(e.g. when using DSA-parameters, see L<dhparam(1)|dhparam(1)>). 1489484Sgarrett.damore@Sun.COMIf "strong" primes were used, it is not strictly necessary to generate 1499484Sgarrett.damore@Sun.COMa new DH key during each handshake but it is also recommended. 1509484Sgarrett.damore@Sun.COMB<SSL_OP_SINGLE_DH_USE> should therefore be enabled whenever 1519484Sgarrett.damore@Sun.COMtemporary/ephemeral DH parameters are used. 1529484Sgarrett.damore@Sun.COM 1539484Sgarrett.damore@Sun.COM=item SSL_OP_EPHEMERAL_RSA 1549484Sgarrett.damore@Sun.COM 1559484Sgarrett.damore@Sun.COMAlways use ephemeral (temporary) RSA key when doing RSA operations 1569484Sgarrett.damore@Sun.COM(see L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>). 1579484Sgarrett.damore@Sun.COMAccording to the specifications this is only done, when a RSA key 1589484Sgarrett.damore@Sun.COMcan only be used for signature operations (namely under export ciphers 1599484Sgarrett.damore@Sun.COMwith restricted RSA keylength). By setting this option, ephemeral 1609484Sgarrett.damore@Sun.COMRSA keys are always used. This option breaks compatibility with the 1619484Sgarrett.damore@Sun.COMSSL/TLS specifications and may lead to interoperability problems with 1629484Sgarrett.damore@Sun.COMclients and should therefore never be used. Ciphers with EDH (ephemeral 1639484Sgarrett.damore@Sun.COMDiffie-Hellman) key exchange should be used instead. 1649484Sgarrett.damore@Sun.COM 1659484Sgarrett.damore@Sun.COM=item SSL_OP_CIPHER_SERVER_PREFERENCE 1669484Sgarrett.damore@Sun.COM 1679484Sgarrett.damore@Sun.COMWhen choosing a cipher, use the server's preferences instead of the client 1689484Sgarrett.damore@Sun.COMpreferences. When not set, the SSL server will always follow the clients 1699484Sgarrett.damore@Sun.COMpreferences. When set, the SSLv3/TLSv1 server will choose following its 1709484Sgarrett.damore@Sun.COMown preferences. Because of the different protocol, for SSLv2 the server 1719484Sgarrett.damore@Sun.COMwill send its list of preferences to the client and the client chooses. 1729484Sgarrett.damore@Sun.COM 1739484Sgarrett.damore@Sun.COM=item SSL_OP_PKCS1_CHECK_1 1749484Sgarrett.damore@Sun.COM 1759484Sgarrett.damore@Sun.COM... 1769484Sgarrett.damore@Sun.COM 1779484Sgarrett.damore@Sun.COM=item SSL_OP_PKCS1_CHECK_2 1789484Sgarrett.damore@Sun.COM 1799484Sgarrett.damore@Sun.COM... 1809484Sgarrett.damore@Sun.COM 1819484Sgarrett.damore@Sun.COM=item SSL_OP_NETSCAPE_CA_DN_BUG 1829484Sgarrett.damore@Sun.COM 1839484Sgarrett.damore@Sun.COMIf we accept a netscape connection, demand a client cert, have a 1849484Sgarrett.damore@Sun.COMnon-self-signed CA which does not have its CA in netscape, and the 1859484Sgarrett.damore@Sun.COMbrowser has a cert, it will crash/hang. Works for 3.x and 4.xbeta 1869484Sgarrett.damore@Sun.COM 1879484Sgarrett.damore@Sun.COM=item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG 1889484Sgarrett.damore@Sun.COM 1899484Sgarrett.damore@Sun.COM... 1909484Sgarrett.damore@Sun.COM 1919484Sgarrett.damore@Sun.COM=item SSL_OP_NO_SSLv2 1929484Sgarrett.damore@Sun.COM 1939484Sgarrett.damore@Sun.COMDo not use the SSLv2 protocol. 1949484Sgarrett.damore@Sun.COM 1959484Sgarrett.damore@Sun.COM=item SSL_OP_NO_SSLv3 1969484Sgarrett.damore@Sun.COM 1979484Sgarrett.damore@Sun.COMDo not use the SSLv3 protocol. 1989484Sgarrett.damore@Sun.COM 1999484Sgarrett.damore@Sun.COM=item SSL_OP_NO_TLSv1 2009484Sgarrett.damore@Sun.COM 2019484Sgarrett.damore@Sun.COMDo not use the TLSv1 protocol. 2029484Sgarrett.damore@Sun.COM 2039484Sgarrett.damore@Sun.COM=item SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION 2049484Sgarrett.damore@Sun.COM 2052696SN/AWhen performing renegotiation as a server, always start a new session 2069484Sgarrett.damore@Sun.COM(i.e., session resumption requests are only accepted in the initial 2079484Sgarrett.damore@Sun.COMhandshake). This option is not needed for clients. 2089484Sgarrett.damore@Sun.COM 2099484Sgarrett.damore@Sun.COM=item SSL_OP_NO_TICKET 2109484Sgarrett.damore@Sun.COM 2119484Sgarrett.damore@Sun.COMNormally clients and servers will, where possible, transparently make use 21211936Sgdamore@opensolaris.orgof RFC4507bis tickets for stateless session resumption. 2139484Sgarrett.damore@Sun.COM 2149484Sgarrett.damore@Sun.COMIf this option is set this functionality is disabled and tickets will 2159484Sgarrett.damore@Sun.COMnot be used by clients or servers. 2169484Sgarrett.damore@Sun.COM 2179484Sgarrett.damore@Sun.COM=item SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION 2189484Sgarrett.damore@Sun.COM 2199484Sgarrett.damore@Sun.COMAllow legacy insecure renegotiation between OpenSSL and unpatched clients or 2209484Sgarrett.damore@Sun.COMservers. See the B<SECURE RENEGOTIATION> section for more details. 2219484Sgarrett.damore@Sun.COM 2229484Sgarrett.damore@Sun.COM=item SSL_OP_LEGACY_SERVER_CONNECT 2239484Sgarrett.damore@Sun.COM 2249484Sgarrett.damore@Sun.COMAllow legacy insecure renegotiation between OpenSSL and unpatched servers 2259484Sgarrett.damore@Sun.COMB<only>: this option is currently set by default. See the 2269484Sgarrett.damore@Sun.COMB<SECURE RENEGOTIATION> section for more details. 2279484Sgarrett.damore@Sun.COM 2289484Sgarrett.damore@Sun.COM=back 2299484Sgarrett.damore@Sun.COM 2309484Sgarrett.damore@Sun.COM=head1 SECURE RENEGOTIATION 2319484Sgarrett.damore@Sun.COM 2329484Sgarrett.damore@Sun.COMOpenSSL 0.9.8m and later always attempts to use secure renegotiation as 2339484Sgarrett.damore@Sun.COMdescribed in RFC5746. This counters the prefix attack described in 2349484Sgarrett.damore@Sun.COMCVE-2009-3555 and elsewhere. 2359484Sgarrett.damore@Sun.COM 2369484Sgarrett.damore@Sun.COMThe deprecated and highly broken SSLv2 protocol does not support 2379484Sgarrett.damore@Sun.COMrenegotiation at all: its use is B<strongly> discouraged. 2389484Sgarrett.damore@Sun.COM 2399484Sgarrett.damore@Sun.COMThis attack has far reaching consequences which application writers should be 2409484Sgarrett.damore@Sun.COMaware of. In the description below an implementation supporting secure 2419484Sgarrett.damore@Sun.COMrenegotiation is referred to as I<patched>. A server not supporting secure 2429484Sgarrett.damore@Sun.COMrenegotiation is referred to as I<unpatched>. 2439484Sgarrett.damore@Sun.COM 2449484Sgarrett.damore@Sun.COMThe following sections describe the operations permitted by OpenSSL's secure 2459484Sgarrett.damore@Sun.COMrenegotiation implementation. 2469484Sgarrett.damore@Sun.COM 2479484Sgarrett.damore@Sun.COM=head2 Patched client and server 2489484Sgarrett.damore@Sun.COM 2499484Sgarrett.damore@Sun.COMConnections and renegotiation are always permitted by OpenSSL implementations. 2509484Sgarrett.damore@Sun.COM 2519484Sgarrett.damore@Sun.COM=head2 Unpatched client and patched OpenSSL server 2529484Sgarrett.damore@Sun.COM 2539484Sgarrett.damore@Sun.COMThe initial connection suceeds but client renegotiation is denied by the 2549484Sgarrett.damore@Sun.COMserver with a B<no_renegotiation> warning alert if TLS v1.0 is used or a fatal 2559484Sgarrett.damore@Sun.COMB<handshake_failure> alert in SSL v3.0. 2569484Sgarrett.damore@Sun.COM 2579484Sgarrett.damore@Sun.COMIf the patched OpenSSL server attempts to renegotiate a fatal 2589484Sgarrett.damore@Sun.COMB<handshake_failure> alert is sent. This is because the server code may be 2599484Sgarrett.damore@Sun.COMunaware of the unpatched nature of the client. 2609484Sgarrett.damore@Sun.COM 2619484Sgarrett.damore@Sun.COMIf the option B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> is set then 2629484Sgarrett.damore@Sun.COMrenegotiation B<always> succeeds. 2639484Sgarrett.damore@Sun.COM 2649484Sgarrett.damore@Sun.COMB<NB:> a bug in OpenSSL clients earlier than 0.9.8m (all of which are 2659484Sgarrett.damore@Sun.COMunpatched) will result in the connection hanging if it receives a 2669484Sgarrett.damore@Sun.COMB<no_renegotiation> alert. OpenSSL versions 0.9.8m and later will regard 2679484Sgarrett.damore@Sun.COMa B<no_renegotiation> alert as fatal and respond with a fatal 2689484Sgarrett.damore@Sun.COMB<handshake_failure> alert. This is because the OpenSSL API currently has 2699484Sgarrett.damore@Sun.COMno provision to indicate to an application that a renegotiation attempt 2709484Sgarrett.damore@Sun.COMwas refused. 2719484Sgarrett.damore@Sun.COM 2729484Sgarrett.damore@Sun.COM=head2 Patched OpenSSL client and unpatched server. 2732696SN/A 2742696SN/AIf the option B<SSL_OP_LEGACY_SERVER_CONNECT> or 2752696SN/AB<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> is set then initial connections 2762696SN/Aand renegotiation between patched OpenSSL clients and unpatched servers 2779484Sgarrett.damore@Sun.COMsucceeds. If neither option is set then initial connections to unpatched 278servers will fail. 279 280The option B<SSL_OP_LEGACY_SERVER_CONNECT> is currently set by default even 281though it has security implications: otherwise it would be impossible to 282connect to unpatched servers (i.e. all of them initially) and this is clearly 283not acceptable. Renegotiation is permitted because this does not add any 284additional security issues: during an attack clients do not see any 285renegotiations anyway. 286 287As more servers become patched the option B<SSL_OP_LEGACY_SERVER_CONNECT> will 288B<not> be set by default in a future version of OpenSSL. 289 290OpenSSL client applications wishing to ensure they can connect to unpatched 291servers should always B<set> B<SSL_OP_LEGACY_SERVER_CONNECT> 292 293OpenSSL client applications that want to ensure they can B<not> connect to 294unpatched servers (and thus avoid any security issues) should always B<clear> 295B<SSL_OP_LEGACY_SERVER_CONNECT> using SSL_CTX_clear_options() or 296SSL_clear_options(). 297 298The difference between the B<SSL_OP_LEGACY_SERVER_CONNECT> and 299B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> options is that 300B<SSL_OP_LEGACY_SERVER_CONNECT> enables initial connections and secure 301renegotiation between OpenSSL clients and unpatched servers B<only>, while 302B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> allows initial connections 303and renegotiation between OpenSSL and unpatched clients or servers. 304 305=head1 RETURN VALUES 306 307SSL_CTX_set_options() and SSL_set_options() return the new options bitmask 308after adding B<options>. 309 310SSL_CTX_clear_options() and SSL_clear_options() return the new options bitmask 311after clearing B<options>. 312 313SSL_CTX_get_options() and SSL_get_options() return the current bitmask. 314 315SSL_get_secure_renegotiation_support() returns 1 is the peer supports 316secure renegotiation and 0 if it does not. 317 318=head1 SEE ALSO 319 320L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>, 321L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>, 322L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>, 323L<dhparam(1)|dhparam(1)> 324 325=head1 HISTORY 326 327B<SSL_OP_CIPHER_SERVER_PREFERENCE> and 328B<SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION> have been added in 329OpenSSL 0.9.7. 330 331B<SSL_OP_TLS_ROLLBACK_BUG> has been added in OpenSSL 0.9.6 and was automatically 332enabled with B<SSL_OP_ALL>. As of 0.9.7, it is no longer included in B<SSL_OP_ALL> 333and must be explicitly set. 334 335B<SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS> has been added in OpenSSL 0.9.6e. 336Versions up to OpenSSL 0.9.6c do not include the countermeasure that 337can be disabled with this option (in OpenSSL 0.9.6d, it was always 338enabled). 339 340SSL_CTX_clear_options() and SSL_clear_options() were first added in OpenSSL 3410.9.8m. 342 343B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION>, B<SSL_OP_LEGACY_SERVER_CONNECT> 344and the function SSL_get_secure_renegotiation_support() were first added in 345OpenSSL 0.9.8m. 346 347=cut 348