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 _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org https://wireshark.org/mailman/listinfo/wireshark-dev
