Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.229 as permitted sender)
Message-ID: <5347AD45.7070902@ice-sa.com>
Date: Fri, 11 Apr 2014 10:52:21 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Does heartbleeding bug impact on Tomcat 6.x, 7.x and 8.x
References: <4F5E23ACD197C243A9F932D07676BFF1D5DB44@XAMOT.glimmerglassnet.com>
 <53470DD1.8090505@touchtonecorp.com> <534716C1.60805@christopherschultz.net>
In-Reply-To: <534716C1.60805@christopherschultz.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org