LibreLAMP - A LAMP Stack for RHEL/CentOS 7

LibreLAMP is a collection of RPM Packages providing an alternate LAMP stack linked against LibreSSL, replacing the RHEL/CentOS 7 provided LAMP stack, which is linked against OpenSSL.

The intended audience is the security minded system administrator that understands the value of a TLS library that has a well-managed code-base with insecure protocols and ciphers removed, and without the un-necessary feature bloat that currently plagues the OpenSSL library.

LibreSSL was forked by the OpenBSD developers out of frustration over several issues with OpenSSL. LibreLAMP is the result of my frustration that it otherwise would likely take years for me to see the library make it into RHEL/CentOS, the server platform I am committed to.

Reactive security is patching exploits as they are found. Proactive security is removing potential exploitable code before the exploits are found. I prefer to be proactive, I did not want to wait for LibreSSL to come to me.

This page describes the software packages that are part of the LAMP stack itself.

For e-mail server software, see the Mail Software page.


List of Topics


LibreSSL Packaging Notes

[Puffy the LibreSSL Mascot]

No version of LibreSSL ships with RHEL/CentOS 7. The LibreSSL provided as part of LibreLAMP (Version 2.8.2) is a TLS library used as an alternative to OpenSSL.

LibreSSL is a fork of the OpenSSL project.

The purpose of a TLS library is to provide secure encrypted communication between two networked computers. Protocols and cipher suites that are weak or known to be insecure do not meet that purpose and have been removed. Features (such as heartbeat) that provide very little benefit but are potentially exploitable (such as the heartbleed vulnerability) have been removed. The remaining code has been reviewed with considerable cleanup. The result is a TLS implementation with a smaller code base that is fundamentally more secure than OpenSSL.

A goal of the LibreSSL project is produce a secure alternative to OpenSSL. I like that goal. However the purpose of LibreLAMP is not to replace OpenSSL, but rather, to provide a LAMP stack using LibreSSL installed in parallel with the distribution vendor provided OpenSSL.

I am personally very fond of RHEL/CentOS as a stable enterprise quality Linux distribution, but it will probably be years before LibreSSL becomes a part of that platform. I did not want to wait years for the security benefits that come from using LibreSSL as the TLS library for my public facing servers.

As such, my goal in packaging LibreSSL for RHEL/CentOS 7 is to package for parallel installation with the system OpenSSL rather than as a replacement for the system OpenSSL.

To achieve parallel installation, the /usr/bin/openssl binary that would normally be installed with LibreSSL has been renamed to /usr/bin/libressl.

Scripts and utilities that call /usr/bin/openssl will still be using the version provided by RHEL/CentOS 7. This is important, not every option supported by the vendor /usr/bin/openssl is supported by the LibreSSL fork (e.g. the -rand switch to genrsa). It is difficult to know what all these differences are because the RHEL/CentOS 7 provided man page for openssl(1) is extremely sparse and lacking in information about options to the command.

Configuration File Notes

I could have continued to use the RHEL/CentOS 7 provided /etc/pki/tls/openssl.cnf file as the configuration file for LibreSSL but I chose not to for several reasons:

  • Even though my goal is not to replace OpenSSL, I do not want to depend upon it either.
  • It is possible some of the configuration options are broken in LibreSSL.
  • I do not yet understand all of the implications of the configuration options in the RHEL/CentOS 7 provided configuration file. I did not want to package a binary that uses configuration options for which I am not familiar with the implications or the security of those implications.

What I did was patch LibreSSL to use /etc/pki/tls/libressl.cnf by default instead.

If you wish to change the behavior of LibreSSL, that is the file you need to customize.

Devel Package Notes

The libressl-devel package conflicts with the RHEL/CentOS 7 supplied openssl-devel package.

This is because LibreSSL is API compatible with OpenSSL 1.0.1, so many of the header files have the same file name and are installed in the same place so that software that wants to link against the library can find the header files.

There is really not a sane reason for trying to have both libressl-devel and openssl-devel installed at the same time.

LibreSSL and FIPS

LibreSSL does not support FIPS and I suspect it never will.

For all practical purposes, FIPS is worthless. Read more about LibreSSL and FIPS here: The future (or lack thereof) of LibreSSL’s FIPS Object Module.

Apache Packaging Notes

