
Full Disclosure mailing list archives
Re: Python ssl handling could be better...
From: Charles Morris <cmorris () cs odu edu>
Date: Mon, 7 Mar 2011 11:10:10 -0500
On Fri, Mar 4, 2011 at 11:14 AM, bk <chort0 () gmail 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/
Current thread:
- Re: Python ssl handling could be better..., (continued)
- Re: Python ssl handling could be better... bk (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... bk (Mar 02)
- Re: Python ssl handling could be better... Marsh Ray (Mar 03)
- Re: Python ssl handling could be better... Jeffrey Walton (Mar 03)
- Re: Python ssl handling could be better... Charles Morris (Mar 02)
- Re: Python ssl handling could be better... bk (Mar 02)
- Re: Python ssl handling could be better... bk (Mar 04)
- Re: Python ssl handling could be better... Marsh Ray (Mar 04)
- Re: Python ssl handling could be better... dave b (Mar 04)
- Re: Python ssl handling could be better... Marsh Ray (Mar 07)
- Re: Python ssl handling could be better... Tim (Mar 04)