Certificate exception for github.com not working with built-in root CAs removed

[kla...@partyheld.de]

Hello everybody,

I'm seeing following issue on current releases of both, Firefox and
Thunderbird: If one removes all built-in root CAs in the Certificate
Manager and adds a server exception for github.com, no connection is
possible (Error code: sec_error_unknown_issuer).

While other servers, e.g., www.joomla.org, www.auswaertiges-amt.de can
be connected to without problems. What can be seen on
https://www.ssllabs.com/ssltest/analyze.html?d=github.com is that it
supports HSTS, while the two working above don't. Could there be an
issue with that here?

Many more details on https://bugzilla.mozilla.org/show_bug.cgi?id=1202511

Best,

Joe

[David Keeler]

HSTS is most likely the issue. If the browser notes a site as HSTS and
later encounters an error when attempting to verify the site's
certificate (such as not being able to find a trusted issuer), the spec
mandates that the connection not be allowed. See
https://tools.ietf.org/html/rfc6797#section-12.1

Cheers,
David

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

[kla...@partyheld.de]

Thanks for the quick response. That makes perfect sense with the
currently not shown "I Understand the Risks" part of the "Untrusted
Connection" page, so that the user can't just click through and accept
an exception.

But couldn't there be at least an about:config parameter to override the
certificate issuer check with respect to the exceptions manually added
in the Certificate Manger?

The reason is that with everyone (hopefully) switching to HTTPS and
implementing HSTS in future, such a simple certificate pinning in
Thunderbird will not be possible. (Which might also be useful with
Firefox in some specific use cases.)

I can't think of a security threat with that right now. Because:

a. With all root CAs removed and a specific server cert pinned (i.e.
exception added), the user can't connect to an MitM, so no "guide" can
be shown by the latter on how to "fix" the connection issue.

b. With the root CAs not removed, an MitM with an accepted (but
different) cert doesn't need to show such a "guide", because a
connection will be established anyway.

c. With the root CAs not removed, an MitM with an UNaccepted cert ...
(no connection - same as in point (a) above).

So that checking of the issuer of certs in the exceptions list doesn't
seem to improve security. But disallows such useful things like that
simple cert pinning on Thunderbird, or usage of self-signed certificates
with HSTS.

Allowing the exceptions, on the other hand, still seems to fit into
https://tools.ietf.org/html/rfc6797#section-12.1. On my reading, anyway.
:) As long as the "I Understand the Risks" part of the "Untrusted
Connection" page is not shown and therefore no click-through is
possible. So that there is "no chance to "fool" users into making the
wrong decision". While existing exceptions don't meant that "something
is not entirely correct with the connection establishment" - they have
been explicitly allowed, after all. I don't think they fall into the
"errors" category as per https://tools.ietf.org/html/rfc6797#section-8.4
either, because, again, they have been explicitly allowed - using them
is expected behavior, not an error. (And if one can choose usable cypher
suits, why can't one also choose usable certificates, even, e.g.,
self-signed ones?)

Am I missing something? What do you think?

Best,

Joe

P.S.: I'm not a lawyer :)