[Apache Feather Logo]
Apache Feather

RHEL/CentOS 7.5 ships with Apache 2.4.6. LibreLAMP ships Apache 2.4.35. Using a newer version of the Apache web server will prevent the LibreLAMP Apache packages from being replaced by an update to the Apache packaging in RHEL/CentOS 7.

Third party Apache modules built for the vendor provided Apache 2.4.6 web server should still work with LibreLAMP provided Apache 2.4.35.

The Apache build provided by LibreLAMP is based upon the RPM spec file used to build the vendor Apache 2.4.6. The layout is the same and RHEL/CentOS 7 specific patches that are not already merged into Apache 2.4.35 are applied.

Other than a few new Apache features that are available, using the Apache provided by LibreLAMP should be no different than using the Apache provided by RHEL/CentOS 7, with the noted exceptions listed in the sections below.

mod_ssl Patch

LibreLAMP has patched mod_ssl to reject the RC4 and the LOW quality ciphers. They simply should never be used in a secure connection.

When a cipher uses DH parameters and your Apache configuration does not point to custom DH parameters, 3072-bit are used by default instead of 2048-bit.

HTTP/2 ALPN

The Apache Server in LibreLAMP supports HTTP/2 ALPN out of the box. The core configuration file is located at /etc/httpd/conf.modules.d/00-http2.conf and by default contains the following:

LoadModule http2_module modules/mod_http2.so
ProtocolsHonorOrder On
Protocols h2 http/1.1

That configuration will provide HTTP/2 when TLS is being used and the client supports HTTP/2. Otherwise it will use HTTP/1.1. For more options with the Apache Protocols directive, please see the Apache Protocols Directive documentation.

You may also benefit from virtual host specific tweeks to HTTP/2. Several different directives are available, as described in the Apache mod_http2 Module Documentation.

OCSP Stapling

The directives needed to add OCSP Stapling to Apache have been added to the default /etc/httpd/conf.d/ssl.conf file.

This can cause error messages in the log file if your TLS certificates do not support OCSP validation. If this causes problems, please see the Apache documentation at https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html for solutions.

To disable it completely, you can edit the /etc/httpd/conf.d/ssl.conf file and comment out the following two lines:

SSLUseStapling On
SSLStaplingCache "shmcb:/run/httpd/ssl_stapling(65536)"

Brotli Compression Support

The Brotli compression module is built and enabled by default, but if you want brotli compression, you need to tell apache what to compress with it. Please note that in general, HTTP compression should only be used with static content for security reasons.

Below is an example of how to enable brotli compression with static WebVTT files:

AddType text/vtt .vtt
AddCharset UTF-8 .vtt
<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/vtt
  Header append Vary User-Agent env=!dont-vary
</IfModule>
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/vtt
  Header append Vary User-Agent env=!dont-vary
</IfModule>
      

Note that the brotli directive comes before the deflate directive. I recommend putting any HTTP compression related directives within a .htaccess file in the directory containing the static content just to make sure Apache does not apply it to dynamically generated content, where HTTP compression poses a security risk.

MariaDB Packaging Notes

[MariaDB Seal Logo]
MariaDB Seal

RHEL/CentOS 7.5 ships with MariaDB 5.5.56. LibreLAMP currently provides MariaDB 10.2.18. Please read the MariaDB specific page for notes about the MariaDB packaging for LibreLAMP.

These versions are not ABI compatible, software linked against the CentOS provided MariaDB libraries should be rebuilt against the newer MariaDB libraries if possible.

However a compatibility package is provided that should allow software linked against the former libraries to still function as intended.

I highly recommend you backup your database and stop the service before upgrading to the packages here. Usually the upgrade is smooth, but I know of one case where the database failed to start after the update and had to be restored from backup. I do not know what went wrong or why, just that the user was very glad they made a database backup.

PHP Packaging Notes

[PHP Elephant Logo]
Logo by Camilo Sanchez
CC by 3.0

RHEL/CentOS 7 ships with PHP 5.4.16 which is really old. The 5.4 branch of PHP is end of life and no longer even receives bug fixes from the PHP developers. Many modern web applications expect a newer version of PHP.

The PHP in LibreLAMP is 7.1.23. I probably will not package PHP 7.2.x but will keep packages 7.1.x releases until 7.3.x has been released and probably will wait a few update releases before packaging it.

