mailing list archives
Re: Python ssl handling could be better...
From: bk <chort0 () gmail com>
Date: Wed, 2 Mar 2011 15:42:00 -0800
On Mar 2, 2011, at 12:36 PM, Charles Morris wrote:
<a bunch of crap>
1. Read Tim's e-mail.
Encryption without authentication is ALWAYS BETTER than no encryption
It's not. Would you like to jump out of an airplane with a parachute that you THINK will work, but doesn't, or one
that actually will
work? You'd make a different choice if you knew the chute wouldn't open.
It is. A parachute that works a nonzero % of the time (encryption
is infinitely better than one that you can BE SURE WILL NEVER WORK (plaintext)
The application, or parachute, should warn of the danger involved so
the user may make an educated choice.
No, wrong. You make a different choice if you know the parachute isn't safe. You aren't forced to jump, you're
evaluating the risk of jumping vs. risk of doing something else. If someone gives you a parachute and says "here, this
is safe" when they know full-well it isn't, but YOU don't know that, it's worse than not jumping.
Authentication without encryption is ALWAYS BETTER than no authentication
Not if it can be captured/replayed to impersonate you in the future. WTF are you smoking?
It is. Authentication that resists a nonzero percentage of attackers
is ALWAYS BETTER than no authentication whatsoever.
Again, you make a different choice if you know for certain your credentials are vulnerable. It's a false sense of
security that lures you into making an unsafe decision.
If you know every connection is going to be anonymous, you build different access control models and make different
authorization decisions than you would if you THINK you know who performs each actually, but in reality they can easily
The entire point is that it's dangerous and deplorable to lie to users and give them a false sense of security. The
users don't know any better, they're trusting us to offer them appropriate protections. The problem is careless folks
like the people who wrote Python's ssl.py and httplib.py were brazen in their disregard for security. They presumably
know what SSL was designed for and how the trust model works, but they chose to implement only the encryption and not
the authentication, then held it out as some kind of security. It's not security. People would make different choices
if base Python only supported HTTP. They'd write their own module that correctly implements HTTPS and widely
disseminate that, but why go to all that effort if you THINK it's already secure (hey, it uses SSL!)?
I really, really hate liars, and people who pawn off encryption (that amounts to really expensive encoding) without
authentication as "security" are evil. Don't fucking lie, just tell the users they're going to be compromised if they
use your stuff, so they know better.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: Python ssl handling could be better... bk (Mar 02)
Re: Python ssl handling could be better... Michael Krymson (Mar 04)