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

[bk <chort0@xxxxxxxxx>]

Sigh, sending with correct account...

On Feb 28, 2011, at 9:34 AM, Michael Krymson wrote:
> 
> What about self-signed certs in my closed network?

The ssl.py module (library/whatever) has support for selectively disabling 
certificate verification.  This parameter should be exposed up the stack in 
modules that rely on it.  The second major problem here is that httplib.py does 
not support that parameter, so anything higher in the stack is tied to the 
(incorrect) default.

That's the thing with default behaviors: The default should be set to something 
sane (in the case of encryption, SECURE) and there should be a way to override 
it if a significant number of users will want to do so (two strikes against the 
Python dev team).

BTW there really isn't a security difference between 
encrypted-but-unauthenticated traffic and just plain unencrypted traffic.  The 
only "attacker" you're defeating is a casual observer, who probably is more 
curious than harmful. Determined attackers who are out to harm you are going to 
get the information any way.  If something is important enough to encrypt 
traffic to/from, it's important enough to authenticate too, otherwise it isn't 
worth the hassle at all.

> What about guests on a network behind a web proxy that MITMs 80/443?

If you're intentionally MITM client traffic, the client should trust your MITM 
CA.  If you aren't doing it that way, ur doin it rong.  You basically just 
compromised the security of all of your end-points and are training your users 
to ignore warnings.  In the case of Python apps, you're teaching your 
developers insecure coding practices.  It's cascading stupidity.

> What if you're brokering a connection, not for some strict security sake, but 
> just because you can and gain a little bit of privacy? Have any personal web 
> sites/servers you don't *need* commercial certs for but want something anyway?

See above.

> 
> In an ideal world, I hear what you're saying. But we're far from ideal...

It's not ideal because people take the lazy way and assume that unauthenticated 
encryption is "good enough."  It's not good enough because it's trivially 
broken.  It used to be (say, a decade ago) less risky because there weren't 
readily available tools everywhere that could do the active MITM, but now there 
are and everyone has already learned to be lazy, so we're at a net deficit from 
the starting point.

Every time you tell yourself "it could be broken, but I'm sure no one will make 
that much of an effort" you're wrong and just made a fundamental mistaken.

> 
> I think we should be happy with the inclusion of such options in 3.2....

No, I'm not going to be happy about an after-thought fix.  At least httplib.py 
should never have been put in the tree without an option to tell ssl.py to 
verify the server cert.  FFS they have client cert support, would it REALLY be 
that hard to pass the verification parameter to ssl.py?  No, it's just sheer 
ignorance of security.

--
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/