Nelson B wrote:
> with known weaknesses.
Namely, they fall apart under not-very-difficult attacks.
Right. So take two not-very-difficult attacks
or preferably three if you can think of them,
and force the attacker to do all three. His
risks go up 10 fold each time. This is what
you'd call common or garden grade security.
> But those weaknesses are not entirely correlated.
No?
Not entirely, no. One's email, the other's
a web site.
If both of these were requested, then an
attacker would have to change over the
domain name record of the email addresses,
as well as change over the DNS settings.
Both MX records (which direct email routing) and A records
which return IP addresses for host names are DNS records.
It suffices to poison the resolver cache of a single victim's
computer to accomplish the attack on both.
Right, there are multiple ways of doing that.
As the change for the DNS settings would
involve directing all (or most) DNS traffic
over a period that was hard to determine,
this would have a much greater chance of
being noticed.
Only the issuer's traffic need be directed.
That certainly makes it easier for the attacker
to pick off both, but bear in mind he still needs
to run a proxy or website or some such, so his
costs increase even then.
And, what I
would suggest is that the caring CA be aware
of this, and do a check from somewhere else.
use SSH and jump over to another box. This
can be done via either email or for browsing.
Right. But the web content is on a site
that is currently in use. And, the more
it is in use, the more it is going to be
noticed, so this scales nicely with the
importance of the check.
Noticed by whom?
Anyone who's looking at his site. His customers,
his users, his girlfriend. The point is that this
isn't foolproof, but it raises the risks and costs
for the attacker.
You still haven't explained how web content is supposed to give
the issuer any more assurance about the party to whom an SSL
cert is about to be issued.
It shows he has control of the web site. So
now he has control over the website *and*
the DNS records, he should presumably have
identified himself better than if he had
shown control over one factor.
I gather that you propose that
the issuer will look at the page that (supposedly) comes from the
requestor's server, and take assurance therefrom. If that is your
proposal, then only the resolver cache used by the issuer's
machine need ever be compromised by the attacker.
That's a good point; see above for a bypass
to that.
The reason the email trick works - I
guess - is because that email path is
never used.
uh, no. It's because whatever email the issuer sends to the
intended recipient is intercepted by the attacker. The attacker
can click on any links, and use any passwords found in the mail
that was intended for the proper recipient, since the email
messages were not secured in any way.
No, ok, let me spell it out. The reason the
attack on the email goes by undetected is
because the admin name in the DNS record
is not used for any other purpose. So any
other emails that would otherwise be stymied
are not going to help trigger detection.
Just so we're clear; what is being proposed
is several small barriers and nuisances that
make it tricky for a thief to easily make one
hack and get away with it. It's an economic
approach, it's how you deal with things when
they are low value, and you don't want to
spend any money.
Which is fine, because we are dealing with
the standard of using email to authenticate
here, we are not trying to compete with
hard paper Id forms.
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
mozilla-crypto@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-crypto
