[aklug] Re: reviewers needed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/2012 05:30 PM, David J. Weller-Fahy wrote:
> * Christopher Howard <christopher.howard@frigidcode.com>
> [2012-02-29 20:48 -0500]:
>> On 02/29/2012 04:01 PM, David J. Weller-Fahy wrote:
>>> 1) In "Masking Origin" perhaps some talk of traffic analysis
>>> and why proxy services which do not run on your machine would
>>> be ineffective (i.e., anonymizer.com doesn't do the job,
>>> really).
>
>> Thanks for the response! Regarding this point, can you clarify
>> what you mean? Are you referring to someone doing traffic
>> analysis of output from the proxy service (and comparing it with
>> yours)?
>
> Nope, I'm referring to free anonymization services which allow
> people to connect to the anonymization service via the web, and
> (from the website) connect to other websites - for example
> kproxy.com. Most common users are probably not aware those types
> of services are not nearly as "anonymous" as having something like
> tor running on your system. Using a service like that means any
> traffic from you to the anonymizing server is effectively
> unprotected (especially given skilled mitm implementations), and a
> note to that effect was what I was talking about.

Ah, yes, I forgot about those.

>
>> Sigh... we've almost completely failed to implement the vision
>> the creators of SSL originally had in mind. It was never meant to
>> be special security protocol reserved for processing credit card
>> transactions or making elite Web sites look "safe". It was
>> supposed to be an added security layer underlying the whole
>> Internet, giving everyone the benefit of encryption and
>> authentication over untrusted networks.
>
> I'm not familiar with the politics behind SSL's beginnings, do you
> have any references for that? I'll do my own searching, but a
> kick-start never hurts.
>

To be honest, I may have overstepped myself there in that statement.
Much of what I know about SSL/TLS is from Oppliger's book "SSL and
TLS: Theory and Practice" and I came away with a strong impression of
that. However, looking again at specific historical information in the
book, it would appear as though supporting secure "e-commerce" was, at
least, one of the highest motivational factors in the early days.
"E-applications" were just coming on the scene and Netscape wanted to
create a security layer that would serve as a cornerstone for Internet
commerce. I'm not sure about the viewpoints of all the individual
Netscape project team members.

So my statement there was, at the best, not well sourced, if not
misleading. For what it is worth, though, I had an interesting e-mail
conversation at the Mozilla crypto list recently about how the
original SSL security model was definitely broken today, due to the
popularity of "partial encryption". I'll reproduce here a response I
got from user ianG.

quote:
- ----------
On 20/12/11 08:13 AM, Christopher Howard wrote:
> There is something that I've been wondering about for a while now:
> When I connect to a SSL/TLS-secured Web site, Firefox allows me to
> click on the identity box and the "More information..." button, and
> it will give me details about the certificate, encryption grade,
> and key length. However, whenever a page is only partially
> encrypted (which seems to be quite often the case) Firefox refuses
> to provide any information about the cipher or the key length used.
> I have even installed the Calomel SSL Validation plug-in to see if
> I could get more information, but it behaves in the same way.
>
> Is there any technical reason for this? Or is this just something
> that was overlooked? Knowing the encryption details would be useful
> even on a page that is only partially encrypted.

Yeah, it's broken at the security model level. The underlying
difficulty is the clash of security models & perceptions as to what
matters.

Go back in history: SSL was invented to create one secure connection
to one site in order to protect one credit card number as it was
passed across in a HTTP POST. It was claimed that this transfer had
to be strongly protected, no matter what, against all threats, and
this must be an absolute requirement.

Hold on to that thought: the credit card must be protected, or die in
the attempt!

The response to this and other market developments was devastating to
the security model. Almost immediately (we're talking 1995) there was
pressure to turn off SSL and ditch it because it was too slow. What
happened in the market was that the "payments page" was sliced out and
set up separately so payment could happen over "slow SSL" after the
decision to buy was apparently made.

This immediately broke the entire model because there was now an easy
downgrade attack from HTTPS to HTTP in the browser, which the user was
ill-equiped to deal with (as Netscape had independently modified the
GUI to drop the CA's name). But on paper, the actions of the servers
were compliant because they could point at *their received credit card
numbers* and show that they were protected. Strongly. No matter what
... including putting at risk credit cards they never saw. Everyone
was happy.

Move forward a few years, and browsers & sites started breaking other
assumptions, and phishers turned up and started exploiting the
downgrade attack in the browsers. So, the original killer
requirement, that the credit card must be protected against everything
imaginable ... killed the security entirely by causing implementors to
turn off the model in what they thought were safe circumstances.

In practical detail right-now terms the question is that the GUI
people don't know how to present a mix of zero-security with
ultra-high security. What does that mean? do we average it? Say it
is top-security and pray it is? Say it is no security and ignore the
rest? (The answer from the model is, like renegotiation, the browser
should drop the connection.)

That argument can go around and around, but keep coming back to the
original requirements. Then, we see that answer to your question is
irrelevant, because the absolute requirement was bypassed so badly
that the model was broken. We're not using the SSL security model,
and haven't been since 1995. So you can do whatever you like, or more
practically, whatever you feel you can get away with (think about the
dozens of connections that modern portals fire up, and outsourced
payment processors and google tools and ...).
- ----------

- --
frigidcode.com
indicium.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPVYhvAAoJEI2DxlFxTtgdPscIAJG1f3k5J7Fgq8g6hKZtk/yc
Wp5AU92o6x5grFZMgMBIjODVxPPJpu+nVqoIGtjEkT6SHAJtELjqJOHDlrtp/cE/
IhCO24JuL7ZaGLZG9itH74jo3mzLOy2q2u4iAnPWxIa2Tdj7NMupve7EHt0J1k8U
DKy03Azqtvq3J3HAQ0v8oYJqiNOqQTfxXoJMhlGlvO1E/0subNHmRMqsYOisLoBf
xjXGcrk285L3AFaFPS270RAJsRMI9n13KiRjkJHyzVb/5r0NCV9AxqME3LeqsYAl
VbgSe/6ddhXcQ9gkv0BOR4X+pshv44CSeW8Qau+wMQJh1sQtk6l+4THsYtUXqsw=
=u3cg
-----END PGP SIGNATURE-----
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Mar 5 18:42:58 2012