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.
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:
Simple Heartbleed explanation in comic form, showing how arbitrary information can be retrieved.
APRIL's point of view, more generally on free vs proprietary software concerning security flaws.
The commit that introduced the bug in OpenSSL on 2012-01-01 (implementation of the heartbeat protocol).
Some technical details about the flaw and its exploitation, on the CloudFlare blog.
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.
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:
The case of Google Chrome / Chromium, which uses a different method, which almost does not work at all in practice. I also noticed that it did not work at all on my machines, with my own use of Chromium, and after many tests, I realized that I first needed to run Chromium for 21 minutes to start having very partial security automatically.
General articles on the subject: Certificate revocation: Why browsers remain affected by Heartbleed (Netcraft, 2014-04-24) and Certificate revocation controversy heats up (ZDNet, 2014-04-30).
The first discussion on the check of the revocation following the announcement of the Heartbleed flaw.
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).
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):
www.vinc17.net:4434 (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.
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
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.SSLStaplingReturnResponderErrors off
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.
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 127.0.0.1 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:
Install the redis package (a database used by ocsp_proxy) and other packages that provide the needed Perl modules.
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.
Restart the redis server with service redis restart
.
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.
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.
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:
Perfect Forward Secrecy support with Apache. I used this article to (re)configure my web server.
My web server supports secure connections via www.vinc17.net or simply vinc17.net. However, I did not take a certificate for my domain vinc17.org, 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.
Page generated from file security.en.xml on 2024-03-17 by xsltproc (using libxml 20914, libxslt 10135 and libexslt 820).
Note: this DocBook conversion is still experimental; please report any problem.