SUSE Conversations


Introducing the SUSE Linux Enterprise 11 Security Module

mge1512

By: mge1512

August 22, 2014 2:47 pm

Reads:4,745

Comments:2

Score:5

Print/PDF

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

.

2 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 5 (2 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...

Tags: ,
Categories: Announcements, Enterprise Linux, Server, SUSE Linux Enterprise, SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP Applications, SUSE Linux Enterprise Server for System z, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

2 Comments

  1. By:MARVHUFFAKER

    “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.

    • By:mge1512

      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.

Comment

RSS