Introducing the SUSE Linux Enterprise 11 Security Module | SUSE Communities

Introducing the SUSE Linux Enterprise 11 Security Module

Share
Share

More on TLS and SSL

SUSE has released the “SUSE Linux Enterprise 11 Security Module”, providing enhancements to SUSE Linux Enterprise 11 SP3, which allow customers and partners to build TLS 1.2 compliant infrastructures beyond the https protocol.

Looking back …

As discussed in my former blog about TLS 1.2, we do not provide OpenSSL 1.x in the default packaging of SUSE Linux Enterprise 11, but suggest and support to use the NSS library with Apache’s mod_nss to achieve TLS 1.2 with Perfect Forward Secrecy. This is also the reason, why SUSE Linux Enterprise and our customers were not directly affected by the OpenSSL Heartbleed Vulnerability earlier this year, fortunately.

New requirements

However, we learned that there are a number of customers and partners who need TLS beyond the Web/HTTPS use case. Specifically we have been approached to support TLS 1.2 powered email environments. Postfix, the preferred secure MTA, does not work with the NSS library, but requires OpenSSL.

Should we simply add a second OpenSSL library to SUSE Linux Enterprise 11?

While this sounds appealing, this would have been a dangerous path to go: people could be tempted to “mix” OpenSSL versions despite the “backward compability nightmare” named OpenSSL (see my last blog). Worst case, existing applications would have crashed unexpectedly. Thus we had to deliver Postfix with a more recent OpenSSL in a way, which clearly separates the new OpenSSL packages from the standard SUSE Linux Enterprise 11 packages.

In addition, we considered that there will be more applications requesting TLS 1.2. Customers and partners have their own applications they want to (re)compile and make ready for TLS 1.2. Thus we should also ship development packages for that more recent OpenSSL, and do this in a way that again is separated from the default OpenSSL, but easy to develop upon, build against and use.

OpenSSL 1.0.1g for SUSE Linux Enterprise 11

Thus we now deliver the OpenSSL 1.0.1g packages for SUSE Linux Enterprise 11 SP3+ in an independent repository called “SUSE Linux Enterprise 11 Security Module”. It is available to all customers with a SUSE Linux Enterprise Server subscription.

We adapted the default OpenSSL for a smooth installation in parallel to the new OpenSSL — at least for the runtime libraries and tools. This was done in a regular OpenSSL maintenance update earlier in 2014.

How to use it

On a SUSE Linux Enterprise Server 11 system which is registered to the Customer Center, first check, if your system already sees the SLE11-Security-Module:

# zypper lr | grep Security
16 | nu_novell_com:SLE11-Security-Module | SLE11-Security-Module | No | Yes

(If this fails,, please make sure your registration has been successful, and the system recently refreshed its repository list from our Customer Center). Afterwards enable the Module:

# zypper mr --enable SLE11-Security-Module

Once you have installed at least the packages “libopenssl1_0_0-1.0.1g” (runtime libraries) and “openssl1-1.0.1g” (tools), the file /usr/share/doc/packages/openssl1/README.SuSE has more information how to build with libopenssl1. You find background on “Shadow Libraries” as part of the module, and some other technical details, e.g. why you can either compile and link against 0.9.8 or against 1.0.1, but never both.

The result

You get a runtime environment which allows to have both libraries, OpenSSL 0.9.8 and OpenSSL 1.0.1, installed in parallel, but in an environment and framework which helps to prevent “mixed use” within one application or development project.

You get the Postfix MTA as a fully supported application linked against OpenSSL 1.0.1. This postfix package is named postfix-openssl1.

As a developer or system integrator, you will find a number of libraries, which help you to build your own applications.

Please note that adding this channel does not automatically change existing applications to use openssl 1.0.1. Unless ported they will still use the SUSE Linux Enterprise 11 openssl 0.9.8j version.

Don’t hesitate to reach out to us with questions and ideas.

The upcoming SUSE Linux Enterprise 12 product family will include recent versions of OpenSSL, the NSS library and other crypto libraries right from the start.

Enjoy!

FAQ

Will the packages of the SUSE Linux Enterprise 11 Security Module be available in the Open Build Service (OBS)?

To not open a door for mixing the OpenSSL 0.9.8 and 1.0.1 worlds accidentally, packages from the SUSE Linux Enterprise 11 Security Module are not available as part of the standard SUSE Linux Enterprise 11 build target; instead we have published the packages in the “SUSE:SLE-11-SP3:Update” project, repository “security”.

To build against them on OBS, add this line to your repository additionally:

<path project="SUSE:SLE-11:SP3:Update" repository="security"/>

and buildrequire at least the libopenssl1-devel package. Alternatively, you can direclty build against the repository

SUSE:SLE-11:SP3:Update

.

Share

