Closed Bug 184881 Opened 22 years ago Closed 8 years ago

More overt presentation of SSL certificate

Categories

(Core Graveyard :: Security: UI, enhancement, P5)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: david, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

Nowadays, users have two to three options for determining whether they're on a
secure site: they either get a pop-up saying they're now entering a secure site
(annoying), they have a little "s" in https://.../ in the Location bar or a
little padlock in the lower right corner of the screen.  In addition, all this
tells users is that the site is "secure" and they can assume the site belongs to
whoever owns the domain in the URL.  It does nothing to obviously establish the
identity of the organization that owns the site.  A user hitting an SSL
"www.ebay.com" site has a pretty good idea that they're on eBay.  But what about
a site like "www.ebayupdates.com" (run by scam artists)?  If the scammer were to
use SSL, it'd look even more legitimate, and users might think that since it's
protected, and has eBay in the name, surely it's eBay they're hitting, right?

I would like to propose a more overt display of information about an SSL
connection.  Specifically, the name of the organization (and perhaps
organizational unit) should appear somewhere in the browser fairly prominently
(at least as prominent as the URL in the Location bar).  We need to get users
into the habit of doing a sanity check on the logical name of the organization
in an SSL certificate instead of just assuming that the name (or part of that
name) of the domain equals the name of the organization.  Since so many logical
entities have registered so many different 2nd-level DNS domains, it's
impractical for people to know which "similar" domains are or are not under the
control of that logical entity.  It should be more obvious in the browser.  The
SSL certificate has this information, it's just hidden behind menu options.

This also has a long-term benefit of reducing users' dependencies on DNS
hostnames and raw URL's as an *organization*'s Internet label, for the day that
these give way to something more appropriate.

Reproducible: Always

Steps to Reproduce:
-> PSM
Assignee: asa → ssaux
Component: Browser-General → Client Library
Product: Browser → PSM
QA Contact: asa → junruh
Version: Trunk → unspecified
The user can also click on the lock icon for company info, or click on View,
Page-Info for the same information concerning the server certificate.
The fact that users are not asked to accept temporarily or permanently a new
Certificate Authority when visiting an honest secure web site means that the
business has already been checked out and trusted by a built-in CA.
Setting to enhancement, ccing people for comments, and suggesting the bug
eventually be marked either works for me or invalid.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Target Milestone: --- → Future
Version: unspecified → 2.4
Mainly my point is that the site's SSL identity (the logical name of the
organization, not the DNS domain name) is every bit as important as the URL in
the Location bar, but it isn't treated that way by current UI practices.  Even
though it's a major change from what browsers do today, I think changing the way
the SSL identity is exposed to users is worth considering.  This is definitely
an enhancement, and arguably low-priority.  I just wanted to suggest it to get
people thinking about this sort of thing.

If someone wants to be sure they're on the eBay site, they should be able to do
a *cursory* check (the operative word being 'cursory') that the organization
they've connected to is eBay and not just someone that happens to share a
similar-seeming DNS domain name in the URL.
> A user hitting an SSL
> "www.ebay.com" site has a pretty good idea that they're on eBay.  But what about
> a site like "www.ebayupdates.com" (run by scam artists)?  If the scammer were to
> use SSL, it'd look even more legitimate, and users might think that since it's
> protected, and has eBay in the name, surely it's eBay they're hitting, right?

We have the problem right there. Each organization should have exactly one
domain, and always use that and only that. Users should distrust everything else.

That's why I think that abc-news.com and abc.de is a very bad idea. it should be
news.abc.com and de.abc.com, like Yahoo does it. Otherwise, somebody else comes
with abc-weather.com or abc.ru, and the only defense is trademark law, if
applicable at all (see .ru). Same with db.de vs. deutsche-bank.de vs.
deutsche-bank-24.de. Stick to one domain.

