Modernes SSL/TLS-Setup mit Apache

From SarWiki
Jump to: navigation, search

Apache2 TLS config with recent attacks in mind

Recent attacks on SSL/TLS

There where many attacks since 2011: BEAST, CRIME, TIME, BREACH, Lucky13 and last but not least RC4 Biases in TLS. Some of them are mitigated through workarounds in Browsers or Webserver-Software, some are mitigated with TLS1.2 and some, at least in case of BREACH and Lucky13, still threaten TLS/SSL. For details on the attacks and the mitigation read the SSL attack survey.

Conceptual improvements on SSL/TLS

Elliptic curve cryptography (ECC)

Use a 2048 or 4096 Bit RSA Key? It might be better to use ECC – the same strength with 224 Bits (and they might even be faster).
ECDH - Elliptic Curve Diffie–Hellman-Keyagreement
ECDSA – for digital signatures, so its possible to use ECC-Certificates (which are not yet available with ECC-singing).

In Apache its possible to use SSLCertificate's in parallel, so you can use a ECC-Certificate and in parallel have a fallback-certificate using RSA-signatures:
SSLCertificateFile "@rel_sysconfdir@/server.crt"
SSLCertificateFile "@rel_sysconfdir@/server-dsa.crt"
SSLCertificateFile "@rel_sysconfdir@/server-ecc.crt"

Forward Secrecy

Ensures that a session key deduced from a key will not be compromised if the private keys is compromised in the future. Uses (elliptic curve) Diffie–Hellman-Keyagreement. In theory, Transport Layer Security (TLS) can choose appropriate ciphers since SSLv3. OpenSSL supports perfect forward secrecy using elliptic curve Diffie–Hellman since version 1.0, with a computational overhead of approximately 15%.


Certificates are usually validated by checking the signature hierarchy. Key-Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known for a host, the certificate or public key is associated or 'pinned' to the host. There are two IETF-Drafts:

Both are not yet stable.

Project: wasupTLS

The goal is to provide an Apache2 configuration for websites with sensible data. It must work today and not exclude any users. Instead users with unsafe browsers should be warned. The project consists of three parts which should be used together:

  • Apache2 config file
  • Server-side script to export TLS information
  • Client-side script to warn users with unsafe browsers

Fork at

Our Decisions:

  • Based on stable software (Debian wheezy, OpenSSL 1.0.1e and Apache 2.4)
  • Export TLS information via SSI
  • BEAST is considered to be mitigated client-side, Priority is Forward Secrecy -> no RC4
  • Prefer ECDHE over DHE
  • HTTP Strict Transport Security
  • No Key-Pinning as it isn't stable at the moment.

The Apache Config: </br> SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 </br> SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS:!aNULL</br> SSLHonorCipherOrder on </br> SSLCompression off</br> Header append Strict-Transport-Security "max-age=15768000 ; includeSubDomains"</br> Header always append X-Frame-Options "sameorigin"</br>

The JavaScript tests if cipher suite is using Forward Secrecy, No SSLv3, No RC4, No 3DES. If not, we warn the user with a pop-up containing information about her_his vulnerability.


WasupTLS Bench Local1.png WasupTLS Bench Local2.png WasupTLS Bench packets.png WasupTLS Bench remote.png WasupTLS Bench remote keepalive.png

What needs to be done...?

  • Watch Key-Pinning
  • Push upgrade process to TLS1.2
  • Get rid of RC4
  • Tune sites for TLS
  • Watch SPDY/HTTP2 (Reduced amount of roundtrips)