Re: Python ssl handling could be better...

[Marsh Ray <marsh () extendedsubset com>]

On 03/02/2011 02:36 PM, Charles Morris wrote:
> e.g. Turn off authentication on your in.telnetd, post your IP on FD,
> and tell me how that works out for you.

Any sensible person turned off telnetd long ago. When it existed with 
password authentication, password capturing was rampant.

Even worse, these captured passwords usually granted access to other 
systems.

So, yes, telnet with plaintext password authentication can be worse than 
telnet without it. "How much worse" is inversely proportional to the 
value of the system running the telnetd.

Even challenge-response authentication schemes are often not immune to 
various forwarding attacks.

On 03/02/2011 03:38 PM, Tim wrote:
> Ok great, but by comparing MitM with sniffing, we're already
> assuming the attacker has access to the traffic.  Think about it.
> There aren't any networks in common use today which in their physical
> implementation make alteration of packets harder than observation of
> packets.  This is why the big-Os are the same.

Well, there are some network links on which it's easier to observe 
traffic than inject it, e.g., unencrypted satellite downlinks.

But these networks are that way by accident, not because of any 
requirement that they guarantee this as a security property. And most 
application traffic may just as easily be routed over other other 
networks in the future.

Strong data integrity is simply not something a software developer can 
expect out of the network. It's exactly why we need IPsec and SSL/TLS.

> On Mar 2, 2011, at 12:36 PM, Charles Morris wrote:
>
> 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)

I would argue it is much much worse. All unreliable parachutes must be 
systematically destroyed.

You should ask some actual professional parachuters how they feel about 
the idea of keeping half-busted parachutes lying around.

> The application, or parachute, should warn of the danger involved
> so the user may make an educated choice.

As a software developer I too feel the desire some times to simply push
off the difficult questions on to the user. E.g.:

"The certificate is incorrect. Your connection may have been redirected
to a malicious server or proxy conducting a man-in-the-middle attack.
Would you like to connect anyway?
Click 'OK' to fail (i.e., get pwned), or click 'Cancel' to not succeed."

If the developer doesn't know if something is secure, how likely is it
that the user will be able to intelligently evaluate the risks?

This is not even a statistical "risk" like, say, an earthquake. It's
fundamentally at the option of the attacker whether or not the user is
under an active attack at any given time.

If the user were able to know whether or not they were under active 
attack at any given time, they wouldn't need the security software, 
would they?

Therefore, expecting the user to evaluate such a risk is equivalent to 
the software not providing security. I.e., it's broken.

On 03/02/2011 05:42 PM, bk wrote:
> 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.

People are being tortured and killed because their connection to 
Facebook is not secure.

This shit is real.

- Marsh

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/