Some of the PHP modules have dependencies on libraries that are part of the EPEL project. Installation of those PHP modules will require that you have the EPEL package repository enabled.

Pristine Source

RHEL/CentOS and Fedora remove some of the PHP source code in their source package. LibreSSL does not. I previously thought it was due to patent issues but I have been informed it has to do with the licensing of ext/json not actually being FLOSS.

The issue appears to be a clause in the license that says ‘The Software shall be used for Good, not Evil.’

Technically speaking FLOSS does not restrict the intended use of the software. So due to that clause, many distributions modify the PHP source to remove the ext/json code. Personally I find the clause in the license humorous. Am I evil?

PECL Extensions

The version of PHP provided by LibreLAMP is not ABI compatible with the version of PHP that ships with RHEL/CentOS 7. As such, PECL modules built against the version of PHP that ships with RHEL/CentOS 7 will not work with the PHP provided by LibreLAMP.

LibreLAMP provides packages that do work for some of the PECL module available in RHEL/CentOS 7 and in EPEL.

If you need a particular PECL extension not provided by LibreLamp, feel free to contact me and I will see what I can do.

PEAR Extensions

PHP PEAR Extensions are script libraries, they are not binary. It is my suggestion to just use the /usr/bin/pear utility to install and update any PEAR extensions that you might need. LibreLAMP will not package them.


Update Policy

Security issues and serious bugs in software packages distributed as part of LibreLAMP will be updated in a timely manner.

I do prefer to wait for a patch that is endorsed by the upstream project before applying a patch unless the particular bug involves a remote exploit vulnerability.

For LibreSSL itself, I do plan to keep up with upstream versioning. However I will not always release a new version of LibreSSL immediately. When shared library versions change, I prefer to wait until the next Apache or PHP update before pushing a new version of LibreSSL.

A shared library versioning change requires rebuilding all packages that link against LibreSSL. That is very time consuming on my end and results in pushing a lot of updated packages to the update server. As PHP tends to be updated about once a month anyway and is a fairly significant update itself, I prefer to wait until the next PHP update to push the changes.

When an update to LibreSSL does not version the shared library, then it is safe to push an update without needing to rebuild all the software that uses it, as that indicates the new version is ABI compatible with the previous version.

For the Apache web server, only updates from the 2.4.x branch will be made available. That is the branch that ships in RHEL/CentOS 7 and is also the most current stable branch available upstream. When a new branch is available upstream, updating to that branch will need a very compelling reason before I choose to do it.

With PHP I tend to update every other major release. For example, I skipped the PHP 7.0.x branch but I am packaging the PHP 7.1.x branch. I will likely skip PHP 7.2.x branch but will likely package the PHP 7.3.x branch.

Future Plans

The LAMP stack is pretty much covered. However there are other public facing servers that are commonly used that would benefit from linking against LibreSSL as opposed to OpenSSL. Once I am confident the LAMP stack is in fact performing to Enterprise standards, the following are my personal highest priority:

  • NSD (Authoritative DNS Nameserver)
  • Unbound (Recursive DNS Server)
  • Nginx (Popular web server)

NSD and Unbound are done, some documentation still needs to be created for them.

There are some servers that I do not wish to rebuild against LibreSSL:

  • OpenSSH (I would actually love to rebuild against LibreSSL but if I screw it up, I can not easily connect to my servers to revert. There is a second remote way in but it is a pain the ass to use)
  • BIND (I do not think it should be used, too many security issues too often)
  • Sendmail (I do not think it should be used, too many security issues too often)

Source

All software packages in LibreLAMP are Free Libre Open Source Software licensed under various FLOSS licenses.

The source code, including all patches, can be obtained in Source RPM packages located at http://awel.domblogger.net/7/libre/src/repoview/.

A git repository containing RPM spec files, patches, and some source files that are not upstream tarballs is located at https://git.domblogger.net/awel-libre.git/.

Sometimes the files there are newer than what is packaged. This is especially likely to be the case with PHP and MariaDB where I do not always push builds to the public due to both the size of the updates and risk involved with updating just for the sake of updating. I do try to keep the RPM spec files up to date with PHP and MariaDB but prefer not to push them unless there is a good reason to, or when updating LibreSSL requires a pushed update anyway.