Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] performing cpu/time intensive computation in a protocol diss

From: "Luis EG Ontanon" <luis@xxxxxxxxxxx>
Date: Thu, 7 Aug 2008 15:57:46 +0200
My vote goes for 2) :

Wireshark is a troubleshooting tool and a vulnerable key can be source
of trouble. It would be plainly wrong not to notify of a potential
source of trouble if we can.

I wonder whether we actually need to decrypt? I think we just need to
build a hash of broken keypairs indexed by PubKeys and check the
PubKey during the setup exchange, if the key is one of the well-known
64k we just mark it.

It would be also interesting to check for CA certs whose PrivKey is
one of the well known 64k. Is that feasable?

\Lego

On Thu, Aug 7, 2008 at 1:30 PM, Sake Blok <sake@xxxxxxxxxx> wrote:
> On Thu, Aug 07, 2008 at 09:59:41AM +0100, Richard van der Hoff wrote:
>> Paolo Abeni wrote:
>> >> 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?)
>> >
>> > Yes. It will take near exactly the same amount of time and computation
>> > since, in current code, the larger amount of time is spent looping on
>> > candidate weak keys.
>>
>> Right. I'd been labouring under the misunderstanding that you could
>> identify whether a key was weak without having to brute force it. Having
>> looked at Paolo's patch a bit more, I now see that isn't true.
>
> Same here...
>
>
>> This certainly shouldn't be enabled by default - I don't want my
>> wireshark to spend ages attempting to brute-force keys every time I
>> happen to pick up a bit of SSL traffic.
>
> As Wireshark is a "Network Protocol Analyzer" and not a "Vulnerability
> Scanning Tool", I would prefer not to waste cycles on identifying
> weak ciphers either...
>
>
>> You could leave the code in there, and have an 'identify weak keys' menu
>> option.
>>
>> But at present I'm changing my vote to 1) Don't include the code at all.
>
> All considering, I vote for 1) as well.
>
> Cheers,
>    Sake
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> https://wireshark.org/mailman/listinfo/wireshark-dev
>



-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan