full-disclosure - Re: Python ssl handling could be better...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 7 Mar 2011 11:10:10 -0500
From: Charles Morris <cmorris@...odu.edu>
To: bk <chort0@...il.com>
Cc: full-disclosure <Full-Disclosure@...ts.grok.org.uk>
Subject: Re: Python ssl handling could be better...

On Fri, Mar 4, 2011 at 11:14 AM, bk <chort0@...il.com> wrote:
> On Mar 4, 2011, at 7:53 AM, Michael Krymson wrote:
>
>> The problem with this discussion is simply one of definition of security. For some, security is entirely black and white.
>
> I can't speak for others, but I don't see anything as black & white.  What I'm railing against is FALSE security.  If it can be trivially
> broken, it shouldn't be labeled as security.  Python has an incomplete implementation of SSL.  The protocol was not designed to
> be used w/o authentication.  It's lazy people who took it out.  One cannot implement a lock without pins.  If anyone can walk up
> and turn the plug, it has no value and if someone is selling that to you to make your house safe, they would be sued.

You are quite right that false security is a serious and pervasive
problem today.
If there is a problem with Python's SSL implementation, which I assume there is,
it should be fixed, regardless of breaking existing applications.

Yes, the snake oil salesman has never had a better opportunity to make
a buck than 1996 to today.

If it's trivial for you to break asymmetric encryption you wouldn't be publicly
making the claim that it was trivial for you to break asymmetric encryption.

>
> If we're talking about whether a certain key length would take 20 years vs. implementing more operations to make it last for 50
> years, that's a discussion of acceptable levels of risk and it comes down to what's appropriate for the data you're protecting.  If
> you're talking about whether it takes 5 minutes to download a sniffing program vs. taking 10 minutes to download and configure
> tools to MITM a connection, that's not shades of grey.  It's freakin broken.
>

Even that is shade of gray. True, the magnitude and growth of O is unchanged,
but sorry friend, 5 does not equal 10.

I also explained why it's not a comparison of 5 to 10.

Especially if in that 5 you are caught and your attack stopped.

Which, you would be, if you were on my network.

>
>>
>> These people probably tend to be those who've actually had jobs in general digital defense...
>
> LOL, really?  Have you seen http://extendedsubset.com/?page_id=2 (Marsh Ray)?  What about http://www.sentinelchicken.com/advisories/ (Tim).
>
> I've worked in security roles since 2000 and I'm credited in http://support.apple.com/kb/HT2009 .

CVE-2008-2538
CVE-2007-4070
CVE-2006-4315
CVE-2005-4158
CVE-2005-1993

I suppose then, by your own standard, you should respect my argument
and stop defending a broken position?
No... I wouldn't expect you to. There's always someone with better
credentials. Stay out of this Michal! ;D

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/