Closed Bug 364667 Opened 17 years ago Closed 16 years ago

Tolerate mismatch between certificate host and actual host if the difference is only "www."

Categories

(Core :: Security: PSM, enhancement)

Product:
Core
Component:
Security: PSM
Platform:
PowerPC
All
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jruderman, Assigned: KaiE)

References

(
URL
)

Details

Steps to reproduce:
1. Go to https://paypal.com/.

Result: security dialog warning me that I'm connecting to "paypal.com" but the cert is for "www.paypal.com".

Expected: ignore the mismatch, or treat the mismatch as a hint to redirect to "www.".
CC'ing more people on this enhancement proposal.

I think we should not ignore the mismatch.

If the web site administrators were smart enough to configure paypal.com to be an alias for www.paypal.com, they should get a certificate that is valid for both hostnames.

Regarding your automatic redirect proposal:

How can we be sure the redirect is indeed pointing to the same site? I think there should be some DNS querying and verification involved to ensure they are really the same.

But in your example that would fail, because DNS gives me different addresses for paypal.com and www.paypal.com

Another question, what should happen if someone plays with a local test configuration, where there is a domain.com DNS entry, the user currently has a www.domain.com cert, but there is no www.domain.com DNS entry? I agree this is a constructed scenario, but having your proposal implemented, it would be impossible to connect to domain.com at all.


Web site admins are able to prevent this kind of error message with the right use of hostnames and certs.

I'm proposing to set this to WONTFIX, but I'm curious to hear more opinions.
OS: Mac OS X 10.4 → All
(In reply to comment #1)

> If the web site administrators were smart enough to configure paypal.com to be
> an alias for www.paypal.com, they should get a certificate that is valid for
> both hostnames.

Right.  But apparently that isn't true for Paypal ;)

> How can we be sure the redirect is indeed pointing to the same site? I think
> there should be some DNS querying and verification involved to ensure they are
> really the same.

I'm just assuming that www.foo and foo are owned by the same people.

> Another question, what should happen if someone plays with a local test
> configuration, where there is a domain.com DNS entry, the user currently has a
> www.domain.com cert, but there is no www.domain.com DNS entry? I agree this is
> a constructed scenario, but having your proposal implemented, it would be
> impossible to connect to domain.com at all.

It should be impossible to connect anyway for real mismatches; see bug 327181.

One disadvantage to "fixing" this bug is that web developers testing in Firefox would not notice the error, while visitors using other browsers (such as IE) would get errors.
QA Contact: psm
How about making the error page (to be added in bug 327181) contain some text like "The certificate is valid for https://www.paypal.com/" in the "www-only mismatch" case?  Then users will have an easy way to get to the site (click the link) but web developers will still notice the screw-up.
See also bug 398949.
Blocks: https-error-pages
Fixed (for a slightly wider range of cases) in bug 402210.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Should this have fixed https://mozilla.com/ so that it works? I.e. should we be making certificates for *.foo.tld match foo.tld?
(In reply to comment #9)
> Should this have fixed https://mozilla.com/ so that it works? I.e. should we be
> making certificates for *.foo.tld match foo.tld?

No, and perhaps: see bug 432491 :)
Um, seems to me that if the answer to the latter is "perhaps", the answer to the former is also "perhaps" by definition. Thanks for the but #.
The patch that landed was not expected to fix that bug, so I replied no to "should this have fixed the bug".
Gavin: ah, okay.

Jesse: looking at this bug's Summary and seeing it marked FIXED, I thought the tolerance thing had been implemented. After testing, seeing that it doesn't work and actually reading the comments here, I see that it hasn't at all. Can we have the issue as reported fixed or wontfixed? I personally think that - with the DNS lookup - it's a good idea.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry, I was confused when I marked this as fixed.  Bug 402210 is about showing a hyperlink in the error page, whereas this bug is about skipping the error page.
Given that Bug 402210 is completed, I think this RFE should be WONTFIX.
I agree on the wontfix. bug 402210 is probably as close as we get to this, and for the minor inconvenience it ameliorates it's not worth delving into extra DNS queries and the security risks of getting it wrong.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
I would like to see this bug fixed.  Another example would be https://www.411.com and http://411.com.  Firefox should be built for the end-user, not for the webmaster, meaning that the user should be able to access any page without worrying about Firefox blocking it because a poor webmaster runs a SSL webserver.

Please change to minor fix in a future version.
Site owners should include all domain names which are supposed to be secured in the SAN extensions as DNS entries. Anything not included in the certificate isn't meant to be covered, either by design or carelessness of the site admin.
I disagree with the wontfix.  The problem is that certificates are good for only one domain, and that some webservers (old versions of IIS, for example) can only use one certificate per machine.  Another issue is with "bad" links in websites (including or missing initial"www").

There's a bigger security risk of users getting used to ignoring the bad certificate dialog then implementing an option for a sane and automatically verifiable exception.
>  The problem is that certificates are good for only one domain,

Absolutely false.
You need to log in before you can comment on or make changes to this bug.