This bug partially requests upstream changes, but it also has Fedora specific elements. You might want to read bug 873373 for some background. In short, pidgin uses openssl for CA verification, which uses the CA whitelist from ca-certificates.pem. As of today, pidgin behaves in a whitelist-only mode. But the global CA bundle could contain blacklisted (compromised) CA certs, too, and it would be good if pidgin were able to handle that (reject server issued by blacklist CAs). While investivating I noticed the following issues (I hope my findings are correct, please speak up if I'm wrong). (a) pidgin uses a configuration option --with-system-ssl-certs=/etc/pki/tls/certs That file contains two files provided by ca-certificates.pem. The files have different format. The pidgin source code tries to open and load ALL files in that directory. I believe that's bad going forward, because the file contains: - one file in an old format (whitelist only, no trust flags) - one file in newer format (with trust flags, blacklisted certs) Even if pidgin supported the newer file format with the blacklisted entries, I'm worried that loading any files from that directory MIGHT lead to unexpected behavior. I suggest to fix that and have pidgin only load one of the files. (If pidgin doesn't change it's "load all from one directory" behavior, this might require that ca-certificates provides the newer file in its own separate directory.) (b) As of today, pidgin doesn't support the blacklisted CA entries. This is an enhancement requested (tracked across apps by bug 873373). It might be necessary to change the way that pidgin loads its list of trusted CA certs. Maybe using new API SSL_CTX_load_verify_locations FYI, in order to verify this is necessary, I have performed various tests. I used rm -rf $HOME/.purple/certificates/x509/tls_peers prior to each of my individual tests, as it seemed that pidgin caches certs that had been verified earlier, and doesn't attempt to verify them again. (I didn't try to figure out whatexactly is the logic here). I had using my own test ca, and used my own server cert (correct hostname) on my own local jabber server, and configured a jabber conf with "require encryption". If my CA was NOT included in global lists: - pidgin prompts me to accept the cert If my CA was added with a standard BEGIN CERTIFICATE block (standard whitelist) to the global list: - pidgin accepts the cert If my CA was added with a new format "BEGIN TRUSTED CERTIFICATE" block to the global list: - pidgin prompts me to accept the cert I got this behaviour with both variotions of that trust block, using either positive trust (-addtrust) or negative trust (-addreject) I tried both, and pidgin will prompt me to accept the cert in both scenarios. This means, at this time, pidgin is unable to deal with BEGIN TRUSTED CERT blocks. (c) I'm worried what will happen if a server cert gets compromised. Might pidgin's cert cache prevent certs from being rejected, if a new global CA bundle changes a root to the distrusted state? This should be verified.
(In reply to comment #0) > In short, pidgin uses openssl for CA verification, which uses the CA > whitelist from ca-certificates.pem. Pidgin can be built using GnuTLS or NSS, OpenSSL is not supported: https://developer.pidgin.im/wiki/FAQssl#WhycantIuseOpenSSLforSSLsupportinlibpurple In summary: you need GNUTLS or Mozilla NSS and NSPR; OpenSSL will not do. http://hg.pidgin.im/pidgin/main/file/fce9167b25c2/libpurple/plugins/ssl IIRC, all Fedora and RHEL builds use NSS: http://pkgs.fedoraproject.org/cgit/pidgin.git/tree/pidgin.spec#n516 # gnutls is buggy so use mozilla-nss on all distributions %configure --enable-gnutls=no --enable-nss=yes --enable-cyrus-sasl \ > pidgin uses a configuration option > --with-system-ssl-certs=/etc/pki/tls/certs Note that pidgin developers also maintain their own list of CAs. I believe the purpose it to provide minimal set of trusted CAs that are known to be needed to connect to servers of the supported IM services. This is meant to reduce risks of accepting malicious certificate issued by a compromised CA. http://hg.pidgin.im/pidgin/main/file/fce9167b25c2/share/ca-certs > If my CA was added with a new format "BEGIN TRUSTED CERTIFICATE" block to > the global list: > - pidgin prompts me to accept the cert Given that Fedora pidgin uses NSS, it probably relies on NSS' PEM reader. This is your turf, can you tell us how NSS handles this trusted format?
(In reply to comment #1) > Pidgin can be built using GnuTLS or NSS, OpenSSL is not supported > IIRC, all Fedora and RHEL builds use NSS Thanks for the clarification. But it's not fully correct, we must explain pidgin's behavior in more detail. NSS comes a list of CA root certs that are built into the library. But as I understand it, Pidgin doesn't use it. Instead, Pidgin reads the files from ca-certificates, and uses that as a pool of acceptable CA certs. NSS provides an API to verify all aspects of a certificate for trustworthiness, the CERT_VerifyCert* functions. But Pidgin doesn't use them. NSS can automatically verify a server's cert during the SSL handshake between client and server. But Pidgin doesn't use that, instead, Pidgin registers callback function ssl_auth_cert, which is a "do nothing" function. What Pidgin does, it implements its own certificate validation (x509_tls_cached_start_verify + x509_tls_cached_unknown_peer). But when it tries to check whether a server certificate has been issued by a trusted CA, it doesn't use NSS code - instead, it searches for certificates in Pidgin's local pool (that was built from the ca-certificates file). I'm really surprised that Pidgin developers used that approach. It appears to me that they have made their life much harder than necessary. (It would be interesting to know why did they it that way, either they had a good reason, or they didn't know what NSS offers.) > > If my CA was added with a new format "BEGIN TRUSTED CERTIFICATE" block to > > the global list: > > - pidgin prompts me to accept the cert > > Given that Fedora pidgin uses NSS, it probably relies on NSS' PEM reader. No, Pidgin uses its own function, x509_importcerts_from_file. > This is your turf, can you tell us how NSS handles this trusted format? I think that's not the right question. Now that I understand that Pidgin doesn't use openssl, it's clear that it cannot understand the openssl-specific (new and experimental) format to bundle trust flags together with certs. Teaching NSS to read such flags doesn't make sense to me. The Pidgin code would have to learn how to do it, if it prefers not to use non-NSS-provided trust data. But after all of this, I really think that Pidgin should be changed to avoid all of its local logic to verify certificates, and simply use what NSS provides. That will give Pidgin the trust store that comes with NSS - and obviously that's what Pidgin wants to use (because ca-certificates is the result of an (incomplete) conversion from the NSS trust store to a different file format). And if Pidgin requires something in addition, then we should find a way to get it done - by extending NSS logic - not by replacing it.
(In reply to comment #1) > Note that pidgin developers also maintain their own list of CAs. I believe > the purpose it to provide minimal set of trusted CAs that are known to be > needed to connect to servers of the supported IM services. This is meant to > reduce risks of accepting malicious certificate issued by a compromised CA. Maybe that was the problem, maybe Pidgin developers didn't know how to add a set of additional CAs on top of NSS' builtin root storage? Even if the application uses the no-database-initialize mode to use NSS (as Pidgin does), I think there should be a way to import a couple of new certificates and mark them as trusted (on top of the list that NSS has built-in).
(In reply to comment #2) > NSS comes a list of CA root certs that are built into the library. libnssckbi. Is there any simple explanation why that list is actually built into the library, rather than provided as nss db (which would be something system administrator can modify without having to rebuild nss)? > But as I understand it, Pidgin doesn't use it. Instead, Pidgin reads the > files from ca-certificates, and uses that as a pool of acceptable CA certs. IIRC, curl is similar in this aspect. It does not use libnssckbi and reads ca-bundle.crt. I believe it uses NSS functionality for that, but I've not looked for details. This is in curl's rpm changelog: - add support for the NSS PKCS#11 pem reader so the command-line is the same for both OpenSSL and NSS by Rob Crittenden curl may not ignore NSS' verification functionality. > NSS can automatically verify a server's cert during the SSL handshake > between client and server. But Pidgin doesn't use that, instead, Pidgin > registers callback function ssl_auth_cert, which is a "do nothing" function. > > What Pidgin does, it implements its own certificate validation > (x509_tls_cached_start_verify + x509_tls_cached_unknown_peer). Somewhat related upstream ticket: https://developer.pidgin.im/ticket/15308 > I'm really surprised that Pidgin developers used that approach. It appears > to me that they have made their life much harder than necessary. (It would > be interesting to know why did they it that way, either they had a good > reason, or they didn't know what NSS offers.) Some hints are in the above ticket, but it does not give a clear answer. > But after all of this, I really think that Pidgin should be changed to avoid > all of its local logic to verify certificates, and simply use what NSS > provides. That will give Pidgin the trust store that comes with NSS - and > obviously that's what Pidgin wants to use (because ca-certificates is the > result of an (incomplete) conversion from the NSS trust store to a different > file format). There are 2 cases to consider - upstream default and what is used in Fedora. It seems upstream default is to only trust the few carefully picked CAs that are actually needed. Hence they trust less than 30 CAs, which is all that's needed to use supported IM networks. Adding full NSS CAs set (either via ca-bundle.crt or libnssckbi) add 100+ more. In Fedora, it should make no difference if libnssckbi is used instead. However, it may lead to differences in configuration depending on what SSL library is used, which may be undesired.
> It seems upstream default is to only trust the few carefully picked CAs that > are actually needed. Hence they trust less than 30 CAs, which is all that's > needed to use supported IM networks. That seems to me a relic of the past when everyone was on either AIM or MSN. These days, with proliferation of jabber servers everywhere, it seems to no longer really apply. But I guess that's a decision for uspstream to make. Although to me, this means I have no problem adding the full NSS trusted CA store. I'd also like to see NSS DANE support but that's a whole separate issue.
(In reply to comment #4) > (In reply to comment #2) > > > NSS comes a list of CA root certs that are built into the library. > > libnssckbi. Is there any simple explanation why that list is actually built > into the library, rather than provided as nss db (which would be something > system administrator can modify without having to rebuild nss)? There's only an explanation that requires you to understand more of the way NSS operates, but I'll try to be short. NSS is able to combine certificates and trust information from multiple sources. The sources follow a standard, pkcs#11 libnssckbi is an implementation of a module that provides both certificates and trust (positive and negative trust). You say, "why not as a DB"? Because using a writeable DB is optional. It might be recommended, but still, it's optional, and many applications use NSS without it. By providing it as a binary module, the default set can work fine in complete read only setups (such as apps not using their own DB). And because NSS combines information from mutliple sources, this approach doesn't prevent anything. As soon as an application decides to use their own writeable NSS database, they can add as many modifications to the trust as they wish - which will be interpreted with a higher priority than the information from libnssckbi. Furthermore, in case you didn't know, on Fedora we even have a global systemwide database, that is owned by root. Read the description of the nss-sysinit package. Applications can load the the shared module that comes with that packacke, and the app will include the certs and trust settings from /etc/pki/nssdb > > But as I understand it, Pidgin doesn't use it. Instead, Pidgin reads the > > files from ca-certificates, and uses that as a pool of acceptable CA certs. > > IIRC, curl is similar in this aspect. It does not use libnssckbi and reads > ca-bundle.crt. I believe it uses NSS functionality for that, but I've not > looked for details. This is in curl's rpm changelog: > > - add support for the NSS PKCS#11 pem reader so the command-line is the > same for both OpenSSL and NSS by Rob Crittenden > > curl may not ignore NSS' verification functionality. curl is another example of an application that can be configured to use NSS or other crypto toolkits. Read the man page of curl and the --cacert section - that indicates how tricky this option is, and how flexible curl is. If curl is configured to use NSS, then I believe curl will use the trust from NSS (libnssckbi). The changelog entry that you quote is a good indication that NSS really uses the NSS trust list from libnssckbi. curl had the requirement to use alternative/additional CA roots, and there was the additional desire that a single input format would use with all crypto toolkits. That was one of the initial triggers to implement the libpem module - it allows NSS to consume a file in the PEM format as a readonly source for trusted CA certificates. > > NSS can automatically verify a server's cert during the SSL handshake > > between client and server. But Pidgin doesn't use that, instead, Pidgin > > registers callback function ssl_auth_cert, which is a "do nothing" function. > > > > What Pidgin does, it implements its own certificate validation > > (x509_tls_cached_start_verify + x509_tls_cached_unknown_peer). > > Somewhat related upstream ticket: > https://developer.pidgin.im/ticket/15308 > > > I'm really surprised that Pidgin developers used that approach. It appears > > to me that they have made their life much harder than necessary. (It would > > be interesting to know why did they it that way, either they had a good > > reason, or they didn't know what NSS offers.) > > Some hints are in the above ticket, but it does not give a clear answer. > Thanks for the link, I'll cc myself. > > But after all of this, I really think that Pidgin should be changed to avoid > > all of its local logic to verify certificates, and simply use what NSS > > provides. That will give Pidgin the trust store that comes with NSS - and > > obviously that's what Pidgin wants to use (because ca-certificates is the > > result of an (incomplete) conversion from the NSS trust store to a different > > file format). > > There are 2 cases to consider - upstream default and what is used in Fedora. > > It seems upstream default is to only trust the few carefully picked CAs that > are actually needed. Hence they trust less than 30 CAs, which is all that's > needed to use supported IM networks. I didn't know that upstream is limited to that list, thanks. > Adding full NSS CAs set (either via ca-bundle.crt or libnssckbi) add 100+ > more. Yes, according to my testing in Fedora, the lists from /etc/pki/tls/certs are loaded (in addition to Pidgin's own list). > In Fedora, it should make no difference if libnssckbi is used instead. I don't propose to use libnssckbi instead of their 30 CAs. I propose that on Fedora, instead of today's "use the 30 pidgin CAs and everything from ca-certificates" Pidgin should be changed to use "use the 30 pidgin CAs and libnssckbi" But in order to make that work, Pidgin would have to be changed to use NSS verification logic. And in order to load the additional 30 CAs on top of that list, the recommended approach is to use the same libpem module that curl uses. (From Bob Relyea, after having briefly talked with him about this issue.) > However, it may lead to differences in configuration depending on what SSL > library is used, which may be undesired. Ok. If we want to solve it in Fedora, we must offer a good solution for upstream, too. The solution is to make sure that "upstream pidgin + NSS" is able to use the libpem module for their set of 30 CAs. Upstream will be able to make their own decision, whether they want to include our big list of CAs, too, or not. This can be a choice at init time. We might have to assist upstream Pidgin to get this done. And we currently have a blocker, before we can start with this task: Unfortunately, the libpem module isn't upstream in NSS yet, it's currently a private addition in Fedora :( But the NSS team is aware this is an important piece of work to get done. See https://bugzilla.mozilla.org/show_bug.cgi?id=402712
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Did upstream ever work on this?
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.