Bernie Sumption wrote:
Graham, Nelson, Eddy, you all make good points.
I'll take your word for it that it's impossible to detect MITM attacks
with 100% reliability, as I said I'm not a security expert.
How about an MITM detection service that gives no false positives, but
might give false negatives? If you positively identify an MITM attack,
you can present users with a much more definite UI saying "this *is*
an MITM attack" and giving advice about what to do in the event of an
MITM.
This is what we have now, sort of. It detects any
certificate MITMs. It also treats any misconfigurations or
use of non-CA certs as potential attacks. It pretty much
picks up all real cert-based attacks on the browser.
The problem here is that the real MITMs are almost
non-existent, the "false negatives" are routine, and there
is no real way to tell the difference. What then is
displayed is (generally) not an attack, the users known
(generall) that it is not an attack, so the users believe
the display to be wrong (fairly).
Click-thru syndrome.
This part is well known. What is less easy is what to do
about it. It all depends on ones commercial or structural
or security viewpoint.
What is clear is that there are no easy answers. Solution A
will offend group X, solution B will offend group Y, etc.
The only solution that seems not to be offensive is to do
much more TLS so that much more attention can be fixed on
the problem. Attention at all levels: user, developer,
LAMPs, ...
But, this is currently blocked by two factors: the absence
of TLS/SNI in servers, and the difficulty of getting certs
into servers. Both situations are slowly getting better,
but aren't really the subject of here.
(I'm talking high level here. Please don't respond with the
normal self-serving low level message.)
I'm not talking about fixing all the problems for all the users, just
a real improvement for a proportion of users.
For example, can one give site owners a way of specifying that their
domain must not be accessed if it presents a self-signed certificate.
Paypal.com would no doubt take this option, as would any large bank.
If the method is made easy enough, so might other sites like facebook.
Yes, this is the solution known hereabouts as Key Continuity
Management. (With a twist.)
Two possible methods that don't require a detection service
(mitm.mozilla.org) might be a DNS record (doesn't work if the attacker
has compromised DNS) or a subdomain naming convention (i.e.
secure.example.com requires a valid certificate - presents adoption
issues for existing sites).
This would likely have stopped the original bug poster from revealing
her password.
Easily defeated with secure2.example.com ? The problem with
technical solutions (only) is that the attack is not at the
technical level, it is at the interface between the tech and
the human. Adi Shamir puts it well in his 3rd law:
"Cryptography is typically bypassed, not penetrated."
The corollary to this is that it is typically wrong to
improve the crypto. E.g., think about all the efforts to
move from 40bits to 256bits ... Security Architecture is
about expanding the security model, and integrating the
human into it, not improving the bits & bobs.
Introducing a new screen that has a far
lower rate of false positives seems a reasonable thing to try.
Yes, but that is fundamentally impossible without a massive
increase in the number of actual MITMs (won't happen for
many and various reasons) or a massive decrease in the
number of other cert errors (won't happen for many various
reasons).
As far as the false positives versus false negatives is
concerned, we are fundamentally stuck with the current balance.
Although, I agree with one point. The screen should analyse
the self-signed cert and show it is self-signed. It is easy
enough to say "look, Mate, this would never be done on a big
ecommerce site or a bank, but it might be done on a hobbyist
or sysadm site."
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
