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)

enhancement
Not set
normal

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.
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.
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.
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/
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.