Version française

Security (Internet, Software, etc.)

This page contains miscellaneous information about security concerning Internet, software, etc., mainly links to interesting documents. It should initially have been just about the Heartbleed security bug and its consequences (generalities and the particular case of my server), but this page may evolve.

The Heartbleed Security Bug

In a few words, Heartbleed was a security bug in the OpenSSL library. It may be seen as the worst flaw ever found, because many servers were affected, highly private data (such as passwords and secret keys) could leak from them, and this bug left no trace.

Main information:

Note: Much attention has been paid to servers, but users should be aware that clients may also be vulnerable. For instance, if a web browser based on a vulnerable OpenSSL library connects to a malicious web server, arbitrary data from the browser's memory could be retrieved by the server. However, while the most common web servers use the OpenSSL library (at least Apache and Nginx under GNU/Linux), this tends not to be the case for the web browsers; for instance, both Firefox and Chromium use NSS [Wikipedia] and not OpenSSL.

Revocation of the Certificates

A consequence of the Heartbleed security flaw for the owners of affected servers is that the secret key of the certificate used for the server identification in secure connections (HTTPS) could have been divulged. As the bug does not leave any trace, in the best case, one does not know. Thus in doubt, the certificate must be revoked.

Note: the above paragraph mentions Heartbleed, but this section is more general, since the secret key could have been divulged for another reason. However, most of the revocations were made following the announcement of the vulnerability.

For the end user, it just suffices that the revocation of the certificates be checked in a reliable way at the beginning of any secure connection. Otherwise, under some conditions and in the event that the secret key has leaked, a malicious web site can impersonate the real site and retrieve data such as the username (login) and password of the user of the site!

There are various ways to check the revocation of a certificate, but in practice, many clients (web browsers…) checks nothing, or very little! The fact that everything has been fixed on the server does not have any influence; it is a vulnerability of web browsers (and other clients). Some links on this issue:

For Firefox, the configuration for a proper check can be chosen via the user interface. With the version I have: in Advanced → Certificates → Validation, both options need to be enabled (the option When an OCSP server connection fails, treat the certificate as invalid is disabled by default, and this is the problem since in case of man-in-the-middle attack, the attacker will make the connection to the OCSP server fail, so that the revocation status cannot be checked). Alternatively, the configuration can be changed via about:config, where security.OCSP.enabled must be set to 1 (this is the default) and security.OCSP.require must be set to true (this is not the default).

Testing Whether the Revocation of Certificates is Checked by Your Web Browser

A few links to test whether the revocation of certain certificates is checked by your web browser (the results depend on both the web site and the web browser):


  • (note: this test is obsolete because the revoked certificate has expired on 2015-12-12, so that this is no longer a test on the revocation).

Test done on 2014-05-27 with up-to-date browsers: on these 3 sites, Firefox properly detects that the certificate has been revoked, but Chromium detects that only for the first site. Other clients, like the Lynx web browser or the GNU Wget utility, do not check anything.

Test done on 2015-05-03 under Debian/unstable: Lynx and GNU Wget now both report the revocation status since they now both use GnuTLS 3, where this check is done. But this gives a false sense of security because no errors are reported in case of lack of OCSP response, which will typically happen with a cybercriminal server. I detected that with a test server openssl s_server using a revoked certificate.

Note that these tests are not sufficient to know the behavior of your browser in case of real attack, such as man-in-the-middle attack. For instance, with such tests, the security.OCSP.require Firefox option will have no influence, while this option is crucial in case of real attack.

OCSP Stapling

One of the best ways to check whether a certificate has been revoked is OCSP stapling, with a fallback to conventional OCSP (necessary in case of attack). But this method must be enabled on the web server. For Apache, the administrator can follow these instructions from 2013, in particular:

  • In the main SSL configuration file (e.g. /etc/apache2/mods-available/ssl.conf):

    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    SSLStaplingCache shmcb:/var/run/ocsp(128000)

    [Update 2020-03] The SSLStaplingReturnResponderErrors off directive is not explained and is surprising. I suppose that this is a workaround to a bug in Apache, which could otherwise return a fake error (see next section). Thus, rather than getting a fake error that would prevent the document from being loaded, it is better to behave as if OCSP stapling were not used.

  • In each virtual host (e.g. some file under the /etc/apache2/sites-available directory), or the main configuration if no virtual hosts are used: a SSLCACertificateFile directive. For instance:

    SSLCACertificateFile /etc/ssl/certs/ca.pem

OCSP stapling also needs to be supported by the web browser. But according to the OCSP stapling Wikipedia article, only Microsoft Internet Explorer and Firefox 26+ support it (2014-05).

