Message-ID: <AANLkTimZdfG5hdJgLW5N6yvVjn53oMfhOjLeS1f5Gy1b@mail.gmail.com>
Date: Thu, 3 Mar 2011 16:20:41 -0500
From: Jeffrey Walton <noloader@...il.com>
To: Marsh Ray <marsh@...endedsubset.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Python ssl handling could be better...

On Thu, Mar 3, 2011 at 3:24 PM, Marsh Ray <marsh@...endedsubset.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
> 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.
http://www.theregister.co.uk/2011/01/25/tunisia_facebook_password_slurping/

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?',
http://lists.gnupg.org/pipermail/gnupg-users/2011-March/040893.html.

Jeff

_______________________________________________
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