Wireshark · Wireshark-dev: [Wireshark-dev] SSL attacks and performing cpu/time intensive computation in a protocol dissector

[Richard van der Hoff <richardv@xxxxxxxxxxxxx>]

I vote for:

> 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?)

I believe this is not CPU intensive.

I'm certainly against adding the brute-forcing functionality, for the 
reasons Andrew mentioned.


Luis EG Ontanon wrote:
> Insecurity people panic... security people take action...
>
> Security people that ban a program that finds/exploits a hole are not
> security people... security people makes sure a well known a very
> impacting vulnerabiliy is taken away.

What you say is true; however, it is sadly my experience that, 
particularly in large companies, (in)security people do exactly what 
Andrew suggested.

> I think that letting users to know that e.g. their Bank's website SSL
> key is broken is a good thing, they will avoid using and start
> complaining (As I did, now my bank uses a secure key, haven't I proven
> the key I might have been using for longer).

Would including brute-forcing code in wireshark help with this at all? 
As I understand it, vulnerable keys can be readily identified without 
trying to brute-force them. I think this was option 2) in Sake's email,

In any case, it's not at all clear to me that the people who need to be 
made aware of the problem are at all likely to be the people running 
wireshark - so your argument of bringing the message to the masses is moot.



Basically, I don't feel that brute-forcing functionality belongs in 
wireshark. (Once you have the key, you can then tell wireshark and it 
will decrypt the traffic. That *does* belong in wireshark.)

So to answer Paolo's original question:

> I would like to know if performing such CPU intensive computations in a
> dissector should be always avoided or, for some special situation like
> the said one, it can be accepted. 

I'm not sure it should *always* be avoided - however I don't think we 
have found a situation special enough to merit it.

> Moreover I would like to know if some kind of user interaction while
> performing the dissection, like said progress window, is acceptable, at
> least in very special situations.

If this ever was merited, then yes a progress window would be desirable.

Regards

Richard