[Update 2015-11-15] See also The case for OCSP Must-Staple on GRC. This is implemented in Firefox 45: see Mozilla bug 901698, resolved on 2015-11-14.

Apache OCSP-Stapling Bug [2020-03]

Currently (at least up to version 2.4.41), if Apache cannot connect to the OCSP server, it propagates the error to the client (e.g. a web browser), even if the latest OCSP reply is still valid. This defeats one of the purposes of OCSP stapling, which should make temporary failures invisible. Here are various bug reports on this problem:

  • Apache bug 57121: ocsp stapling should not pass temporary server outages to clients

  • Apache bug 60182: SSLStaplingFakeTryLater Deviates From Documented Behavior of Only Being Effective When SSLStaplingReturnResponderErrors is On

  • Debian bug 933129: apache2: OCSP stapling poorly handled, yielding trylater errors in the client (which I've reported)

This is all the more annoying as failures appeared on my web server more and more frequently. A comment in Apache bug 57121 eventually mentioned a workaround: the use of a simple OCSP proxy, ocsp_proxy.

So I started to try that. Unfortunately there were some issues with my Debian 10 machine:

  • I reported the following bug: fail to start the systemd service due to the "test" utility being only in /usr/bin, which was quickly fixed after a short discussion.

  • There was some administration work to do, summarized below. This was not difficult, but as this was not documented, I was wondering why this did not work in the first place.

  • With the provided documentation (and other documents found on the net), Apache could not connect to the proxy. After some testing and debugging, I found out that Apache was trying to connect with IPv4 (due to the use of the address in its configuration) while the proxy was listening on an IPv6 socket (due to the use of localhost in its configuration and the fact that IPv6 is preferred by default). After changing the Apache configuration, everything worked well. So I did a pull request (also containing a previous change), which was quickly merged (documentation fix for the Apache configuration).

Summary of things I had to do in order to use ocsp_proxy:

  1. Install the redis package (a database used by ocsp_proxy) and other packages that provide the needed Perl modules.

  2. As this can be seen in systemd/ocsp_proxy.service from the ocsp_proxy source, ocsp_proxy connects to redis on a Unix socket. However, redis does not create a socket in its default configuration. This needs to be changed by adding the following two lines to the configuration file /etc/redis/redis.conf:

    unixsocket /run/redis/redis.sock
    unixsocketperm 770

    The filename matches the one from systemd/ocsp_proxy.service.

  3. Restart the redis server with service redis restart.

  4. Download ocsp_proxy (e.g. by cloning the git repository) if not done already, and run the following commands as root. The third one needs to be run from the ocsp_proxy source tree.

    # adduser --system --group --home /var/lib/ocspproxy --no-create-home ocspproxy
    # adduser ocspproxy redis
    # make install SYSTEMD_DIR=/etc/systemd/system
    # systemctl enable ocsp_proxy.service --now

    The first command creates a user and a group ocspproxy as required by systemd/ocsp_proxy.service, and the second one adds this user to the redis group so that ocsp_proxy can connect to the socket. Since this is not a Debian package, the installation of the service file needs to be done under /etc/systemd/system; hence the SYSTEMD_DIR=/etc/systemd/system argument in the third command.

  5. As now correctly documented in ocsp_proxy, reconfigure Apache to use the proxy by adding the following line to the Apache SSL configuration file, typically /etc/apache2/mods-available/ssl.conf:

    SSLOCSPProxyURL http://localhost:8888/

    Then restart Apache.

Perfect Forward Secrecy

Another important notion concerning the secure communications with servers is Perfect Forward Secrecy. If it is not used and some key is compromised (as this could happen due to the Heartbleed bug), then past encrypted communications (including those dating before this bug was introduced) could be revealed.

Links about Perfect Forward Secrecy:

My Web Server (

My web server supports secure connections via or simply However, I did not take a certificate for my domain, since this is not free and this would be redundant with my other domain name.

I had reconfigured my server on 2013-11-12 to support Perfect Forward Secrecy and tested it with Chromium, but for some unknown reason, this was no longer working several weeks/months later (I don't know when exactly). I changed the configuration again on 2014-03-31, and retested it with Chromium and Qualys SSL Server Test, where my server got an A overall rating.

The Heartbleed bug was fixed on my server on 2014-04-08 at 07:51 UTC (a few hours after the announce of the flaw) via the usual security updates, and the certificate was regenerated in the evening, as advised by Gandi (with Gandi, certificate regeneration is free).

My server has also supported OCSP stapling since 2014-05-04.