Add sample of AprLifecycleListener log output (from Tomcat 8)
Mention how to update Tomcat Native.
|Deletions are marked like this.||Additions are marked like this.|
|Line 32:||Line 32:|
|1. Update OpenSSL to a version that includes the fix. The natural version number for this is 1.0.1g, though some package maintainers have chosen to back-port their fixes to versions with a lower patch-level. Among such maintainers are Debian and probably also Debian-based distributions such as Ubuntu. tcnative 1.1.30 and later include patched versions of OpenSSL.||1. Update OpenSSL to a version that includes the fix. The natural version number for this is 1.0.1g, though some package maintainers have chosen to back-port their fixes to versions with a lower patch-level. Among such maintainers are Debian and probably also Debian-based distributions such as Ubuntu.<<BR>><<BR>>Tomcat Native 1.1.30 and later include patched versions of OpenSSL.<<BR>><<BR>>To install updated Tomcat Native on Windows without updating Tomcat itself you have to [[http://tomcat.apache.org/download-native.cgi|download it]] and replace `tcnative-1.dll` in your installation with a new one.|
This Wiki entry serves as a place for all relevant information regarding CVE-2014-0160 (aka the “Heartbleed” OpenSSL bug). Rather than regurgitating this information repeatedly on mailing lists, etc., please make references to this page and refer people to it. With any luck, its usefulness will be short-lived.
I’ll go ahead and put the explanations last for convenience. If you’d like to read some of the justifications, you’ll find them at the end.
Is this a Tomcat problem?
No. This is a problem with a library that, under some configurations, causes your server to be vulnerable.
Am I Vulnerable?
If you are running any server that uses OpenSSL version 1.0.1 with any patch level before “g” you may be vulnerable. Unless you happened to install OpenSSL 1.0.1 for the *first* time after 2014-04-08 or so, you are almost certainly vulnerable. If you are running an ASF-provided tcnative binary version 1.1.24-1.1.29, then you are vulnerable, as tcnative ships with a statically-linked OpenSSL version which is vulnerable. If you are running OpenSSL 0.9.8 or 1.0.0, then you are not vulnerable to this particular vulnerability. If you are using Tomcat with any Java connector (BIO or NIO), then you are not vulnerable to this particular vulnerability.
You may also check if you are vulnerable using online tools:
What version of OpenSSL is Tomcat using?
This information is logged by AprLifecycleListener when Tomcat starts. For example,
10-Apr-2014 19:25:28.801 INFO [main] org.apache.catalina.core.AprLifecycleListener.init Loaded APR based Apache Tomcat Native library 1.1.30 using APR version 1.4.8. 10-Apr-2014 19:25:28.804 INFO [main] org.apache.catalina.core.AprLifecycleListener.init APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 10-Apr-2014 19:25:29.955 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized (OpenSSL 1.0.1g 7 Apr 2014)
How do I fix my servers?
This is an easy 3-step process:
Update OpenSSL to a version that includes the fix. The natural version number for this is 1.0.1g, though some package maintainers have chosen to back-port their fixes to versions with a lower patch-level. Among such maintainers are Debian and probably also Debian-based distributions such as Ubuntu.
Tomcat Native 1.1.30 and later include patched versions of OpenSSL.
To install updated Tomcat Native on Windows without updating Tomcat itself you have to download it and replace tcnative-1.dll in your installation with a new one.
- Re-key your server. This means creating a new RSA or DSA server key, creating a new CSR for your Certificate Authority, and applying for a replacement certificate. All CAs allow for the revocation of a server certificate due to “key compromise” which is exactly the reason for the re-keying of your server. You should be able to obtain a replacement certificate at no charge, though free-certificate providers may charge a fee for revocation/replacement.
- Revoke any certificates that might have been compromised. This does not guarantee that the old certificate cannot still be used in MITM attacks, as most browsers don't check revocations in a timely fashion (if at all). However it should help to catch some attacks.
Is there anything else I need to do?
Yes: you need to change any password that ever traversed any HTTP server that was using the potentially compromised certificate. If the certificate was a wildcard certificate, then a single vulnerable server would be sufficient to compromise the certificate and thus the traffic on all other servers using the same certificate.
That pretty much means you have to change all passwords, and notify your users that they should change all their passwords as well. Unfortunately, any other sensitive information that traversed your server should be consider compromised. In many cases, there is nothing to be done unless that information can be changed (credit card numbers, account numbers, passwords etc.).
What about servers for services that I use personally?
You should wait until your bank, email provider, online store, etc. patches and re-keys their servers and then change your password(s) as soon as possible.
Why should I do any of this?
You need to patch your servers if you are vulnerable. That part should be obvious. You need to re-key your servers because, during the period when your servers were vulnerable, it is possible (though improbable) that your server’s key was read remotely due to this bug. If an attacker has your key, they can decrypt any past or future communication if they can observe the encrypted traffic.