[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    Re: [Full-disclosure] Python ssl handling could be better...
From:       bk <chort0 () gmail ! com>
Date:       2011-02-28 18:37:18
Message-ID: 897E4639-97DC-436D-814E-5A4179EBE7D0 () gmail ! com
[Download RAW message or body]

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/


[prev in list] [next in list] [prev in thread] [next in thread]