395703 - Larry claims the site is all good when it isn't

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P4)

Description

[Dave Townsend [:mossop]]

If you visit the kubla site you must allow the certificate temporarily because the ssl certificate is for sm-cms01 and also see a horrible error describing this.

Once you have done this larry happily claims that the site's location has been verified as kubla.sm-cms01.mozilla.com, verified by that well known SomeOrganization. Apparently this is because accepting the certificate even for the session makes it trusted.

To me this is just plain wrong and actively suggesting to people that this domain is safer than it is. I would suggest one of two options, either we should actively highlight that the certificate is bad (red background to larry bar perhaps), or simply leave the UI the same as for a non-ssl site.

Johnathan says this is a bug with PSM and it's notifications, but I know that the updates and extension manager services can pick up whether a certificate is signed by a built in CA or not, I don't see why Larry can't follow this path.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

> Apparently this is because accepting the certificate even for the session 
> makes it trusted.

... for the session.  That's exactly what it does.  Only trusted certs 
(or certs that issue from trusted certs) are honored, by design. 
You want us to honor a cert that doesn't issue from a trusted cert?
Then you're telling us to trust that cert, for the session, or permanently,
as you (the user) see fit.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

BTW,  I agree that when a cert was trusted by the user, rather than having
been issued by a trusted CA, Larry ought to tell us that.

Comment 3

[Johnathan Nightingale [:johnath]]

Nelson/Kai - is there a way to ask for this information?  That is, a service to ask "Is this cert a trust override?"

Comment 4

[Kai Engert (:KaiE:)]

(In reply to comment #3)
> Nelson/Kai - is there a way to ask for this information?  That is, a service to
> ask "Is this cert a trust override?"

I think we already have that. Let's see what we need:


(In reply to comment #2)
> BTW,  I agree that when a cert was trusted by the user, rather than having
> been issued by a trusted CA, Larry ought to tell us that.


We should decide where we draw the boundary.
A cert could be trusted because:
(a) host:port+cert override (entered by the user)
(b) explicitly trusted server cert (by the user)
   (either an "accept cert permanently" cert from the old days,
    or a cert manually imported from a file in cert manager)
(c) trusted because user has imported+trusted a root CA cert
(d) trusted because the trusted CA cert was shipped with the product


In my opinion, we should show "this is an override" for (a) and (b).


You're already able to test for (a)

interface nsICertOverrideService {
  boolean hasMatchingOverride(in AString aHostNameWithPort,
                              in nsIX509Cert aCert,
                              out PRUint32 aOverrideBits);
}

You call it with the "hostname:port" string plus the cert, and you'll get a false for "no override stored" and a "true + trust bits" for "yes, there is an active override for this combination".

(I just realized that my comment for this function in the IDL doesn't yet match the function, it was a copy paste from another one...)


If you want to report (b), I think you want to run the same code that is currently used when you "edit" the trust of a server cert. See editcerts.js

I think you need to call
  nsIX509CertDB::isCertTrusted(cert, nsIX509Cert.SERVER_CERT,
                                     nsIX509CertDB.TRUSTED_SSL):


I expect you don't want to do (c) or (d).
If you want to, I'll write further explanations.

Comment 5

[Johnathan Nightingale [:johnath]]

With bug 406612 landed, sites with security exceptions get different text treatment in the panel and the tooltip (see attachment 300074 [details]).  We could potentially wordsmith the text there, but I'm going to mark this bug FIXED since the behaviour Mossop identifies no longer occurs.

Comment 6

[Tracy Walker [:tracy]]

I'm certain this is covered in the Litmus Security test group.