TLS 1.2
Summary
SUSE has just released a new Apache webserver module, which supports the “Transport Layer Security” (TLS 1.2) standard for HTTPS, the primary use case of the TLS cryptographic protocol.
Details
Background
Governmental agencies around the world, such as the US American NIST (NIST SP 800-52 Rev.1) and the German BSI (BSI TR-02102-2) have recently issued guidance to use Version 1.2 of the “Transport Layer Security” (TLS) cryptographic protocol as a minimum standard for encryption. This is primarily important for HTTPS encryption of web traffic.
OpenSSL – a backward compabilities’ nightmare
HTTPS encryption in SUSE Linux Enterprise 11 SP2 and SP3 is based on the cryptographic libraries that are part of OpenSSL 0.9.8j.
Unfortunately, OpenSSL 0.9.8 doesn’t support either TLS 1.1 or 1.2, and this support cannot be added easily. Even worse, an update to a more recent OpenSSL version is not possible, as OpenSSL is notoriously incompatible with itself; in other words, an OpenSSL version upgrade would trigger a rebuild of a significant number of other packages in SUSE Linux Enterprise 11 — and subsequently would require a high number of updates to be installed on all our customers’ production systems. And a version upgrade would break (third party) applications. Not a solution, obviously.
An overview on the “notorious incompatibility” of OpenSSL is available via the ABI Tracker (OpenSSL), a service originally funded by Linux Foundation. The tool is available at Github.
Heading towards a solution … Mozilla’s NSS
Aware of this conflict, SUSE’s security team has for some time already been looking for an approach to provide TLS 1.2 with a minimum of annoyance for our customers.
Fortunately, there are other crypto libraries beyond OpenSSL, and amongst those, NSS is the best option. Here is why:
- The library is stable and proven to work, as it provides HTTPS support (including TLS) for the Firefox Web-Browser.
- An Apache module already exists, which is derived from mod_ssl and thus easy to use for administrators used to mod_ssl.
- The NSS library is already part of SUSE Linux Enterprise 11, and support for TLS 1.2 can be provided easily with full backward compatibility, see ABI Tracker (NSS).
The result
Last week, we shipped all necessary packages via the Maintenance Channels for SUSE Linux Enterprise 11 SP2 and SP3 to deliver:
- Mozilla NSS Update with support for TLS 1.2. Please update the packages: libfreebl3, libsoftokn3, mozilla-nspr, mozilla-nss.
- New package “apache2-mod_nss”.
Please don’t forget to read /usr/share/doc/packages/apache2-mod_nss/README-SUSE.txt for a smooth start with mod_nss. Enjoy!
Changelog
- 2014-01-23: Clarification, which impact a version update of OpenSSL would have on applications and production systems.
- 2017-06-03: Update links to ABI Tracker and add the Github link to the source code.
Related Articles
Jun 14th, 2024
Ensuring Continued Support for CentOS 7 Beyond End of Life
Jun 29th, 2023
Navigating Changes in the Open Source Landscape
Comments
Maybe SUSE should be mention in https://developer.mozilla.org/en-US/docs/Overview_of_NSS ; )
Good suggestion. Done. Thanks – MgE
Good article. A bit difficult to change from mod_ssl to mod_nss. Now how do we setup Perfect Forward Secrecy (PFS)?
To implement Perfect Forward Secrecy, you have to use “ephemeral keys”. For mod_nss these are provided by the ciphers with “ecdhe” (Elliptic Curve Diffie–Hellman Exchange) in their names.
Two options for cipher lists are provided in /etc/apache2/conf.d/mod_nss.conf, search for NSSCipherSuite. ecdhe ciphers may have a performance impact of up to 15%, thus they are not switched on by default, but we recommend to switch them on.
Hope this helps – MgE
in README-SUSE.txt, there is mention of mod_nss_migrate.pl, which uses certutil. now that doesn’t work because you need to add mozilla-nss-32bit.
now i was able to work thru this, but by you not mentioning it, it makes it feel like you didn’t know.
p
Thanks for the tips on PFS. It is working now.
I am accustomed to doing ‘service apache2 restart’ to bounce my web server. If I have set a password on the NSS DB then it needs that password to load the X.509 certificate. The old ssl mod would prompt for the ssl key pass phrase but mod_nss will not VISIBLY prompt for it although it is waiting for the pass phrase.
If I do enter the pass phase where it is expected it is also echoed to the tty.
I have expect scripts which depend on the prompt. The SLES11 NSS packages must perform as a “drop in replacement” for the ssl mod before I will deploy them in a commercial web server.
Not sure if the fix is in /etc/init.d/apache2 or the programs/modules it calls.
After I followed the steps, I am stuck with:
Invalid command ‘NSSHonorCipherOrder’, perhaps misspelled or defined by a module not included in the server configuration. Is that a standard issue or any config steps are missing ?