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

[bk <chort0@xxxxxxxxx>]

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

> On 27 February 2011 18:36, bk <chort0@xxxxxxxxx> 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/