Re: [Full-disclosure] Python ssl handling could be better...

[Marsh Ray <marsh@xxxxxxxxxxxxxxxxxx>]

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/