[cryptography] SSL is not "broken by design"

ianG iang at iang.org
Tue Sep 20 18:27:43 EDT 2011


On 21/09/11 03:32 AM, Jeffrey Walton wrote:
> On Tue, Sep 20, 2011 at 1:09 PM, ianG<iang at iang.org>  wrote:
>> On 18/09/11 20:02 PM, M.R. wrote:
>>> On 18/09/11 08:59, James A. Donald wrote:
>>>
>>>> If we acknowledge that SSL is not secure, then need
>>>> something that is secure.
>>> Nothing is either "secure", or "not secure". Any engineering
>>> system is either secure for the purpose it was designed for,
>>> or it is not. SSL is secure, since it is secure for the
>>> purpose it was designed and implemented for.
>> That's bad engineering.  Any system that is designed for protecting humans
>> has to base itself on risks.  Either it has a reasonable chance of
>> addressing the risks at a good level, or it addresses the risks at a less
>> than good level.
>>
>> It is only cryptographers that insist that security is binary -- perfect or
>> not there at all. Too my knowledge, no other engineering discipline falls to
>> this hubris [0].  They achieve this remarkable feat by drawing the boundary
>> of security so narrow as to be typically irrelevant to most purposes.
>>
>> This can be seen in the original design of SSL.  It was designed to protect
>> the wire, because it was theorised that the wire was where the threat was.
>>   Eavesdropping, MITMs and the like.  Not the node.
>>
>> But, if you read carefully between the lines, there was no evidence of that
>> statement.  In fact, it turns out, the reason that the threat was taken to
>> be the wire and not the node was that (a) there was a military cryptography
>> model that supported wire threats as important, and (b) there was an exotic
>> and sexy cryptography design that could defeat it.
>>
>> In other words, they did it because they could [1].
>>
>> In practice it was the reverse:  in commercial threats, the node is the
>> problem.  It's always been far greater of a problem than the wire [1].  This
>> is why SSL is often considered to be a fashion accessory, not a serious
>> indicator of security; it didn't solve the real problem, but it itself
>> wasn't much of an issue until attackers started embarrassing it by invading
>> its design space with attacks.
> It seems to me that both the network and the endpoints are at risk. By
> what degree the endpoint exceeds the network is an open question for
> me since (in my observations) most folks and organizations don't boast
> like ComodoHacker. Sadly, I suspect its 'epidemic vs pandemic' and not
> 'rare/isolated vs occasional'.

Right, so the question is a judgement call.  But it can be an informed 
one.  You can come up with "low risk" and "high risk" ... design for 
high risk, and accept low risk.

The point in general was that SSL v2 especially treated a very low 
theoretical risk as a high risk, and this had the consequence of raising 
its cost dramatically.  In the event, from almost costless to almost 
undeployable.  Thus it reduced its cost-effectiveness, eventually 
reducing its impact to the point where it reduced security overall.

In contrast, SSH was informed by its evidence of risks, so it got them 
right - at a good cost that all were happy to afford.
> Network attacks are not an isolated incident (recall Tunisia and
> Facebook?), not to mention chronic problems with Cisco gear in the
> network, and the cheap cable/dsl broadband routers and home networking
> equipment that rarely gets updated.

Sure.  But what was the security requirement again?  Credit cards over 
the net.  Between people who hadn't met.

This is sooooooo far away from Tunisia and Facebook that really, it 
doesn't count. And, local routing didn't really emerge as a threat to 
credit cards.  Even though we were all watching and waiting, watching 
and waiting.

So, in short, the predicted threat never really materialised, because 
the cost of SSL caused an easier attack to open up - bypass/downgrade to 
HTTP.  Since the original analysis, SSL has migrated outside its 
business space and into new areas.  Maybe the original threat model is 
holding us up?  Maybe we need a new business model which will tell us 
what threats to worry about, instead of repeating the doctrine that MITM 
must be protected even if it is killing us?

Clearly, something has to give.  What is it?

iang



More information about the cryptography mailing list