On 21/09/11 03:32 AM, Jeffrey Walton wrote:
On Tue, Sep 20, 2011 at 1:09 PM, ianG<[email protected]> 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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
