[cryptography] SSL is not "broken by design"

Ian G iang at iang.org
Sun Sep 18 05:49:39 EDT 2011

On 18/09/11 4:34 PM, M.R. wrote:
> On 17/09/11 17:56, lodewijk andré de la porte wrote:
>  > ...therefore assumes others assume SSL to be broken by design...
> SSL is not "broken by design"!

See counter-proof at bottom.

> SSL was designed to protect relatively low-value retail commerce,
> and it still does that job reasonably well.

It does it badly, if protecting relatively low-value commerce includes 
stopping phishing.  Proof:

Note that SSL includes a large dose of authentication.  Indeed, the 
raison d'etre for SSL v2 was authentication.  PKI.

In phishing, it fails to authenticate.

Now, to cut the conversation short, you'll say "oh, SSL doesn't protect 
that!"  And I'll say, "then, SSL doesn't protect what needs protecting...."

E.g., low-value retail commerce.

And we'll go round and round in circles for years while users get 
robbed.  Which has been going on for around 8 years now.  Make a 
difference, step off the merry-go-round...

> What failed were our mechanisms to ensure that system usage regime does
> not exceed it's design parameters. If I can be flippant, SSL was a
> pedestrian bridge which ended up used to drive 18-wheelers across it.

Well, I'm one who uses analogies and has them reversed against me :)  So 
I'll have a go.

Actually SSL was designed to drive 18-wheelers over it, when pedestrians 
and bicycles were all that was needed.  Note the PKIX's obsession with 
256 bit algorithsm and exotica like renegotiation.

In contrast, note the absence of any attention as to how to use the 
authentication in a suitable fashion...  They put the bridge in the 
wrong place, there ain't a river for miles.

"Bridge in nowhere" :)

> What failed was the total absence of an equivalent of a notice in
> big red letters somewhere on the access ramp: "this structure is not
> capable of carrying heavy vehicles. If you use it to do so, it will
> collapse and you will get hurt or killed".

I kind of agree with that.  What failed was a complete absence of 
responsibility on the part of the engineers to say "don't do that!" 
Instead they repeated the mantra that SSL was very strong, and should 
always be used.  And and and...

When it came to actual failures ... they are silent.  Still.  But they 
love their merry-go-round :)

> There once was a rich, well organized industry fighting such move,
> (think CA's :), but we finally got those "Smoking Kills" notices on
> cigarette boxes. And the reasons we are not, at least as a stop-gap
> measure, putting up such notices on browsers (i.e., the package)
> right now (as the evidence of the danger of the product misuse is
> emerging not only among the experts but among the general public
> as well) is twofold: the industry lobby, helped immensely by that
> most misguided computer security doctrine: "the user is an uneducated
> moron and must be treated accordingly".

Well.  Actually I agree with that last statement, but not as a 
disrespect.  The customer is king.

The most important thing that drives any security design is K6:

     "Finally, it is necessary, given the circumstances that
     command its application, that the system be easy to use,
     requiring neither mental strain nor the knowledge of a
     long series of rules to observe."

If you look at threat modelling, the first point is:  know the business 
model.  Same point.

Get K6 right and you have a chance.  Get it wrong and it's all over 
before you begin.  You have zero chance.

PKI got it wrong;  by design:  In PKI, the CPS is a document that 
describes whether and how to rely.  This is patently and absurdly in 
contradiction to K6.

Hence, SSL v2 got it wrong, by design.  QED.

What the vendors (browsers) did was to unwind the K6 mistake in PKI by 
homogonising the CA's influence (and thus removing the CPS from the eyes 
of the user).  Now, this isn't entirely grand, they were right in doing 
that, but wrong in enough other things that we got an unworkable mess.

They didn't unwind enough (but there again, given the architectural 
direction they got from the SSL community, they can be forgiven for 
getting it wrong in 1994).


More information about the cryptography mailing list