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)

Product:
Core
Component:
Networking
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: olaf, Assigned: darin.moz)

Details

Attachments

(1 file)

suggested patch
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
verified wontfix
Status: RESOLVED → VERIFIED
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.
Attached patch suggested patch — — Splinter Review 
to fix it, very simple
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.


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.
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 → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Any thoughts on this one, darin?
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.
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.
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.
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.

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


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.
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.
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?
william: mozilla uses nsIURI::Equals to compare two URLs... no one should be
doing raw URL string compares.
*** Bug 152016 has been marked as a duplicate of this bug. ***
-> 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.
-> darin
Assignee: dougt → darin
Target Milestone: --- → Future
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
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).
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
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: