On Thu, Aug 07, 2008 at 03:57:46PM +0200, Luis EG Ontanon wrote:
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
On Tue, Sep 30, 2008 at 10:43:22AM +0200, Sake Blok wrote:
OK, it's been a while, but no decission has been made for enhancing
Wireshark with Weak-Key detection and decryption.
Is this something we can all (oh well, most of us) agree on?
I vote for #2.
If so, I think the option of using
Use the best of both worlds?
Don't include the code in Wireshark.
Wireshark is the reliable protocol analyser, which still can be used on
corporate
networks.
Avoid discussions whether or not Wireshark has become a hacking tool.
ODOH
There will be circumstances in which you want to / need to
hello,
On Wed, 2008-08-06 at 11:17 +0200, Sake Blok wrote:
Well, if I have understood your code correctly,
Just to leave praise (or blame :-), for those who really deserve it,
this is not entirely my code, since others have contributed to the patch
(as bugzilla entry reports): Luciano Bello
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
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
On Thu, Aug 07, 2008 at 01:30:25PM +0200, Sake Blok wrote:
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.
I still strongly prefer 2)
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
hello,
On Tue, 2008-08-05 at 20:28 +0200, Sake Blok wrote:
Wireshark has a good
reputation as a network analysis tool. Which of course means it can be
used for less honest purposes as well, but putting code in to deliberately
break security based on a weakness in the protocol crosses the line
On Wed, Aug 06, 2008 at 09:12:14AM +0200, Paolo Abeni wrote:
On Tue, 2008-08-05 at 20:28 +0200, Sake Blok wrote:
Wireshark has a good
reputation as a network analysis tool. Which of course means it can be
used for less honest purposes as well, but putting code in to deliberately
break
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
Sake Blok wrote:
May I have your votes please? ;-)
1) Don't include the code at all
There are enough weak key identifiers out there without burdening
Wireshark with a CPU intensive test for a one off problem. The next time
someone finds a weakness it is bound to be a different problem
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.
I think that letting users to know that e.g. their Bank's
FYI, I've read Richard's reply.
Luis EG Ontanon wrote:
Insecurity people panic... security people take action...
Possibly a poor choice of words. You can't have dealt with the way a
large organisation reacts to stress. Panic preceeds action because panic
is easy and action is not. The ones who
hello,
In a pending patch for the SSL dissector:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2725
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2029
it's implemented the attack to CVE 2008 0166. This is basically a brute
force against a relative small set of candidate private
On Tue, Aug 05, 2008 at 02:22:58PM +0200, Paolo Abeni wrote:
hello,
In a pending patch for the SSL dissector:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2725
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2029
it's implemented the attack to CVE 2008 0166. This is
Sake Blok schrieb:
On Tue, Aug 05, 2008 at 02:22:58PM +0200, Paolo Abeni wrote:
hello,
In a pending patch for the SSL dissector:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2725
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2029
it's implemented the attack to CVE 2008
Ulf Lamping wrote:
Sake Blok schrieb:
snip
I personally vote against inclusing of this code into the source
tree. How do others feel about the inclussion of this code?
FULL ACK to Sake!
+1
___
Wireshark-dev mailing list
I'd be against inclusion too... Wireshark is a Protocol-Analyzer not a
Network Penetration Analysis tool or something similar. from that PoV
it's just unappropriate...
On the other hand someone has to tell the sysadmin to dump that key
ASAP, bad guys know it's broken already. 65536 attempts to
19 matches
Mail list logo
