To enable the user to decide what actions are safe, the browser
should help the user identify the site that's being interacted with.
The question i want to address in this post is how and on whose terms
that identification should happen.
I can think of five possible ways that a site could be identified, which
i'll list here in order of increasing trustworthiness. (Feel free to
suggest other possibilities to add to the list.)
1. Page appearance (images, text, titlebar, etc.). This is the most
easily forged option, but unfortunately it also seems to be the
most common and natural way that users identify sites. Most
phishing messages that i've received exploit this weakness -- they
point to an IP address and don't even try to use a plausible domain.
2. URL. For non-Firefox browsers, the user's only way to passively
(i.e. without clicking on things) identify the current site is to
look at the URL and extract the domain name. Without IDN, this
method is reliable as long as the user understands how to parse URLs
properly. I've seen a few phishing messages exploit the parsing
weakness by putting a plausible domain in the username field.
3. Domain name. Firefox extracts the domain name reliably and displays
it separately in the status bar, thereby circumventing user errors
in parsing the URL. But the domain name is only shown for SSL pages,
and the status bar isn't always visible; though it cannot be turned
off by an attacker, it can still be turned off by the user, and it
always disappears if the window height is reduced to less than about
150 pixels. It is slightly unfortunate that the domain name is shown
in a sans-serif typeface where the lowercase "l" is indistinguishable
from an uppercase "I", though this isn't an issue if the user trusts
that domain names are always shown in lowercase.
More significantly, the domain name is completely under the control
of the remote site. An attacker can select any available domain
name, and even if "paypal.com" is not available, attacks from domains
such as "secure-paypal.com" or "paypal.bank-accounts.com" may still
have a good chance of succeeding.
4. Organization name. Finally we get to an identifier that may not be
completely controllable by an attacker. In order to use a particular
organization name in a certificate, the attacker must convince a CA
to issue a certificate with that name. If the CAs are scrupulous and
competent, they should refuse to issue certificates with confusing or
misleading names. If the CAs require applicants to present proof of
incorporation, and if we trust the government's ethics and competence
in preventing people from claiming confusingly similar company names,
then an attacker should not be able to get a certificate with a
well-known company's name on it.
Moreover, the organization name is a much more familiar identifier
("Wells Fargo and Company") than a domain name ("wellsfargo.com")
to a user, especially a user who is trying to bootstrap from trust
in the real world to trust in an online entity.
However, CAs and the government are far from perfect. The long list
of root CAs in browsers is rather scary: Firefox has nearly 100
certificates from about 30 companies, and a single incident of
misconduct, carelessness, or a security breach by any one of these
companies compromises the trustworthiness of the whole system.
(Verisign has already demonstrated its incompetence by issuing a
"Microsoft" certificate to an impostor and a certificate whose name
is "CLICK YES TO CONTINUE".)
Furthermore, the CAs are mostly unknown to the user. Whereas the
user can be expected to have some kind of trust relationship with
the government, the user has no trust relationship with the CAs, has
no basis on which to judge their reliability, and shouldn't be forced
to assume trust in an unknown entity just to do business online.
5. Petname. A "petname" is a user-assigned name (usually associated
with the site's public key). From a user's point of view, a petname
is by far the simplest mechanism to identify a site -- no domain
registrars, governments, or certificate authorities are involved.
Seeing a particular petname is direct and unspoofable assurance that
the site being viewed now is the same site that was being viewed
when that particular petname was assigned.
There are valid concerns that users might not make the extra effort
to enter a petname. But, when a petname exists, it is unquestionably
the simplest and most reliable identification method, because it is
100% controlled by the user and no one else. The remote site has
absolutely zero control over what is displayed as its petname.
These five choices lie on a spectrum from no user control to total
user control, with each step yielding a more secure browser. With
Firefox, we've made it to step 3, which is further than any other
browser i know. But we still haven't escaped the attacker -- all of
steps 1, 2, and 3 are still under complete attacker control.
Firefox already makes huge assumptions about trusting CAs, so moving
to step 4 would probably be an improvement, though i would much rather
see Firefox aim for step 5.
-- ?!ng
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security
