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

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 :)





On 08/09/15 22:56, David Keeler wrote:
> 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
>
> On 09/08/2015 01:46 PM, [email protected] wrote:
>> 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
>> _______________________________________________
>> dev-security mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-security
>
>
>
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>