Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "Security/Heartbleed" page has been changed by ChristopherSchultz: https://wiki.apache.org/tomcat/Security/Heartbleed Comment: Information on Heartbleed New page: This Wiki entry serves as a place for all relevant information regarding [[http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160|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 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. == How do I fix my servers? == This is an easy 2-step process: 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. 2. 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. == Is there anything else I need to do? == Yes: you need to change any password that ever traversed your HTTP server while vulnerable. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
