Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Andre, On 12.4.2014 0:51, André Warnier wrote: Ognjen Blagojevic wrote: On 11.4.2014 10:52, André Warnier wrote: 3) if he has recorded past encrypted traffic to/from your server, and saved this recording, then he can at any time go back and decrypt this past traffic, and pick up anything interesting from there, even without having the new keys. Such a recording could contain, for example, any number of submits from HTML login pages, which were theoretically protected by being made on an encrypted channel. That could probably also contain any communications which your server did with other servers over encrypted channels. ... unless Forward secrecy was utilized, which is pretty much invented to defeat future decryption of recorded traffic. Forward secrecy was easy to set up on Linux with APR. All agreed. But I was talking about existing recordings of past communications. Whatever is done from now on, would not help in that respect, would it ? I was also talking about past recordings. For example, let's say that you had a new server set up in e.g. the beginning of 2013, and you configured HTTPS (TLS) to support Forward Secrecy from start. And let's say, that some agency immediately started recording all your encrypted traffic, with the idea that if will be able to decrypt it in the future. And let's assume that the same agency found out about Heartbleed bug at the beginning of 2014, before general public. So they obtained immediately your private key. You find out about the same bug in 7.4.2014, and you replace your private key at the same day. Now, it is clear that the agency was able to decrypt traffic from the beggining of 2014 (using MITM attack), but it should also be clear that although they have private key of your server, and they have recorded all your conversations ever, they will not be able to decrypt conversations from 2013. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Just for the sake of clarity, I will redundantly highlight some parts of Christopher's recent message : Christopher Schultz wrote: ... * If you are on 1.1.24-1.1.29, then you have been vulnerable. * ... I can't stress enough that once you update to a fixed version, *you must re-key your server* and obtain a replacement certificate from your CA. You must also consider any communication that traversed your system while vulnerable to be compromised. That means that every password that went through your system during the period of vulnerability ought to be changed. As I understand it, the real bitch about this bug, is that *during the whole period in which your server was vulnerable* , a knowledgeable attacker would have been able to connect to your server and grab the contents of arbitrary 64 K chunks of memory. This could have contained *anything*, including SSL keys, certificates, decrypted passwords, user-id's, whatever was in such a 64K chunk at that time. And he could do that as often as he wanted, without ever being detected or leaving any trace to allow an analysis later. And he could record this information, for leasurely inspection and analysis at any later time. There are at least 3 consequences : 1) if you do not change your keys and/or passwords now, then in the future that attacker (and whoever he gives or sells the information to) will be able to access your server with the stolen credentials, and do whatever these credentials allow him to do. 2) if these stolen credentials apply to other systems too, even ones that are not vulnerable and have never been, he can use them there too. (people use the same keys and passwords for multiple services, that's just a fact of life) 3) if he has recorded past encrypted traffic to/from your server, and saved this recording, then he can at any time go back and decrypt this past traffic, and pick up anything interesting from there, even without having the new keys. Such a recording could contain, for example, any number of submits from HTML login pages, which were theoretically protected by being made on an encrypted channel. That could probably also contain any communications which your server did with other servers over encrypted channels. This is all fairly complex, and would require a knowledgeable attacker, one that knew about this bug before the good guys, one who had the technical means to do this kind of thing, and some serious dedication and planning on top. That would not be your everyday script-kiddie. But there are people like that out there, and it may explain a-posteriori a number of high-profile data theft incidents that happened over the last 2 years, and any number of low-profile ones that you never heard about. The point is, nobody knows really. So I guess that the amount of damage that this can cause is very much dependent on what you have been running on your server, and for whom, and how attractive your site may have been for such a would-be serious attacker. I would definitely not like to be in the position of having run a HTTPS-based electronic-payment system over the last 2 years. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 4/11/14, 2:52 AM, André Warnier wrote: As I understand it, the real bitch about this bug, is that *during the whole period in which your server was vulnerable* , a knowledgeable attacker would have been able to connect to your server and grab the contents of arbitrary 64 K chunks of memory. Correct. It's ... kind of bad. There are at least 3 consequences : 1) if you do not change your keys and/or passwords now, then in the future that attacker (and whoever he gives or sells the information to) will be able to access your server with the stolen credentials, and do whatever these credentials allow him to do. Correct: if your server keys have been stolen, then even after you patch your server the damage has been done -- an attacker can decrypt any traffic they capture in the future. That's why you must re-key. Remember to patch first, then re-key ;) 2) if these stolen credentials apply to other systems too, even ones that are not vulnerable and have never been, he can use them there too. (people use the same keys and passwords for multiple services, that's just a fact of life) +1 If you re-use the key+cert on other servers, then their traffic can be decrypted as well if your key has been stolen. 3) if he has recorded past encrypted traffic to/from your server, and saved this recording, then he can at any time go back and decrypt this past traffic, and pick up anything interesting from there, even without having the new keys. Well, the new keys are irrelevant for old traffic. Such a recording could contain, for example, any number of submits from HTML login pages, which were theoretically protected by being made on an encrypted channel. That could probably also contain any communications which your server did with other servers over encrypted channels. Correct: you have to assume that basically your traffic has been essentially unencrypted during the period of vulnerability. That's why everyone has to change all their passwords. For everything. Everywhere. Have fun! - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTSBRMAAoJEBzwKT+lPKRYCacP/2B9d5ooilyV3KxY2K1hXw1n ijesdzbV7xWdgFOVLqvS1OLGbFRFzUhJeu30zhX/aw3gVzUnVrmEHLZqaU5nZXrD gfHEO7FkEazuKrwiZ6Y382t0542Gb735piTM6q49aUs51mIRKzwQgPyGAUD2L+wY 4/djZ2rUPWAp3N/qKrCgSqVFAU03gLU6rhRuyPdOUj4GWRBEFCKPyxrIAfz7xU0/ w3sv9VXobLcAMVTFJvn/7D3H7iA0BjRfYZeo613miCfsGO1d6Y5b3R2z6kBJ5R0A iIVJDaA7O8DFwt5nFwYAm1x9VvoxGBY6+UXEZkaYPisQhVJh5/aKlYIN+AObIRKX RcmoLPxCiz/ANoq8YPovtCumrrqqwNdfceMzP5JyAk6p4pS4OlVrxWST7N4q9fkJ /ZnwGanb3WTU4iFuCf4TijzF0QvwS9rmtZuQLYzG2qSgjOF6O2mBWeSnHQ9bA5RZ gpD/NEOlgYXpVlH0VfFNVQOW8ymWEBdO3Mxq/RoCumWh8yRMLRyodEI7QqUXqCb6 I8fA08xwsjKHNgGxNaJmvf3q6xExhfhASauwNBwTWpO9vtKYBvE3jlgbqR/qcqMT egiqIPGWLK3A14G9YzqOpFljBUxzh9tcNrauFCOZ3Qh5EaffvM6hubBL+MyxsDhR 329oLojNhu47UxqzpgwX =GPt2 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
On 11.4.2014 10:52, André Warnier wrote: 3) if he has recorded past encrypted traffic to/from your server, and saved this recording, then he can at any time go back and decrypt this past traffic, and pick up anything interesting from there, even without having the new keys. Such a recording could contain, for example, any number of submits from HTML login pages, which were theoretically protected by being made on an encrypted channel. That could probably also contain any communications which your server did with other servers over encrypted channels. ... unless Forward secrecy was utilized, which is pretty much invented to defeat future decryption of recorded traffic. Forward secrecy was easy to set up on Linux with APR. When tcnative 1.1.30 is released, it will be easy to set up on Windows with APR. If issue 55988 [1] is resolved, it would be also possible to set it up on JSSE connectors with Java 8. -Ognjen [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55988 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Ognjen Blagojevic wrote: On 11.4.2014 10:52, André Warnier wrote: 3) if he has recorded past encrypted traffic to/from your server, and saved this recording, then he can at any time go back and decrypt this past traffic, and pick up anything interesting from there, even without having the new keys. Such a recording could contain, for example, any number of submits from HTML login pages, which were theoretically protected by being made on an encrypted channel. That could probably also contain any communications which your server did with other servers over encrypted channels. ... unless Forward secrecy was utilized, which is pretty much invented to defeat future decryption of recorded traffic. Forward secrecy was easy to set up on Linux with APR. All agreed. But I was talking about existing recordings of past communications. Whatever is done from now on, would not help in that respect, would it ? When tcnative 1.1.30 is released, it will be easy to set up on Windows with APR. If issue 55988 [1] is resolved, it would be also possible to set it up on JSSE connectors with Java 8. -Ognjen [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=55988 Famous last words.. - I don't think this feature justifies a big blob of ugly code, so this should wait for Java 8. I gather that this was written before HeartBleed became public knowledge. ;-) I believe that in the end, it has to be hoped that the bad guys are no better than the good guys, and that they did not spot this any earlier than the good guys. http://www.theregister.co.uk/2014/04/01/nsa_plans_range_of_free_cloud_services_data_analytics/ They must be very pleased. Now that they have the keys also, they can go back and decode all that stuff, and then they they can zip it properly and reclaim a lot of disk space. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Hi, Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. How can I find which version of Tomcat uses which version of Tomcat native connector ? For example, how can I figure out which version of Tomcat native connector is used by Tomcat 7.0 build 47. Thanks, Ji CONFIDENTIALITY NOTE: The information contained herein this email is intended for the exclusive use of the original recipient. The information in this email and any attachments is granted for the sole use of the intended recipient and may be distributed within the recipient's organization only with the permission of the sender. Any further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. If you are not the intended recipient, please contact the sender immediately and permanently delete the original email together with any copies thereof, including any attachments. Thank you for your cooperation.
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
On Thu, Apr 10, 2014 at 2:10 PM, Ji Song s...@glimmerglass.com wrote: Hi, Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. How can I find which version of Tomcat uses which version of Tomcat native connector ? For example, how can I figure out which version of Tomcat native connector is used by Tomcat 7.0 build 47. Look here: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_47/build.properties.default Scroll to the # - Tomcat native library - section
RE: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
Hi I think it is tcnative.dll. You should find the tar.gz file attached with the source, which says you the version. Best Regards, Sasi Eswaravaka -Original Message- From: Ji Song [mailto:s...@glimmerglass.com] Sent: Thursday, April 10, 2014 4:11 PM To: 'users@tomcat.apache.org' Subject: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x Hi, Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. How can I find which version of Tomcat uses which version of Tomcat native connector ? For example, how can I figure out which version of Tomcat native connector is used by Tomcat 7.0 build 47. Thanks, Ji CONFIDENTIALITY NOTE: The information contained herein this email is intended for the exclusive use of the original recipient. The information in this email and any attachments is granted for the sole use of the intended recipient and may be distributed within the recipient's organization only with the permission of the sender. Any further dissemination, whether private or public, is prohibited and may be covered under a non-disclosure agreement. If you are not the intended recipient, please contact the sender immediately and permanently delete the original email together with any copies thereof, including any attachments. Thank you for your cooperation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
On 4/10/14 2:10 PM, Ji Song wrote: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. If you use JSSE for your SSL support, then you're not affected, no matter what version of OpenSSL your Tomcat uses. Kind of makes all that futzing around with Keytool (because JSSE is apparently the only SSL option for Tomcat on an IBM Midrange box) all worth it. ;-) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 4/10/14, 3:32 PM, James H. H. Lampert wrote: On 4/10/14 2:10 PM, Ji Song wrote: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x ? I noticed that Tomcat native connector version 1.1.22 uses : OpenSSL 0.9.8 which doesn't have the heartbleeding bug, but 1.1.24 and 1.1.29 also include the buggy openssl. If you use JSSE for your SSL support, then you're not affected, no matter what version of OpenSSL your Tomcat uses. +1 Conversely, the version of Tomcat is not relevant, here: it's only the version of tcnative you are using. If you have 1.1.23 or earlier, then you are safe from this particular vulnerability (but there may be other issues with older versions). If you are on 1.1.24-1.1.29, then you have been vulnerable. tcnative can be used with any version of Tomcat, though certain versions of Tomcat have minimum requirements for the tcnative version. I can't stress enough that once you update to a fixed version, *you must re-key your server* and obtain a replacement certificate from your CA. You must also consider any communication that traversed your system while vulnerable to be compromised. That means that every password that went through your system during the period of vulnerability ought to be changed. Kind of makes all that futzing around with Keytool (because JSSE is apparently the only SSL option for Tomcat on an IBM Midrange box) all worth it. ;-) Erm, maybe not. ;) You can actually use pkcs12 and avoid using keytool altogether. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRxbBAAoJEBzwKT+lPKRYnH4QAJwy4GbC4hLHIXZ3nn+slf9G 3NWGlpLo9Ua6ft4SvEiVxfWJ6hqShlWm6XcLwVjfG9TdAjL5NgXkQL5fXS/eWHTM 0HgMJnkkc6xPn/BgPpno9CcOcboBdH0wT+eazhuurKF7qdpancaujKbA2tf+gA59 929DbZTJLBSvYpY7eevdiIiFCzKrgUkpKUIOhj3QY8GsT2sfiMeSuY3R2X9CoSNa Jt8Zdew2eSsOTWURgeOFRfobKHDc2dIC9Z2/O0lUac16W8+IaM7rjzuXEGaZGUb2 6v0+CuMeGcoHpUg7h7P2xD1CgqR3U1MfSD8IEhW2axi3h9Z4DpsjZG8CTbgV2EDX zaZnv9cZld03j8efCkviYDM6LI4PY3H3/+gzIHvjzVdqLXACIyivYsEfLNw7/b7v 3TVB57dmB8At87WgH/15EHoJRPg75TtFC41YQLMXF/GrTE/GSrYnjjqLCVh+Yf+B nl/yVbGgDh+BLXlcVw9qMc7WCTkYLIi5ga3doh+i+fOYOQ/sLF+NWpTF1I2Nj7bR ilVS4nSAFPhrl/jbZxN7ojCyuo30/p0pDRKktZk/wGVj5Jgn9QSirEEjbLT1O9Au reEmnc25okkviPNFdHmxuDaSJIfLdCrXXGxpt6qWQ9Mcan/3X7boo8GAFZTLvsEM FAva6x+0v5/Gw/2Xc/88 =w2/Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
