Full Disclosure mailing list archives
Re: Python ssl handling could be better...
From: Marsh Ray <marsh () extendedsubset com>
Date: Fri, 04 Mar 2011 11:58:28 -0600
On 03/04/2011 10:14 AM, bk 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.
A minor correction -- SSL/TLS does support a mode for anonymous Diffie-Hellman key exchange. But most SSL stacks (such as OpenSSL) disable it by default to avoid a downgrade attack which application code usually neglects to check for. Unless client certificates are required (very rare), the server has no way to detect the presence of a MitM. So if the server presents a certificate, he's really depending on the client to check it.
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.
What about a lock that, with a little practice, could be picked in 30 seconds? My understanding is that's about the security of most home locks sold today. I can't explain why.
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.
Look for something to show up in the Android app store in the next year (if it's not there already). I guess Python developers don't use public WiFi much.
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)?
Michael has an interesting point here. I agree that most people on the defending side long enough get beaten down and end up resigned to doing "vulnerability management". (I think we primarily have some large vendors to blame for this defeatist attitude.) I'm not one of them though. As as software developer, I know I have very little control over how my code is actually going to be used. The more general-purpose a facility is (e.g. a network protocol library) the less it is possible to make assumptions about where it will be deployed. SSL is a perfect example. It was originally conceived as a way to let individuals feel comfortable enough to type their (limited liability) credit card number online and thus enable ecommerce. But it has subsequently become one of the most heavily used data security protocols ever, and is now used for some of the most security-critical things imaginable. (Note that the Pentagon has a preference for off-the-shelf solutions these days.) So because it is impossible for us software developers to know the value of the asset being protected, we must hold ourselves to a near-zero tolerance for insecurity. We have to meet the requirements of our users who have the highest requirements, not the average case. Nevertheless, failing to check the server's cert is simply a joke and not anywhere close to an gray area of acceptable risk for anyone. The Python developers aren't dumb. What they are saying is, perhaps unconsciously, that they don't consider their implementation appropriate for high-value systems. Python is big in the financial industry. It is a near-certainty that there are financial systems using this Python thing on the client side to manage large assets and people are thinking they are secure because the server is properly requiring the use of HTTPS. Those of you at financial institutions should probably either require client certificates everywhere or track down every client-side script (especially those at remote client sites) and audit it for this vulnerability, if you haven't already done so. - Marsh _______________________________________________ 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... Tim (Mar 02)
- Re: Python ssl handling could be better... Charles Morris (Mar 07)
- Re: Python ssl handling could be better... Valdis . Kletnieks (Mar 08)
- 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... 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)