Message-Id: <86ACB501-7CFB-431B-B3D0-9A55C48B37E7@gmail.com>
Date: Sun, 27 Feb 2011 10:58:26 -0800
From: bk <chort0@...il.com>
To: security@...hon.org,
 full-disclosure@...ts.grok.org.uk
Subject: Re: Python ssl handling could be better...


On Feb 27, 2011, at 5:57 AM, dave b wrote:

> On 27 February 2011 18:36, bk <chort0@...il.com> wrote:
>> On Nov 14, 2010, at 8:54 AM, dave b wrote:
>> 
>>> Just when you thought it couldn't get worse...
>>> 
>>> http://bugs.python.org/issue3596
>>> http://bugs.python.org/issue4870
>> 
>> As a follow-up to this, I recently started working with the python-twitter library (http://code.google.com/p/python-twitter/) that makes use of urllib2 for HTTPS requests, which in turn relies on httplib (that is shipped with Python).  Auditing all the way back down the stack of objects I didn't notice any parameters that override the defaults to require certificate verification, and in fact the ssl library for Python 2.6.5 (which is the latest on OpenBSD at least) does no verification of the server's cert by default.  I checked the page for httplib (http://docs.python.org/library/httplib) to see if I could pass a parameter to override the default (insane) behavior and found this helpful message: Warning This does not do any verification of the server’s certificate.
>> 
>> So anyone using Python's built-in httplib (usually via urllib2) is screwed.
>> 
>> You can't say you weren't warned (even Facebook has heard of Firesheep, there's no excuse).
> 
> The behaviour isn't that insane. While some of us disagree with it the
> python developers are correct in saying that changing this behaviour
> (by default) will break stuff.
> 

No, this is just plain stupid.  Web browser creators caught on a long time ago that allowing users to connect to unauthenticated pages by default defeats the whole purpose of SSL (or any encryption).

Apparently some people still do not get it:
- I want to encrypt something

- The only value this has is if "bad" actors can't see what I'm encrypting

- It's impossible to enumerate the set of "not bad" actors, so we encrypt to a set of "good" actors

- We need to authenticate the "good actors" to make sure they're the only ones who can read our message

- This is why clients need to verify server certificates, because otherwise there's no way to know if your message is being decrypted by a "bad" actor or a "good" one

- If you think it's "hard" to forge certificates, realize this: With the default Python configuration you don't even need to know who the message is encrypted for--you can use ANY certificate, ARP poison for the gateway, run a transparent proxy, and BOOM! You have the "secret"

- If you have the ability to sniff unencrypted traffic, you also have the ability to hijack unauthenticated HTTPS traffic, it just that simple.

- ENCRYPTION IS POINTLESS WITHOUT AUTHENTICATION

- It was python dev's fault they set expectation that totally insecure implementation of HTTPS would work--bite the bullet and put the correct (secure) behavior in by default. All it's going to break is insecure applications, but on the plus side it will ACTUALLY secure many applications that have a false sense of security right now.

- By not fixing the default behavior, actual harm is being caused.  Insecure apps are believed to be secure.  That's worse than stopping insecure apps from working (at least then they have the chance to realize what's wrong and fix them)

- For example, look at Twitter and removing basic auth

> Also thanks to some awesome work by Antoine Pitrou [0]
> in python3.2   -->  "http.client.HTTPSConnection,

That's great, but doesn't help 2.6.

--
chort

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

Powered by blists - more mailing lists