Modernes SSL/TLS-Setup mit Apache: Difference between revisions
| Line 7: | Line 7: | ||
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). <br /> |
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). <br /> |
||
'''ECDH''' - Elliptic Curve Diffie–Hellman-Keyagreement<br /> |
'''ECDH''' - Elliptic Curve Diffie–Hellman-Keyagreement<br /> |
||
'''ECDSA''' – for digital signatures <br /> |
'''ECDSA''' – for digital signatures, so its possible to use ECC-Certificates (which are not yet available with ECC-singing). <br /> |
||
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: <br /> |
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: <br /> |
||
Revision as of 15:19, 27 September 2013
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%.
Key-Pinning
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 https://github.com/t2d/wasuptls
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:
SSLProtocol -ALL +SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
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
SSLHonorCipherOrder on
SSLCompression off
Header append Strict-Transport-Security "max-age=15768000 ; includeSubDomains"
Header always append X-Frame-Options "sameorigin"
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.
Benchmarks
to do
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)