Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Python ssl handling could be better...
From: Jeffrey Walton <noloader () gmail com>
Date: Thu, 3 Mar 2011 16:20:41 -0500

On Thu, Mar 3, 2011 at 3:24 PM, Marsh Ray <marsh () extendedsubset com> wrote:
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

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

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

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

This shit is real.

Some folks on the GnuPG mailing list don't understand why it might be
a good idea to purge key chains of email addresses (and use only key
IDs): 'Security of the gpg private keyring?',


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]