Closed
Bug 228296
Opened 22 years ago
Closed 20 years ago
Include "Company Name" in status bar for URLs w/FQDNs, esp. https urls
Categories
(Core :: Security, enhancement)
Core
Security
Tracking
()
RESOLVED
EXPIRED
People
(Reporter: Brian.Cain, Assigned: security-bugs)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
I believe it's a well-documented "issue" that one could exploit the nature of
URLs by making the user field (prot://user@fqdn/) contain something that
resembled a hostname, followed by lots of non-slash ('/') garbage characters
(enough to cause the actual hostname to be concealed).
Mozilla/Phoenix's answer to this "issue" may be that the user needs to be more
careful. In the absence of that stance, I recommend that the company name
field(s), retrieved from an SSL/TLS cert [cn/o/ou], or a DNS (or whois?) record,
be placed in the status bar, adjacent to the all-familiar padlock icon. I know
that the information in a website's cert is available on demand, but I think in
the name of security it should always be pushed to the user (but perhaps
configurable). I know that "transferring data from <fqdn>" is displayed during
loading of a page, but the FQDN may not make the company name obvious, and the
actual loading time is often very brief relative to the time spent
reading/interacting with a web page.
I trust my local DNS server, and I trust the root certs in my browser, so I
should be able to trust the "Company Name" (or similar) text that would
accompany the records derived from those repositories. I cannot sufficiently
trust that a URL will accurately represent the organization with which I am
actually communicating.
I just noticed that the icon is absent (not unlocked as it appeared in versions
past) for http urls, but I believe it's clear which component I'm referring to
when I say "status bar".
Reproducible: Always
Steps to Reproduce:
1. Load a webpage from a remote host (http|https).
Actual Results:
The webpage is displayed.
Expected Results:
Mozilla should have offered the actual company name of the entity with which I
was communicating, so that I might verify it.
I suppose fear of a "false negative" impression of impropriety might shelve this
RFE. Domains that have been registered with a parent company or subsidiary's
name, or organizations that change their name or brand might seem to not be who
they claim to be. I simply suggest that the option be present to enable
(preferably disabling this feature should be optional) the feature I've described.
Comment 1•22 years ago
|
||
This sounds like a front-end issue that needs to be solved in the front ends,
not a security back end issue... but your call, caillon.
Comment 2•22 years ago
|
||
dupe of bug 228296 ? (I think that one is newer, but it was by the module-owner,
and has lot of ideas). See also bug 184881.
Comment 3•20 years ago
|
||
This is an automated message, with ID "auto-resolve01".
This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.
While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.
The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 4•20 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•