Re: Python ssl handling could be better...

[bk <chort0 () gmail com>]

On Mar 2, 2011, at 12:36 PM, Charles Morris wrote:

> > > <a bunch of crap>

1.  Read Tim's e-mail.

> > > In short-
> > > 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
> without authentication)
> 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
> (cleartext authentication)
> 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 
be SPOOFED.

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.

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