On Wed, Aug 06, 2008 at 10:20:46AM +0200, Paolo Abeni wrote:
> On Wed, 2008-08-06 at 09:44 +0200, Sake Blok wrote:
> > 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.
>
> I really would not to start a flame here, and I'm sorry if my pour
> English does not help.
I don't consider this a flame war, I think it's a healthy discussion :-)
I understand that you would like your code to be included. I just want
to make sure including this code does not change the nature of Wireshark.
My impression is that your code will change it's nature in a way that I
don't feel comfortable with.
> There are a couple of thinks that should be underlined: the patch does
> not use any private secret, but data publicly available and which use is
> well known to be strongly discouraged.
>
> I called the code itself a "brute force" since it try different keys,
> but strictly speaking it does not belong to such attack category, since
> it does not walk all the key space nor a large-enough subset of said
> space.
>
> It does not 'crack passwords'; instead it identify weak keys.
Well, if I have understood your code correctly, it *does* use the
identified weak key to decrypt the SSL traffic. When seen from the
viewpoint of the legal owner of the key, they never gave permission
to decrypt the traffic. This is different from the current
implementation of decryption, where the private data needs to
be provided by the legal owner.
This to me is a major difference in functionality. If Wireshark
just identifies the weak keys with a Expert Info Warning, then I'm
fine with it, because then it will help people to increase their
security awareness. I see no added value in decrypting traffic for
which the legal owner of the key did not give permission explicitly.
I hope you will understand this distinction. And the legal issues
it might cause...
In the end it's not my call to decide whether or not to include this
new functionality. I am at least curious how other (core) developers
stand on the issue...
May I have your votes please? ;-)
1) Don't include the code at all
2) Change the code to only identify the weak keys, but not use it
to decrypt the SSL traffic (would this also be CPU intensive?)
3) Add the code as is, including decryption of SSL traffic
In the end, I think its Geralds call to make a decission :-)
Cheers,
Sake
