1202511 - Server certificate exceptions not working with feeds

Status: RESOLVED DUPLICATE of bug 497488

(MailNews Core :: Feed Reader, defect)

Description

[Joe Smith]

Manually added server certificate exceptions do not work with Feeds.

Test steps:
1. In the certificate manager, Authorities tab, "delete" (i.e. revoke trust of) all built-in authorities
2. In the Servers tab, add a permanent exception for a certificate (use e.g. https://github.com/joomla/joomla-cms/releases.atom)
3. Under Blogs & News Feeds, open the Feed Subscriptions window, place "https://github.com/joomla/joomla-cms/releases.atom" into the Feed URL text box and click OK.

Expected results:
1. Trust gets revoked for all
2. Exception appears under the Certificate Name of Digicert Inc, as "github.com", for the server "github.com:443"
3. Feed gets added

Actual results:
3. "The Feed URL could not be found. Please check the name and try again" appears at the bottom of the Feed Subscriptions window. While the Error Console shows following:
Timestamp: 08/09/15 00:49:15
Error: github.com:443 uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
(Error code: sec_error_unknown_issuer)

Note: Same occurs with, e.g., https://www.joomla.org/announcements/release-news.feed?type=rss

Please note that the two above example servers (github.com and www.joomla.org) do not allow HTTP - they redirect to HTTPS.

Thunderbird 38.2.0 as provided by Linux Mint 17.1

Comment 1

[Joe Smith]

P.S.: Exceptions for IMAP and SMTP servers work without problems.

Comment 2

[alta88]

This is certainly not a feeds core issue, it just happens that feeds are the only real user of http[s] in Tb.

Both of those https urls subscribe fine with the standard CAs.  Are you removing them just for fun?  Is it your expectation that removing a root CA should not matter if manually adding a site exception which uses the root CA to issue its cert?

If you perform the exact same steps in Firefox, and attempt to go to those links, what happens?

Comment 3

[Joe Smith]

(In reply to alta88 from comment #2)
> This is certainly not a feeds core issue, it just happens that feeds are the
> only real user of http[s] in Tb.
>
> Both of those https urls subscribe fine with the standard CAs. Are you
> removing them just for fun?

It's to implement certificate pinning in TB. See, e.g., following for information: http://forums.mozillazine.org/viewtopic.php?f=39&t=2687657

> Is it your expectation that removing a root CA
> should not matter if manually adding a site exception which uses the root CA
> to issue its cert?
Absolutely. That sounds logical based on the UI, and also on the how Firefox behaves on adding exceptions for sites using, e.g., self-signed certificates. Those don't have a root CA either, but they work in Firefox.

> If you perform the exact same steps in Firefox, and attempt to go to those
> links, what happens?

I just tried that with Firefox 40.0.3 (same distro), as a test. And:
* On github.com, the "Untrusted Connection" page appears (Error code: sec_error_unknown_issuer), but there is no option to add an exception - the "I Understand the Risks" part of the page is not shown. When one adds an exception manually (in the Certificate Manager), it still doesn't work - the same "Untrusted Connection" window appears on both, feeds and noon-feed pages.

* On www.joomla.com, the "Untrusted Connection" page appears and the "I Understand the Risks" is shown, with the "Add Exception" button. When one adds the exception, both feed and non-feed pages are shown correctly.

I wonder where the difference between the two above sites comes from. Maybe server or CA cert properties (used hash function, expiration dates, etc.)?

After that, I went back and re-ran the test in the issue description with the www.joomla.com feed - and it actually works! (I must have made a mistake testing it. The github.com one still doesn't work.)

Another one that works in TB and shows the same behavior in the FF test as www.joomla.org (i.e. it works, too) is https://www.auswaertiges-amt.de/SiteGlobals/Functions/RSSFeed/DE/RSSNewsfeed/RSS_Reisehinweise.xml


Notes:
- Generally, I use the Certificate Patrol add-on for cert pinning on Firefox, and don't change the built-in CAs. Because on a browser, where one accesses plenty new sites frequently, it would be an overkill to have to confirm an exception for each new site after having removed all built-in CAs. So, the Certificate Patrol is a much better solution (and provides much better information on certificate changes). An e-mail/feed client, on the other hand, only accesses a few pre-defined servers: the ones configured for e-mail (IMAP, POP, SMTP) and the feed URLs. So, I expect to just need to add exceptions for those servers and be notified on a cert change (by a window popping up as it is already the case with e-mail servers; or at least an Error Console output, as it seems to be the case with the feeds).

- Certificate Patrol is not supported with TB. And even if it would work with the feed reader there, re-enabling the built-in CAs for the feed reader would remove the pinning of the mail servers, because Certificate Patrol definitely does not "patrol" e-mail servers. I tried it a while ago, before switching to the CA removal solution. And pinning of e-mail servers is more important to me. The major reason for "pinning" the HTTPS feeds for me is just that those are not accessible over HTTP.

- Another type of connections in need of pinning (and which is not covered by Certificate Patrol) are connections to Mozilla update servers. But that has already been built in in recent FF and TB releases (allowing just two specific issuing CAs, if I remember correctly). So, that covers Firefox, while on TB pinning of those can be made even stricter - to specific certs, exactly like with e-mail servers. (The difference is that no cert error window will open up on cert change like with e-mail servers, but one can see the reason of failed connection in the TB Error Console.) I haven't tested it recently, because TB comes from the distro and I haven't been using add-ons on it, but it worked on Windows some versions ago.

Comment 4

[alta88]

To summarize, adding some certs manually works, and those that succeed in Tb also succeed in Fx. An exception is github, which fails on both (with roots removed from both).

I don't know if github.com cert is broken or not, and suggest you post the issue/behavior to mozilla.dev.security before raising a bug in Firefox, but would guess it's more likely than not.  In any event, core cert handling is outside the scope of any Tb component.

The misleading feed subscription message on cert error is Bug 497488, duping to that.

Comment 5

[alta88]

You may want to check that this isn't the no cyphers overlap issue between your Fx/Tb prefs and what github wants to exchange, there's a lot of commentary about it recently since some weak suites are being deprecated.

Comment 6

[Joe Smith]

Thanks for the hint. But while the TB profile I use is stricter-than-normal with the cyphers choice, I used a virgin FF profile for the above test. And I actually had tested more servers in TB than the ones mentioned above, but I didn't mention them, because TB displayed a "no cyphers overlap" (I'm paraphrasing here) on them in the Error Console, so I didn't mention them. Github wasn't one of them. Looks like github.com passes with flying colors on https://www.ssllabs.com/ssltest/analyze.html?d=github.com - strange. Or maybe that's the problem: it supports "HTTP Strict Transport Security", while www.joomla.org and www.auswaertiges-amt.de don't and they work.

I'm going to ask on mozilla.dev.security.