*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> SSL_CTX_set_options (3)              



NAME    [Toc]    [Back]

       SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options,
       SSL_get_options - Manipulate SSL engine options

SYNOPSIS    [Toc]    [Back]

       #include <openssl/ssl.h>

       long SSL_CTX_set_options(
               SSL_CTX *ctx,
               long options ); long SSL_set_options(
               SSL *ssl,
               long options ); long SSL_CTX_get_options(
               SSL_CTX *ctx ); long SSL_get_options(
               SSL *ssl );

DESCRIPTION    [Toc]    [Back]

       The SSL_CTX_set_options() function adds  the  options  set
       via  bitmask in options to ctx. Options already set before
       are not cleared.

       The SSL_set_options() function adds the  options  set  via
       bitmask  in options to ssl. Options already set before are
       not cleared.

       The SSL_CTX_get_options() function returns the options set
       for ctx.

       The SSL_get_options() function returns the options set for

NOTES    [Toc]    [Back]

       The behavior of the SSL library can be changed by  setting
       several  options.   The  options are coded as bitmasks and
       can be combined by a logical or operation (|). Options can
       only be added; they can never be reset.

       The  SSL_CTX_set_options() and SSL_set_options() functions
       affect  the  (external)  protocol  behavior  of  the   SSL
       library.   The  (internal)  behavior  of  the  API  can be
       changed  by  using  the  similar  SSL_CTX_set_mode()   and
       SSL_set_mode() functions.

       During  a handshake, the option settings of the SSL object
       are used.  When a new SSL object is created from a context
       using  SSL_new(),  the  current  option setting is copied.
       Changes to ctx do not affect already created SSL  objects.
       The SSL_clear() function does not affect the settings.

       The   following  bug  workaround  options  are  available:
       www.microsoft.com, when talking SSLv2, if session-id reuse
       is  performed,  the  session-id passed back in the serverfinished
 message is different from the one  decided  upon.
       Netscape-Commerce/1.12,  when  talking  SSLv2,  accepts  a
       32-byte challenge but then appears to only  use  16  bytes
       when  generating  the  encryption keys.  Using 16 bytes is
       acceptable, but it should be acceptable also  to  use  32.
       According to SSLv3 specifications, you should use 32 bytes
       for the challenge when operating in SSLv2/v3 compatibility
       mode,  but this breaks the server. So, 16 bytes is preferable.
  ssl3.netscape.com:443, first a connection is established
  with RC4-MD5. If it resumes, you use DES-CBC3-SHA.
       It should be RC4-MD5 according to, 'cipher_suite'.

              Netscape-Enterprise/2.01              (https://merchant.netscape.com)
 has this bug.  It only shows up
              when  connecting via SSLv2/v3 then reconnecting via
              SSLv3.  The cipher list changes.

              Try connecting  with  a  cipher  list  of  DES-CBCSHA:RC4-MD5.
  Each new connection uses RC4-MD5, but
              a reconnect tries to use DES-CBC-SHA.  So, Netscape
              always  takes  the  first cipher in the cipher list
              when doing a reconnect.  ...  ...   ...   ...   ...
              ...  Disable version rollback attack detection.

              During  the  client  key  exchange, the client must
              send the same information about acceptable  SSL/TLS
              protocol  levels  as  during  the first hello. Some
              clients  violate  this  rule  by  adapting  to  the
              server's  answer.  (Example:  the  client  sends an
              SSLv2 hello and accepts up  to  SSLv3.1=TLSv1.  The
              server  only  understands up to SSLv3. In this case
              the client must still use  the  same  SSLv3.1=TLSv1
              announcement.  Some clients step down to SSLv3 with
              respect to the server's answer and violate the version
  rollback protection.)  Disables a countermeasure
 against an SSL 3.0/TLS 1.0  protocol  vulnerability
  affecting CBC ciphers, which cannot be handled
 by some   broken  SSL  implementations.   This
              option  has  no  effect for connections using other
              ciphers.  All of the above bug workarounds.

       It is usually safe to use SSL_OP_ALL  to  enable  the  bug
       workaround  options  if compatibility with somewhat broken
       implementations is  desired.

       The following modifying options are available: Always create
 a new key when using temporary/ephemeral DH parameters
       (see SSL_CTX_set_tmp_dh_callback()).  This option must  be
       used to        prevent small subgroup attacks, when the DH
       parameters were not generated using "strong" primes  (e.g.
       when  using  DSA-parameters,  see dhparam()).  If "strong"
       primes were used, it is not necessary to generate a new DH
       key   during   each  handshake,  but  it  is  recommended.
       SSL_OP_SINGLE_DH_USE should therefore be enabled  whenever
       temporary/ephemeral  DH  parameters  are used.  Always use
       ephemeral (temporary) RSA key when  doing  RSA  operations
       (see  SSL_CTX_set_tmp_rsa_callback()).   According  to the
       specifications, this is only done when an RSA key can only
       be  used  for  signature  operations  (namely under export
       ciphers with restricted RSA keylength).  By  setting  this
       option,  ephemeral  RSA  keys are always used. This option
       breaks compatibility with the SSL/TLS  specifications  and
       may lead to        interoperability problems with clients.
       Therefore, it should  never  be  used.  Ciphers  with  EDH
       (ephemeral  Diffie-Hellman)  key  exchange  should be used
       instead.  ...  ...  If you accept a  Netscape  connection,
       demand a client cert, have a non-self-signed CA which does
       not have its CA in netscape, and the browser has  a  cert,
       it will crash/hang.  Works for 3.x and 4.xbeta ...  Do not
       use the SSLv2 protocol.  Do not use  the  SSLv3  protocol.
       Do not use the TLSv1 protocol.

RETURN VALUES    [Toc]    [Back]

       The  SSL_CTX_set_options() and SSL_set_options() functions
       return the new options bitmask after adding options.

       The SSL_CTX_get_options() and SSL_get_options()  functions
       return the current bitmask.

HISTORY    [Toc]    [Back]

       SSL_OP_TLS_ROLLBACK_BUG was added in OpenSSL 0.9.6.

       SSL_OP_DONT   INSERT_EMPTY_FRAGMENTS  has  been  added  in
       OpenSSL 0.9.6e.  Versions up  to  OpenSSL  0.9.6c  do  not
       include  the countermeasure that can be disabled with this
       option. In OpenSSL 0.9.6d it was always  enabled.

SEE ALSO    [Toc]    [Back]

       Commands: dhparam(1)

       Functions:     ssl(3),     SSL_CTX_set_tmp_dh_callback(3),
       SSL_CTX_set_tmp_rsa_callback(3), SSL_new(3), SSL_clear(3)

[ Back ]
 Similar pages
Name OS Title
SSL_CTX_get_mode OpenBSD manipulate SSL engine mode
SSL_set_mode Tru64 Manipulate SSL engine mode
SSL_CTX_set_mode Tru64 Manipulate SSL engine mode
SSL_CTX_set_mode NetBSD manipulate SSL engine mode
SSL_get_mode OpenBSD manipulate SSL engine mode
SSL_CTX_set_mode OpenBSD manipulate SSL engine mode
SSL_set_mode OpenBSD manipulate SSL engine mode
SSL_get_mode Tru64 Manipulate SSL engine mode
SSL_CTX_get_mode Tru64 Manipulate SSL engine mode
DtMmdbQuit HP-UX shuts down the DtInfo database engine
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service