Comments

  • Avatar photo MARVHUFFAKER says:

    “build your own applications.
    Please note that adding this channel does not automatically change existing applications to use openssl 1.0.1. Unless ported they will still use the SUSE Linux Enterprise 11 openssl 0.9.8j version.”

    This document NEEDS to explain how to make the above statement happen. What good is installing openssl 1.0.1 if it still uses the old version? Basicallyl it provides a worthless exercise. Novell and SLES customers of both SLES11 and OES11 NEED to know how to get openssl1.0.1 working on their systems.

    The README doc mentioned doesn’t provide any info, and the INSTALL doc mentioned is not something that your typical network administrator is going to understand. There are too many assumptions and compiling code is just not something that “admin” type folks do very often. Especially with proprietary enterprise software that is generally prebuilt and delivered from the Novell channel.

    Novell needs to either provide a package that is precompiled and can be applied easily via the channel, or provide a clear step by step guide, with no assumptions or vague developer references, in order to get this working. For example, even the INSTALL file mentions running “./config”. What does this mean? Where is it? There are hundreds of files named “config” on any system but none of that I can find seem to have any relation to the openssl package..

    With all the CVE’s as of late, customers are pushing hard to get stronger security, and there is just no information out there on how to actually make 1.0.1 work in production.

    • Avatar photo mge1512 says:

      Thanks for your suggestions. Please read my first blog about TLS 1.2 again, to understand how all web related SSL/TLS communication is handled independently of OpenSSL, and why replacing the OpenSSL version built into SUSE Linux Enterprise 11 is not a realistic option. We will continue to improve our documentation for the SUSE Linux Enterprise 11 Security Module.

  • Avatar photo dkatare says:

    Does openssl1 1.0.1g is protected from TLS1/SSLv3 Renegotiation Vulnerability as opensll 0.9.8j still be present in suse because of other dependency.

    My acunetix scan shows TLS1/SSLv3 Renegotiation Vulnerability is present even after i upgraded to openssl1 1.0.1g. I am using jboss 6.3.0 GA.

  • Avatar photo mge1512 says:

    With respect to openssl, yes, we have backported the fix for CVE-2009-3555, see:
    https://www.suse.com/security/cve/CVE-2009-3555.html

    I can’t say, though, which openssl version your jboss is linked against and thus, if it consumes the benefits of openssl 1.0.1g from the security module.

    Remember: openssl 1.0.1g is not a drop-in replacement for openssl 0.9.8 (see my other blog for an explanation).

  • Avatar photo corey_ashford says:

    Can you talk about the long-term support strategy for openssl-1.0.1g (and beyond) in this security module? Is there an online document somewhere that describes SUSE’s commitment to this module? Thank you.

  • Avatar photo shrik_dr says:

    I am trying to use SLE11-Security-Module on SLES11SP3 but not able to find this bundle in SUSE repository (“SUSE:SLE-11-SP3:Update” project, repository “security”).

    I am able to locate the link (https://build.opensuse.org/project/repositories/SUSE:SLE-11:SP3:Update) for this module but that is broken. Please can you help me to locate it ??

    • Avatar photo mge1512 says:

      The SLE11-Security-Module is available as a separate repository, once you have registered your SUSE Linux Enterprise Server system. I suggest, you work with your Customer Care contact, if you have issues to access the repository.

      • Avatar photo shrik_dr says:

        Hi ,

        Thanks for the info. Now I got SLE11-Security-Module RMPs. I have two more questions now.

        1) As this module is supported only from SLES11-SP3, can I have OS running with SLES11-SP2 kernel and SLES11-SP3 user space libraries with openssl given here ?

        Actually my requirement is that, I have a product and we modified few things in SLES11-SP2 kernel to make it work properly. So I wanted to keep the SLES11-SP2 kernel and take the latest userspace libraries from SLES11-SP3.

        2) How can make existing application running using openssl-.9.8 to use openssl-1.0.1 installed using this module ??

        Thanks
        Shrik_dr

  • Avatar photo leizerbeam says:

    Hi guys – we are happy you have come out with an updated openssl module however, we have dependent modules that have to be recompiled as a result (i.e. apache and openssh) – since this patch is packaged alongside the original openssl0.9.8, we have to manually repackage apache and openssh to continue – is there going to be a repackaging of all dependent openssl libraries?

  • Avatar photo fan_fei says:

    I have multiple virtual host configured. Through some test i found that
    NSSNickname can be defined in a virtual host context, means that different virtual host can have different certificate nickname
    NSSCertificateDatabase will not work if you specify different value for it in different virtual host context, even you set different value for it for different virtual host, only one will take effect

    NSSDBPrefix the same as NSSCertificateDatabase

    is this a bug or not?
    why only the first directive can take effect in a virtual host context?

  • Avatar photo davehowland says:

    I have followed the instructions to install OpenSSL1.0.1g and that works fine. I then rebuilt curl using the new 1.0.1g libraries and that now has support for TLSv1.2 – so far so good. However this has now broken zypper, which reports a Segmentation Fault when trying to run “zypper refresh” or “zypper update”. I have run this under strace and these are the last 20 lines:

    time(NULL) = 1458216326
    uname({sys=”Linux”, node=”ssltest”, …}) = 0
    write(3, “2016-03-17 12:05:26 ssltest(“…, 92) = 92
    time(NULL) = 1458216326
    uname({sys=”Linux”, node=”ssltest”, …}) = 0
    write(3, “2016-03-17 12:05:26 ssltest(“…, 97) = 97
    time(NULL) = 1458216326
    uname({sys=”Linux”, node=”ssltest”, …}) = 0
    write(3, “2016-03-17 12:05:26 ssltest(“…, 190) = 190
    open(“/etc/ssl/openssl.cnf”, O_RDONLY|O_LARGEFILE) = 4
    fstat64(4, {st_mode=S_IFREG|0644, st_size=9374, …}) = 0
    mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7759000
    read(4, “#n# OpenSSL example configuratio”…, 4096) = 4096
    read(4, “_name ]ncountryNamettt= Country “…, 4096) = 4096
    read(4, ” an SSL server.n# nsCertTypettt=”…, 4096) = 1182
    read(4, “”, 4096) = 0
    close(4) = 0
    munmap(0xb7759000, 4096) = 0
    — SIGSEGV (Segmentation fault) @ 0 (0) —
    +++ killed by SIGSEGV +++

    What can I do to resolve this? I need to be able to support TLSv1.2 but I also need to be able to keep the system up to date.

    Dave.

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Avatar photo
    53,756 views