Re: Python ssl handling could be better...

[bk <chort0 () gmail com>]

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/