Closed
Bug 38998
Opened 24 years ago
Closed 19 years ago
URL: hostname case should be preserved (currently lower cased).
Categories
(Core :: Networking, defect, P3)
Core
Networking
Tracking
()
VERIFIED
WONTFIX
Future
People
(Reporter: olaf, Assigned: darin.moz)
Details
Attachments
(1 file)
659 bytes,
patch
|
Details | Diff | Splinter Review |
I have a hacked proxy which uses special hostnames written in all uppercase. (See http://sites.inka.de/~bigred/devel/squid-filter.html if curious.) Mozilla now smashes them to lower case, breaking that scheme and potentially leading to more unnecessary surprises.
hostnames have to case insensitive per the spec. suggestion- use a better scheme.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
I dont think so. for RFC1034, there is no case insensitive in dns. So URL can not be changed into all lowcase! I think it should be reopened again.
some old system is case sensetive about URL's hostname. It can work well using netscape 4.X, but can not using mozilla09X.
dmose, please take a look at this bug. due to URL lowcase,some sun's internal site can not be accessed. I have to add my patch, then can I access these site. so it is an p2 bug in sun's bugtraq for ns621.
Comment 7•23 years ago
|
||
Lower-casing domain names improves Mozilla's security by making it much harder to spoof domain names. For example, paypaI.com looks a lot like paypal.com. Many Internet Explorer users were tricked by the paypai.com scam (see http://zdnet.com.com/2100-11-522401.html?legacy=zdnn&chkpt=zdhpnews01). Very few sites rely on the case of the hostname, so let's not remove this feature.
Comment 8•23 years ago
|
||
Reopening; this was closed for the wrong reason. The spec (RFC 1034, section 3.1) says that labels should be compared in a case-insensitive fashion, but that the case of the labels themselves should be preserved. Jesse has an interesting point, in that this may discourage some attacks. However, I think the claim that this sort of attack will be "much harder" isn't very realistic. Other opinions?
Status: VERIFIED → UNCONFIRMED
Resolution: WONTFIX → ---
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 9•23 years ago
|
||
host names are case insensitive. Therefore, aaa == AAA, and so it is invalid to differentiate between them when deciding what host to go to. Searching that part for 'case' doesn't turn up anything in paticular - can you point to which part says that it does something different? When comparing for the filters, the host/scheme comparisons MUST be case-insensitive. Re jesse's issue, I'm not sure. Case preserving at the UI would probably lead to less surprises, but stuff like the url bar autocomplete should case insensitive for the scheme://host/ portion, I think. In practice, that may lead to perf issues, and if it does I don't think its work worrying abhout it
Opinion: let's not borrow more 4.x-mismatch trouble. Compare case-insensitively, and leave the case as it is. It's even the standards-way, by dmose's reading.
Comment 11•23 years ago
|
||
Any thoughts on this one, darin?
Assignee | ||
Comment 12•23 years ago
|
||
we lowercase the hostname so we can generate a canonical URL. this is important because there are parts of our code that index tables w/ URLs and use case sensitive compares. afterall, the path component is case sensitive. this bug needs to be blocked by bugs to fix such usages to use nsIURI's as keys instead of nsIURI::spec's.
Comment 13•23 years ago
|
||
Sorry, I am a little confused with the status of this bug. How should we proceed with this bug? Are we saying that there are usages which rely on it being case insensitive? If so, do we already have a bug filed against that? Do we have to check in all the related fixes together? Or can we simply check this in, and fix others. Thanks.
Comment 14•23 years ago
|
||
There are two issues - what we send over the network, and what we present to the user. We can send whatever case we like over the network, and anyone relying on the case of the hostname for whatever reason is broken - see the RFCs I cited. What we present to the user should probably be what they entered, although see jesse's comments. Once we've decided what to do, fixing that relies on making the changes darin mentions in comment 12, I suppose. See my comment 9 - where do you get the statement that "there is no case insensitive in dns"? The HTTP spec is very clear about what is and what isn't case insensitive.
Comment 15•23 years ago
|
||
let us think about url like that. 1. when user input url into mozilla input box, such as www.Yahoo.com, mozilla should reserve its original one in it, not change it to www.yahoo.com in the url input box.it may confuse user. 2. when some cgi program return server name, it also return original one. 3. maybe in the internal sourcecode, it can be lowcased.
Comment 16•23 years ago
|
||
>let us think about url like that. >1. when user input url into mozilla input box, such as www.Yahoo.com, > mozilla should reserve its original one in it, not change it to 0 >www.yahoo.com in the url input box.it may confuse user. Right; thats what happens now >2. when some cgi program return server name, it also return original one. > I don't understand that. >3. maybe in the internal sourcecode, it can be lowcased. Why? If we changed this, we'd have to update the url parser, change everyone who compares hostnames to use case insensitive parsing (which is more expensive) Places which use host:port as a key would have to lowercase before putting it in there, and then keep an additional copy of the 'real' case.
Comment 17•23 years ago
|
||
maybe there is one simple way to resolve it. just keep two url variable in source code. one is for reserve original one,it is for display. another one is lowcased, for internal use, just like now.
Assignee | ||
Comment 18•23 years ago
|
||
i understand that it would be nice to preserve the case of the hostname and that we could even do so (not without carefully reviewing all code that touches hostnames of course!), but jesse's comment #7 scares me. however, w/ support for iDNS, we'll have spoofing problems up the wazzoo.. thanks the great variety of similar characters (e.g., wide jp chars vs. narros jp chars) present in unicode. so i guess you could argue against preserving lowercase for the purposes of enhanced security. or maybe the IDNA spec handles this problem in the canonicalization step. cc'ing nhotta and william tan.
Assignee | ||
Comment 19•23 years ago
|
||
jerry: we don't want to hold two copies of the hostname if we can help it. either we stick with tolowercase or we accept strcasecmp.
Comment 20•23 years ago
|
||
I think IDNA doesn't apply here, in section 4.1 of the draft, the ToASCII operation skips Nameprep (where canonicalisation is performed). http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt Darin: How is strcasecmp gonna help if the path names in URLs are case sensitive?
Assignee | ||
Comment 21•23 years ago
|
||
william: mozilla uses nsIURI::Equals to compare two URLs... no one should be doing raw URL string compares.
Comment 22•22 years ago
|
||
*** Bug 152016 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
-> defaults, which are totally stale. (this is all/all right?)
Assignee: gagan → dougt
OS: Linux → All
QA Contact: tever → benc
Hardware: PC → All
Summary: Should not case-smash host names in URLs → URL: hosntame case should be preserved.
Assignee | ||
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 25•19 years ago
|
||
IMO, this is WONTFIX; we've lived with it for ages and no-one seems to mind, and lower-casing does reduce the scope for homograph attacks. Particularly, it improves the situation for 1/I and 0/O, which probably can't be fixed by restricting DNS registrations for historical reasons. Gerv
Comment 26•19 years ago
|
||
dmose mentioned RFC 1034, which says: "When you receive a domain name or label, you should preserve its case. The rationale for this choice is that we may someday need to add full binary domain names for new services; existing services would not be changed." While this is "should" rather than SHOULD (which hadn't been invented yet), I think we are justified in not following this recommendation for display, because displaying it to the user as lowercase does not break the rationale given. The fact that the rationale (allowing both lower and upper forms, distinctively) is extremely unlikely ever to be implemented is relevant, but secondary. Gerv
Summary: URL: hosntame case should be preserved. → URL: hostname case should be preserved (currently lower cased).
Assignee | ||
Comment 27•19 years ago
|
||
WONTFIX: canonicalizing hostnames to lowercase it a good anti spoofing measure, and it also enables us to get away with using strcmp to compare URL strings in some cases (hello mork!). we can't afford to change this behavior.
Status: NEW → RESOLVED
Closed: 24 years ago → 19 years ago
Resolution: --- → WONTFIX
Comment 28•19 years ago
|
||
V/wontfix. I think the string compare reason is partical and faithful to the specifications. I don't think this should be done because of (or considered beneficial to the problem of) spoofing. The cases are few, probably font related, and certainly limited (this would not prevent the same attack in non-english character sets. We'd be kidding ourselves if we thought this was anti-spoof/phishing.
Status: RESOLVED → VERIFIED
Comment 29•19 years ago
|
||
An observation: while the number of homographs it helps with may be few, the current ASCII nature of DNS means that they are the critical ones, and ones that (for legacy reasons) can't be dealt with by problems like homographic domain bundling. Gerv
You need to log in
before you can comment on or make changes to this bug.
Description
•