Wireshark-dev: Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol diss
On Wed, Aug 06, 2008 at 09:12:14AM +0200, Paolo Abeni wrote:
> On Tue, 2008-08-05 at 20:28 +0200, Sake Blok wrote:
> > Wireshark has a good
> > reputation as a network analysis tool. Which of course means it can be
> > used for less honest purposes as well, but putting code in to deliberately
> > break security based on a weakness in the protocol crosses the line
> > for me.
>
> I would add just a little detail: the issue exploited in the CVE 2008
> 0166 attack is not related to the SSL protocol, but to some specific
> (broken) implementations.
>
> Moreover the decryption of encrypted sessions is a feature that
> wireshark supports since a few time for SSL, IPsec, ecc. and at least
> for SSL sessions it works in a very similar fashion to the CVE attack
> (in both situations you have to provide wireshark with some additional
> knowledge).
I don't agree with you here. For the current decrypt functions of
Wireshark, the user add specific additional knowledge for *their*
setup. The information needed is private and only available to
legitimate administrators of the systems involved.
In the case of this CVE, there is no administrator giving access to
the private information.
Wireshark is a tool designed to help people troubleshoot *their*
networking issues. In which case it is very helpful that one can
provide private information so that more details can become visible.
It is not a tool designed to be able to decrypt as much as possible
with whatever means available. That would mean more brute force-attacks
would be included in the future.
As pointed out by Ulf, there are legal issues involved as well and
noone would want to have Wireshark banned from corporate networks
just because it has crossed the narrow line of being a security
tool or being a cracking tool.
That said, I do agree it could be nice to detect the weak keys and
provide the user with an expert info item telling them that the key
that is used is weak, without actually decrypting the data. If they
want to decrypt the session for troubleshooting, they should have
access to the keys anyways.
> Anyway I would be very interested in some feedback on the initial
> questions (long computation and/or user interaction in dissector
> code)...
Well, IMHO brute forcing should never be needed for dissection. So
I think it should never be necessary to have these long computations.
But of course, that's MHO :D
Cheers,
Sake
