393973 - password manager treats domains with trailing dot as 2nd domain

Status: REOPENED

(Toolkit :: Password Manager, defect, P5)

Description

[Martin Sch]

A dot at the end of a host name means that this host name is absolute, i.e. remains as it is. Without a dot, the host name can be expanded with a domain.
Let's assume I sit at the company example.com. In my browser, I enter the url "http://stories/", then the tcpip stack looks for http://stories.example.com/
But if I enter "http://stories./", then the system tries to resolv the hostname stories.

The password manager treats http://stories.example.com/ and http://stories.example.com./ as two different domains, which is incorrect!

Comment 1

[Peter Weilbacher]

I am not sure I follow your preamble about the TCP/IP stack (trying to reproduce without a browser with nslookup instead I found that "nslookup www" works while "nslookup www." does not) but I do see the problem with the password manager and it is seems to be a cross-platform issue:

Logging in and saving the login info at www.gmx.net and www.gmx.net. results in two entries in the password manager (SeaMonkey trunk build on Linux). The same happens for https://freemail.web.de. and https://freemail.web.de but for the version with the trailing dot I get a warning that the site certificate belongs to another site. The same double password manager entry also happens when I log in at https://freemail.web.de/msg/logonfailed.htm instead of https://freemail.web.de

Comment 2

[Martin Sch]

See http://tools.ietf.org/html/rfc1035

"Domain names that end in a dot are called
absolute, and are taken as complete.  Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin"

Comment 3

[Martin Sch]

What is bug 396316 about?

Comment 4

[Justin Dolske [:Dolske]]

I changed my mind and removed the dependancy on 396316; it touched on a vaguely similar issue but isn't really related.

Anyway...

I don't think this issue is fixable at the password manager level, as you'd have to dig around in DNS to know that |foo| and |foo.| are the same. I'm not  sure if that info is available in a default DNS reply, or if it takes more work to get at. It seems like this kind of issue would be like to affect other areas of the browser as well. Perhaps the networking layer should internally redirect requests for a non-FQDN to the FQDN, so that document.location could always be assumed to be fully qualified?

Alternatively, I'm also thinking this may just be a WONTFIX, as there are already other ways to access the same host in ways that password manager can't be sure are the same. EG, "www.site.com", "site.com", "redirect.site.com", "129.1.2.3", different protocol, etc.

Comment 5

[Justin Dolske [:Dolske]]

WONTFIX for the reasons in comment #4.

Domains with a trailing dot seem fairly rare, so I don't think this is even likely to be a real issue for most people. [It wasn't for me for the years I worked behind a proxy.]

Comment 6

[Martin Sch]

The trailing dot does not belong to the domain. It is entered by the user.

I prefer links of the kind "https://my-secure-bank.com./" because this is the correct way the thing works.

Would I enter "https://my-secure-bank.com/" and the network admin in my company would set up a server named my-secure-bank.com, I would end up at "https://my-secure-bank.com.mycompany.com/"!

You see the difference?

Comment 7

[Max Kalashnikov]

(In reply to comment #6)
> The trailing dot does not belong to the domain. It is entered by the user.

This may be a bit more widespread a problem than just in Password Manager:

Try, for example, in FF3 to go to https://www.starone.org./ and you should get a certificate warning. However, it's impossible to add an exception because the cert is correctly recognized as valid.

> I prefer links of the kind "https://my-secure-bank.com./" because this is the
> correct way the thing works.

This turns out not to be the case. I would suggest you examine http://tools.ietf.org/html/rfc3986#section-3.2.2 and pay particular attention to the phrase "ending with an alphanumeric character"

Comment 8

[Arthur]

(In reply to comment #7)
> (In reply to comment #6)
> > I prefer links of the kind "https://my-secure-bank.com./" because this is the
> > correct way the thing works.
> 
> This turns out not to be the case. I would suggest you examine
> http://tools.ietf.org/html/rfc3986#section-3.2.2 and pay particular attention
> to the phrase "ending with an alphanumeric character"

You should finish that quote correctly:

[...]ending with an alphanumeric character and possibly also containing "-" characters.  The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.[...]

Comment 9

[Anne (:annevk)]

As discussed in bug 134402 and elsewhere, these can end up being completely different websites. I'm not sure we should treat them as equivalent for password purposes. Maybe as some kind of opt-in suggestion...