432491 - Hyperlinked ssl error page not useful for wildcards

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect)

Description

[Johnathan Nightingale [:johnath]]

IF a site uses a wildcard cert ("*.example.com")...
AND the cert is not valid for the domain itself ("example.com")...
AND the user attempts to https://example.com/ directly...

we will show an ssl error for the domain name mismatch.  In some cases, bug 402210 will cause the error page to be hyperlinked, which means that we will try to hyperlink "*.example.com" which doesn't work very well, since "*.example.com" doesn't resolve to anything.

We should probably special case that, since it's a known pattern in certs, and either:

a) Not hyperlink at all in that case
b) Hyperlink to 'www' instead, since that's the most-likely-to-be-useful link.

An example of a site with this problem is (ahem): https://mozilla.com/

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Of the two options, I'd rather we s/*/www/ in these cases, since then we're doing something useful for the user.

Comment 3

[Johnathan Nightingale [:johnath]]

Attachment: replace /^\*/ with "www"

(In reply to comment #1)
> Of the two options, I'd rather we s/*/www/ in these cases, since then we're
> doing something useful for the user.

I agree.  Attached one-liner to make the substitution.  Tagging gavin for review since he received biesi's punted review on the original in bug 402210,  but this isn't a blocker, so I fully expect it to be low on the priority list.

Comment 4

[Kai Engert (:KaiE:)]

I would vote for for (a).

Using "www" is a blind guess, which can result in an invalid link, too.
If the server uses a wildcard cert, it says the destination is operating many servers, and we don't know where the user intended to go.

Does it really help to enable a user to go "somewhere"?

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 319644 [details] [diff] [review]
replace /^\*/ with "www"

>Index: docshell/resources/content/netError.xhtml

>+        // If okHost is a wildcard domain ("*.example.com") let's
>+        // use "www" instead.  "*.example.com" isn't going to
>+        // get anyone anywhere useful. bug 432491
>+        okHost = okHost.replace(/^\*/, "www");

Use /^\*\./ to be safe?

nit: also don't add unneeded whitespace on that blank line.

Comment 6

[Kai Engert (:KaiE:)]

Look at this page for example:
http://support.microsoft.com/kb/258858
search for "accepted wildcard examples"

Your patch will still generate a nonworking hyperlink for wildcards like w*.example.com

I propose: if * found in name, do not hyperlink

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> Your patch will still generate a nonworking hyperlink for wildcards like
> w*.example.com

I was told that w*.example.com is not a valid wildcard. Do CAs actually issue such certs?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Beware of the MS KB article cited in comment 6. 
Some of the "Accepted Wildcard examples" don't work in IE 
and don't follow the RFC.

I have a few questions about the new links that now sometimes appear in 
host name mismatch pages.  

Q1) If I follow a link to (say) 
  https://example.com/some_big_long_complicated_URI
and get a host name mismatch page with a hyperlink, will that hyperlink be to 
  https://www.example.com/
or will be it to 
  https://www.example.com/some_big_long_complicated_URI 
?

Q2) If I submit a form that POSTS to that same URL given above, 
will the link rePOST the data to that corresponding www. URL?  

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> Q1) If I follow a link to (say) 
>   https://example.com/some_big_long_complicated_URI
> and get a host name mismatch page with a hyperlink, will that hyperlink be to 
>   https://www.example.com/
> or will be it to 
>   https://www.example.com/some_big_long_complicated_URI 
> ?

The former.

> Q2) If I submit a form that POSTS to that same URL given above, 
> will the link rePOST the data to that corresponding www. URL?  

No.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 7,
Gavin, there is much discussion about acceptable wildcard forms in 
bug 159483.  See especially bug 159483 comment 3 and bug 159483 comment 9,
both of which quote brief passages from the relevant RFCs.  

w*.example.com fits the specification and examples in RFC 2818.
RFC gives f*.com as an example. (:-/)  

As to actual CA practice, I don't know of any CAs that offer wildcards
in any form other than *.domain

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Just to be clear, the current patch only affects wildcards with a leading "*", so "w*.example.com" will not be affected. "*foo.example.com" is currently affected by the patch (hyperlink becomes "wwwfoo.example.com"), but will not be affected if Johnathan makes the change I suggested.

Comment 12

[Jonathan Watt [:jwatt]]

Can someone explain why a certificate that is valid for *.foo.tld should not be accepted for foo.tld? It seems to be a really common mistake.

Comment 13

[Johnathan Nightingale [:johnath]]

Attachment: With review comments

(In reply to comment #5)
> (From update of attachment 319644 [details] [diff] [review])
> >Index: docshell/resources/content/netError.xhtml
> 
> >+        // If okHost is a wildcard domain ("*.example.com") let's
> >+        // use "www" instead.  "*.example.com" isn't going to
> >+        // get anyone anywhere useful. bug 432491
> >+        okHost = okHost.replace(/^\*/, "www");
> 
> Use /^\*\./ to be safe?

Done (with the obvious "www"->"www." change as well.

> nit: also don't add unneeded whitespace on that blank line.

Done.

(In reply to comment #11)
> Just to be clear, the current patch only affects wildcards with a leading "*",
> so "w*.example.com" will not be affected. "*foo.example.com" is currently
> affected by the patch (hyperlink becomes "wwwfoo.example.com"), but will not be
> affected if Johnathan makes the change I suggested.

Right, this will only "fix" leading wildcards.  Sites using foo*bar.*.baz certificates can wallow in their edge-case-itude.

(In reply to comment #6)
> I propose: if * found in name, do not hyperlink

I hear what you're saying, Kai, that hyperlinking here may still lead them nowhere, but "www" does enjoy sort of special status on the web as a "substantially more likely than most" target for a given domain.  I feel like the assistance we offer much of the time by hyperlinking outweighs the concern that, in the other cases, we will continue to be unhelpful.

(In reply to comment #12)
> Can someone explain why a certificate that is valid for *.foo.tld should not be
> accepted for foo.tld? It seems to be a really common mistake.

Because the CA didn't issue that certificate.  We have to trust what the CAs say and this cert is not listing, e.g., "mozilla.com" as one of the things that is verified.  Stupid, I agree, but certificate holders should take it up with their CA if they think that they aren't getting the product they bought.  We don't want to be in the business of second-guessing the CN/subjectAltName fields, imo.

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 319779 [details] [diff] [review]
With review comments

a1.9=beltzner

Comment 15

[Johnathan Nightingale [:johnath]]

Checking in docshell/resources/content/netError.xhtml;
/cvsroot/mozilla/docshell/resources/content/netError.xhtml,v  <--  netError.xhtml
new revision: 1.31; previous revision: 1.30
done