Message-ID: <4D751C45.4050502@extendedsubset.com>
Date: Mon, 07 Mar 2011 11:56:21 -0600
From: Marsh Ray <marsh@...endedsubset.com>
To: dave b <db.pub.mail@...il.com>, Charles Morris <cmorris@...odu.edu>
Cc: full-disclosure <Full-Disclosure@...ts.grok.org.uk>
Subject: Re: Python ssl handling could be better...

On 03/04/2011 09:35 PM, dave b wrote:
> Marsh, the thing is that the ssl module was only introduced in python
> 2.6. [0] There has been other options for a _long_ time. As an
> example, (for https traffic) pycurl.

Oh good, there aren't many users who will be affected by the fix then.

So now you really have no excuse for not patching it correctly.

> So python developers can and do use public wifi without problems.
> Only the ones who do not read warning messages are at risk.

Warning: Python's 'ssl' module implements just enough of the
specification to successfully transfer data. It doesn't actually provide
security.

> Of course a fair amount of code would have been written before the
> warnings were added...

I know how that goes. Bugs happen and occasionally they require 
"breaking" API changes to fix. But this is software engineering 101 - 
API bugs are expensive.

On 03/07/2011 10:10 AM, Charles Morris wrote:
>
> You are quite right that false security is a serious and pervasive
> problem today. If there is a problem with Python's SSL
> implementation, which I assume there is, it should be fixed,
> regardless of breaking existing applications.

The trap is thinking of the current situation as "working" and that the 
fix "breaks existing applications".

The existing applications are broken _now_.

The necessary fix just converts the brokenness from a hidden 
vulnerability to a visible-but-innocuous refusal to establish an 
insecure connection.

> If it's trivial for you to break asymmetric encryption you wouldn't
> be publicly making the claim that it was trivial for you to break
> asymmetric encryption.

Yeah, you'd be better off just patenting the solution :-)

>> If
>> you're talking about whether it takes 5 minutes to download a
>> sniffing program vs. taking 10 minutes to download and configure
>> tools to MITM a connection, that's not shades of grey.  It's
>> freakin broken.
>
> Even that is shade of gray. True, the magnitude and growth of O is
> unchanged, but sorry friend, 5 does not equal 10. I also explained
> why it's not a comparison of 5 to 10.

Hmm let's try that out:

     "Our encrypted data security library is so secure that it
     takes at least [T] minutes to download and configure the
     exploit for the known vulnerability that we find
     inconvenient to patch."

          when T = 5,  user = PWNED 4 THE LULZ
          when T = 10, user = PWNED 4 THE LULZ

They are equivalent in any meaningful sense.

> Especially if in that 5 you are caught and your attack stopped.
>
> Which, you would be, if you were on my network.

Well, for one thing the entire purpose of SSL/TLS is to make it possible 
to transmit data securely across untrusted networks. So any analysis 
must assume that the network is hostile. This turns out to be a pretty 
good model in practice.

But on a more practical level, I suspect you're wrong (or your network 
is trivial). The attack may look like ordinary traffic from the 
perspective of the client or the server.

Your network monitoring checks the validity of the certs used in SSL/TLS 
handshakes?

Even if a valid certificate is presented by the server side, how do you 
know what site the client was intending to connect to? Do you maintain 
some association between the client's DNS lookup and a subsequent 
outgoing connection?

Or maybe your network is on the server side.

In that case, how would you know what certificate the client was trusting?

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

Powered by blists - more mailing lists