| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <897E4639-97DC-436D-814E-5A4179EBE7D0@gmail.com> Date: Mon, 28 Feb 2011 10:37:18 -0800 From: bk <chort0@...il.com> To: full-disclosure@...ts.grok.org.uk, Michael Krymson <krymson@...il.com> Cc: security@...hon.org Subject: Re: Python ssl handling could be better... 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/
Powered by blists - more mailing lists