Uploaded image for project: 'CFEngine Community'
  1. CFEngine Community
  2. CFE-1522

CFEngine fails to compile with pre-0.9.8m OpenSSL versions

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.6.1
    • Labels:
      None

      Description

      During some builds on SLES 10, I get:
      <pre>
      CCLD cf-agent
      /root/core-3.6rc2-build1/libpromises/.libs/libpromises.so: undefined reference to `SSL_CTX_clear_options'
      collect2: ld returned 1 exit status
      </pre>

      The reason is that SSL_CTX_clear_options was introduced first in OpenSSL 0.9.8m, whereas SLES 10 use 0.9.8a: https://www.openssl.org/docs/ssl/SSL_CTX_set_options.html (bottom)

      According to this page, this function can be used to disable things like legacy renegotiation support ( SSL_OP_LEGACY_SERVER_CONNECT and SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION ), which is confirmed by the comment in CFEngine source code:
      <pre>
      /* Clear all flags, we do not want compatibility tradeoffs like

      • SSL_OP_LEGACY_SERVER_CONNECT. */
        SSL_CTX_clear_options(ssl_ctx, SSL_CTX_get_options(ssl_ctx));
        </pre>

      The OpenSSL documentation states:
      <pre>
      If the option SSL_OP_LEGACY_SERVER_CONNECT or SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set then initial connections and renegotiation between patched OpenSSL clients and unpatched servers succeeds. If neither option is set then initial connections to unpatched servers will fail.

      The option SSL_OP_LEGACY_SERVER_CONNECT is currently set by default even though it has security implications: otherwise it would be impossible to connect to unpatched servers (i.e. all of them initially) and this is clearly not acceptable. Renegotiation is permitted because this does not add any additional security issues: during an attack clients do not see any renegotiations anyway.

      As more servers become patched the option SSL_OP_LEGACY_SERVER_CONNECT will not be set by default in a future version of OpenSSL.

      OpenSSL client applications wishing to ensure they can connect to unpatched servers should always set SSL_OP_LEGACY_SERVER_CONNECT

      OpenSSL client applications that want to ensure they can not connect to unpatched servers (and thus avoid any security issues) should always clear SSL_OP_LEGACY_SERVER_CONNECT using SSL_CTX_clear_options() or SSL_clear_options().

      The difference between the SSL_OP_LEGACY_SERVER_CONNECT and SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION options is that SSL_OP_LEGACY_SERVER_CONNECT enables initial connections and secure renegotiation between OpenSSL clients and unpatched servers only, while SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION allows initial connections and renegotiation between OpenSSL and unpatched clients or servers.
      </pre>

      It means that using CFEngine default implementation, it is not possible to disable selectively this SSL_CTX_clear_options function as it would mean that if a client would be to meet an unpatched server, the connection would fail => "If neither option is set then initial connections to unpatched servers will fail. ".

      Quite a lot of Linux OSes are in the following case:

      • SLES 10 and SLES 11 do not support this function (OpenSSL 0.9.8a and 0.9.8h respectively)
      • Debian 6+, RHEL6+ and Ubuntu Precise (12.04+) support it, older versions do not

      Disabling this function would mean enabling compatibility flags again, allowing clients without secure renegociation support to connect/compile, but would go in the opposite way the original developper of this code snippet seemed to want. This needs careful review.

        Attachments

          Release management

            Activity

              People

              Assignee:
              a10038 jimis (Dimitrios Apostolou)
              Reporter:
              Kegeruneku Matthieu CERDA
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: