276533 - Certificate Mismatch Override Indicator

Status: RESOLVED DUPLICATE of bug 1201437

(Core Graveyard :: Security: UI, enhancement)

Description

[David E. Ross]

A common problem with viewing secure Web sites is that the site domain name
might change without a new site certificate being issued.  For example, at the
time this bug report is being written, <www.londonstockexchange.co.uk> is using
a certificate originally issued for <www.londonstockexchange.com>.  

If the user overrides the mismatch and uses the certificate, the "lock" icon
should indicate that override.  

Currently, the lock icon can have one of three appearances: a closed lock (page
is secure per certificate), an open lock (page is not secure), and a closed lock
with a diagonal red line (at least one element in an otherwise secure page is
not secure).  I propose a fourth appearance: a closed lock with a red question
mark, meaning the page is being treated as secure because of a user override of
a mismatch.

Comment 1

[David E. Ross]

On further evaluation, I also suggest that the user have the ability to tell the
browser to "forget" that there is a mismatch override.  Currently, when a user
overrides a certificate mismatch, that choice remains in effect throughout the
current browser session.  

Comment 2

[Jean-Marc Desperrier]

*** Bug 274700 has been marked as a duplicate of this bug. ***

Comment 3

[Kai Engert (:KaiE:)]

I propose this bug should be a WONTFIX.

I disagree with the request to allow a "mismatch override allowance whitelist".

Two "emotional" arguments first:

- Such a whitelist increases the list of possible attacks to the application (an
attack would only require to manipulate the stored dynamic whitelist).

- It makes it more confusing for the user why a site is trusted, although by
inspecting the domain name is different.

But my most important argument is based on facts: Your request is not required,
because a web site's webmaster has all power in hand fix the mismatch on the
server side.

Scenario 1: The web site switches to a new domain, no longer using the old one.
The administrator should simply get a new cert.

Scenario 2: The web site would like to use multiple domains. If that's required,
the web site operator should not only afford the additional domain costs, but
also the costs for additional IP adresses. By having a separate IP address for
each domain, there can be a web server configuration with separate SSL
certificate for each domain.

Another possibility for scen. 2: (though I'm not absolutely sure this will work
in your example) is to use a "multiple common name" certificate. I know for sure
it works with "wildcard certs" like "*.domain.com", and I also have seen certs
like "(a|b).domain.com", so I guess it should be possible to issue certs like
"www.londonstockexchange.(com|co.uk)".

Comment 4

[David E. Ross]

Reference comment #3:

The current implementation is unsafe.  It allows a certificate domain mismatch
to be overridden by the user.  Then, in the same session, it allows the same
override to occur again without the user being reminded of the situation.  

The requested change would at least provide the user with an ongoing indicator
that a certificate domain mismatch has been overridden and (per comment #1)
allows the user to cancel further use of an override.  The only alternatives to
improve security would be either:

1. Prohibit any override of a certificate domain mismatch (the extreme solution).  

2.  Automatically force the browser to "forget" an override after the current
use ends (the annoying solution, since it brings up the popup for a new override
for each affected secure session).  

If there is general strong opposition to the RFE, I would strongly suggest at
least implementing alternative 2 rather than doing nothing.  

On the other hand, if this RFE were to be implemented, I would expand it to
include all certificate overrides.  That would then include the case where a
user overrides a lack of root certificate for a site certificate (i.e., when the
domain for a site certificate indeed matches the site's domain but the root
certificate that signed the site certificate is either not in the browser's
database or else has its trust indicator "off").  The current implementation is
generally unsafe in that all certificate overrides seem to persist until the
browser is terminated.  

Comment 5

[Kai Engert (:KaiE:)]

I think I misread your original comment, sorry!

You were not suggesting a whitelist, you are simply suggesting to give the user
a feedback while security is in place caused by a manual override the user
decided to make during the session.

I now agree to your suggestion.

Using a visual feedback of the special security situation would increase the
user awareness.

However the problem is more difficult than just introducing a new lock icon,
because http is not the only way to use certificate. There is also mail and ldap.

Comment 6

[David E. Ross]

This RFE should be implemented in conjunction with bug #267515.  

Comment 7

[Taral]

Nitpick: Can I suggest a "!" instead of a "?" overlay? The "?" implies
uncertainty, whereas "!" implies exception.

Comment 8

[Kai Engert (:KaiE:)]

reassign bug owner.
mass-update-kaie-20120918

Comment 9

[:Cykesiopka]

This is basically a combination of Bug 1201437, and Bug 1220753, so duping as appropriate.