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 usin
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
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 u
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 indexe
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 prefe
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 an
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 loopi
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 an
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
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 website
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 need
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
hello,
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 only available to
> legitimate administrators of the sys
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
> > b
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 l
On Wed, Aug 06, 2008 at 01:47:22AM +0200, Luis EG Ontanon wrote:
> 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 see if
> eventually we could decrypt and add an expert item in regarding the
> vulnerability would be a
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 see
Ulf Lamping wrote:
> Sake Blok schrieb:
>>
>> 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
Wireshark-d
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 attac
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 i
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 k
21 matches
Mail list logo