I don't see that SSL helps at all here. If I started a company "eBayHelpers", I
would get a certificate with that name, and ebay would have to sue me, with
questionable outcome. Same problem as with ebayhelpers.com. I cannot get
helpers.ebay.com, though.

> instead of just assuming that the name (or part of that
> name) of the domain equals the name of the organization.

Next problem. If you look for a company you know from real life, you should
search on Google for it (PageRank), not guess domain names. Once you found that,
bookmark or remember the right domain name.

If you get to know a company from a web link, you have your right domain name
right there. Just keep it and insist on using it.

> Since so many logical entities have registered so many different 2nd-level
> DNS domains, it's impractical for people to know which "similar" domains
> or are not under the control of that logical entity.

Right, that's the fault of the relevant companies, and their own problem. We
should educate them to use one domain only for the whole organization.


For these reasons, I think that SSL is only useful to determine that the
datastream most likely came from and goes only to the one owning the domain. It
is for me an addition to the DNS.
"most likely", because CAs probably make errors, and the U.S. government
controls the CAs, so it can create fake certificates (accepted by my browser)
and be a man in the middle.

Granted, DNS is not secure either, but most of the DNS exploits are made
impossible in connection with SSL. (Not the SSL problems mentioned in the last
paragraph, though.)


Suggesting WONTFIX. Nice suggestion, doesn't work in practice.
David, I agree with your comment 3.  The cert represents a binding of 
the key to a name, the subject name in the cert, as certified by a particular
entity (the issuer CA).  The user should be able to see, readily and easily
a) what name the key is bound to, and b) who says so (who is the CA).  

This is a UI issue much bigger than PSM though.  It's a browser window
real estate issue.  
Regarding comment #4, I completely agree with what you're saying is the "real
problem" here (and, indeed, I've written something to this effect at
http://fastolfe.net/features/directory-service/), but solving *this* problem is
something that is going to take decades, not just years.  We are too entrenched
in a DNS-oriented world to escape.  But by reducing the user's dependence on
URL's and DNS hostnames, we also happen to reduce the value of all these
bazillion second-level domains that companies feel they have to own.

I also intimated in my first two comments that this is a first step in this
direction.  We must first begin to wean the user off of DNS hostnames and URL's.

SSL does help in that web sites use SSL certificates to associate a real-world
identity with their site.  I don't have to guess that a DNS domain with the word
"ebay" in it is or is not affiliated with eBay.  But any eBay site I connect to
should be able to prove (through a certificate) that they are eBay.  Even if
someone grabs a certificate claiming something eBay-like, it should still be
readily apparent and provable that they are not really eBay.  That isn't really
possible today without investigation.  Keep in mind also that CA's like VeriSign
actually *verify* that you are the company you say you are.  You can't just make
up a company name confusingly similar to an existing one.

The way I see it, lots of sites have SSL certificates, but all browsers do is
verify that the SSL certificate matches the host.  We have the ability through
these certificates to validate a real-world identity against a host, but we're
currently all but completely ignoring this aspect.  It seems like an awful waste.

Lastly, with respects to search engines, there is no search engine currently
qualified to guarantee a reliable link between your company's name or one of
their trade marks and your company's Internet domain.  If you have a large
company with lots of links to your site, maybe, but even then you're relying on
the search engine to have a good ranking system, and you're hoping that a
competitor doesn't find some way of elevating their own rank in the search
results to put their site before yours.  We presently lack an online database
suitable as a directory to link real-world names with DNS domains.  I think
that's the direction we need to move towards, but until then, all we have is
DNS, so we might as well *try* to make the best of it for now.
To last comment: This won't help, if you still display the URLbar, because the
user will see "www.microsoft.com" in the URLbar and hostname "234.567.891.234",
and will think "Microsoft, OK".

After I wrote comment 4, this bug's idea stuck in my head, and I started to
agree with it. In fact, I would go one drastical step further, namely completely
removing the URLbar. I filed bug 228524 about this, to keep this bug free from
that discussion.
I implemented this for bug 228524.
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
For those that believe the lock icon is enough, this article was interesting:
http://news.netcraft.com/archives/2004/03/08/ssls_credibility_as_phishing_defense_is_tested.html

