ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Richard van der Hoff <richardv@xxxxxxxxxxxxx>
Date: Wed, 06 Aug 2008 22:04:54 +0100
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