Re: MITM in the wild
No. There is no consensus. There are opposing camps. One camp believes that the solution is to drop all self-signed certs. Another camp believes that Key Continuity Management is the answer. Yet a third camp believes that user training has to be done, and the UI needs a little tweaking, is all. A fourth camp has written off SSL / secure browsing as irrepairably flawed. A fifth camp believes that only protocol bugs and the number of bits is security, the rest is outside purview. A sixth camp believes this is not a technical issue at all, and will be solved by the lawyers. If we look over the hill, we'll see other camps, hear much muttering, and in the end, we all return to our cups and mutter on... How about a consensus that there is no consensus? [camp A] NO! [camp B] NEVER! Thanks for the nuanced answers Ian G and the rest, I've enjoyed this chat. I'm not sure exactly what I had hoped to contribute, but I've certainly educated myself. You want a cup of wine with your muttering? :) 1994 Urbina Gran Reserva Rioja if you please. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
If we create an error display that says No kidding, this absolutely is an attack and we're stopping you cold to protect you from it. it seems unavoidable that users will learn to treat the absence of such an unbypassable error display as proof to the contrary, proof that the site is genuine and verified. Do we want to train them that way? I don't think that this is an issue. I believe most users likely never see a MITM attack in their browsing carer - indeed this rarity of real MITM attacks is the reason why real attacks are interpreted as false positives, it's just the most likely explanation for a cert error screen. If a MITM detection service could be designed that gave no false negatives, most users would never see it, so would not learn to associate the existing cert error screen with an all clear. I have no idea if MITM attacks are generally targeted at users, as in the case of this thread, or against servers. If MITM attackls are targeted at servers, I accept that there is very little that Firefox can do to stop this. If the attack is targeting a user, surely there is an opportunity for Firefox to help the user realise that they are being MITM'd? This could be a sustained attack, lasting days or weeks, slowly collecting all of the user's passwords. The idea of it makes me shudder! Any solution will be an imperfect trade-off, but is it really the consensus that there's no better trade- off than the current situation? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
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. 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. 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. If you could implement a perfect MITM detection service, that would be of some value. But an imperfect MITM detection service simply becomes the favorite new target of attackers. A perfect MITM detection service is useful in that if it detects an MITM then that might be a basis upon which to stop the client cold. But in the absence of such detection, there is still no proof that the cert accurately identifies the party it claims to identify. Trouble is, users will learn to treat the absence of a definitive MITM detection as if it WAS proof of the server's identity. I can see how there are philosophical reasons to avoid any MITM detection even if it gave no false positives, because a false negative would be interpreted as an all clear. However, if the user who filed the bug report is anything to go by, people are already misinterpreting real MITM attacks as false positives. Making the error screen scarier for all errors won't fix this because users will just learn that the new scarier screen is what false positives now look like. Introducing a new screen that has a far lower rate of false positives seems a reasonable thing to try. I know you brought it up somewhere on Bugzillago ahead and implement it. Implement what? There's no proposal yet, I'm just trying to start a constructive discussion. If there is interest in implementing something resembling my suggestions, I'll pitch in as much as my schedule and ability allow. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
Is removal of the ability to override bad certs the ONLY effective
protection for such users?
No. If we can detect MITM attacks, the problem goes away. There are
ways of detecting MITM attacks, but first of all, this is why we need
to do it:
The problem as I see it is that the same warning UI is shown whenever
there is a less than perfect certificate. Let us assume that 99.99% of
the time, this either a misconfigured web server or a homebrew site
that is using self-signed certs because they only care about
encryption, not authentication. 0.01% of the time it is a MITM
attack.In the MITM scenario the UI is not harsh enough. In the common
case it is too harsh.
The important thing is that we recognise that some kind of MITM
detection is essential, no matter how hard it might be to implement,
because if you show the same UI for a MITM attack as you show for a
misconfigured/homebrew web server, even quite savvy users are going to
assume that a real MITM is a misconfiguration/homebrew.
In the event of a MITM attack, the user should be shown a huge red
warning, like the phishing and malware warnings, stating that Firefox
has detected a man-in-the-middle attack: we think that an attacker is
intercepting your connection. Whether you let users override this can
be debated.
In the event of a misconfigured web server / homebrew site, the user
could be shown a more qualified warning that this site uses
encryption, but can't be identified because {$REASON}. It is
difficult, but not impossible, for an attacker to see any data you
send or receive. If you use this site for important communications or
financial transactions you should not use it. Please contact the site
owners and let them know about this problem.
Here's one idea for detecting MITM attacks, but I'm not a security
expert so please don't jump on me and call me an idiot. If this way
doesn't work for some reason, I'm sure that there are other ways:
The browser could send all self-signed or invalid certificates to a
trusted MITM detection service, say https://mitm.mozilla.com. A MITM
on this site is impossible because it would have a valid certificate.
This site could inspect the certificate and use a variety of
heuristics to detect MITM attacks:
* The service could connect to the same site and check that it has the
same certificate, which obviously only works if the attacker is not in
a position to MITM the trusted server too (if the attacker is on the
same network as the host, they can MITM any client on the Internet).
* The service could use a community based approach as used by phishing
detection to report MITM attacks so close to the target host that they
can MITM the entire Internet.
* There could be some kind of opt-in way (through a DNS record?) of a
site specifying a MITM policy, so banks could state that anything but
a properly signed certificate is treatede as an MITM.
* Any other ideas?
Care would need to be taken with privacy, but if this approach works
with phishing, why now MITM?
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