"[Security] professionals are focused on the limitations of SSL in the wake of a
recent scam targeting Earthlink users (mentioned near the bottom of this story)
which employed an SSL certificate so the bogus page displayed the lock icon. In
this case, the certificate appeared legit because it matched the URL of the fake
page mimicking the Earthlink web site, but had no connection to Earthlink.
Visitors would only detect the deception if they reviewed the certificate."
Mass change "Future" target milestone to "--" on bugs that now are assigned to
nobody.  Those targets reflected the prioritization of past PSM management.
Many of these should be marked invalid or wontfix, I think.
Target Milestone: Future → ---
Here's what I suggest for an SSL connection in order to address phishing:

  * the identity of the site should be presented in the chrome
    (by which I mean it can't be overwritten by some trick or other).

  * a count of the number of visits to this particular SSL cert
    is also displayed.  This way, today your BoA shows 100, and 101
    tomorrow.  You could also display things like time of last access.

  * Along side the counting of the cached cert, things like 'petnames'
    have been suggested.  This information is unknown to any phisher,
    so in the chrome where it says "my retail banking account" for the
    right BoA cert, the phisher would be challenged to invent something
    there.  Amir and Ahmad are working on a much more sophisticated 'logo'
    fix to Firebird that allows user-based authentication by graphics.

  * Along side the identity of the site the CA should also be listed.
    This is because the SSL PKI has an architectural feature/bug whereby
    all CAs are considered equally good, which means that anyone can get
    any cert by tricking just one CA.  As there are hundreds, and as they
    operate across the world, this seems of only minor challenge.
    (So, where it says for this page bugzilla.mozilla.org it should also
    say Thwarte).
  * All of the above should be done for self-signed certs as well.  One
    important way to get more people using SSL is to encourage use of
    self-signed certs, which are currently discouraged.  Yet their
    security properties are perfect for anti-phishing measures, as the
    prior relationship between the user and the site is what counts, not
    what any CA says.

The important thing about phishing is that the user and the browser and the site
already have a very useful relationship: multiple visits hopefully based on a
cert.  To stop the browser/user being tricked into going to the wrong site, the
browser should display more context information about the history of the
relationship.  Hence, counts, petnames, logos, site identities and CA names, all
of which can be done by caching the cert and recording the info over time.
  
iang
Product: PSM → Core
Showing the cert's organization name in the browser chrome is useless since some trusted CA's (cough Usertrust cough) do nothing to validate the stuff in the cert except check that the admin email address works, and place a robo-voice call to an arbitrary attacker-supplied phone number.  Nothing stops me from registering ebaygoodies.com, generating a CSR with "Ebay goodies special offers" in the organization field, getting a UTN certificate and installing it in a server.  Comment #4 is correct, the only solution in the present framework is for vendors to stop being so cutesy with multiple domains, and stick with just one.  Bug should be closed as invalid.
Paul Rubin, have you really seen that? Do you have a live example?

The sites I have seen that is using usertrust, cacert.org (without enough trust) or some other low quality verification certificate is either leaving the organization field empty or just repeat the domain name, so it is easy to see that the organization is not verified when using this feature in Opera or checking the certificate in other browsers.
(In reply to comment #14)
> Showing the cert's organization name in the browser chrome is useless since
> some trusted CA's (cough Usertrust cough) do nothing to validate the stuff in
> the cert except check that the admin email address works, and place a
> robo-voice call to an arbitrary attacker-supplied phone number.  Nothing stops
> me from registering ebaygoodies.com, generating a CSR with "Ebay goodies
> special offers" in the organization field, getting a UTN certificate and
> installing it in a server.

Surely the certificates of such untrustworthy CAs should be removed from NSS altogether.
QA Contact: junruh → ui
Version: psm2.4 → 1.0 Branch
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.