Jabber certificate check is wrong, also forcing trust doesn't work

I believe the always trust only works if the first part works. It should be using the server's domain and not taking it from the JID. Andy?

Yes, the host name problem is a real bug. It used to work fine when I implemented it, but now it doesn't any more for some reason unknown to me (probably some regression in libpurple).

Trusting the certificate isn't possible when the hostname doesn't match (since then the man-in-the-middle-attack server would just have to use any certificate you have set to be trusted in your keychain to get your password). However, you can disable certificate checks in the account settings for this particular account.

Fixed in libpurple mtn b7bc71beeea1f0d58d282c66c591928964e3b333 (will be part of 2.3.2 I guess)

This needs a different milestone.

The milestone could be 1.2:

1. If 2.3.2 mtn is followed by the time 1.2 final is released
2. If 2.3.2 final is released before 1.2 final is released.

Otherwise it will be 1.2.1... going to set to the later milestone so people don't get the idea in their heads that it's definitely in 1.2 final.

Replying to jas8522:

I believe the always trust only works if the first part works. It should be using the server's domain and not taking it from the JID. Andy?

It _should_ take it from the JID. See:

RFC 3920 (XMPP Core), Section 5.1 (Use of TLS), Rule #8:

""" Certificates MUST be checked against the hostname as provided by the initiating entity (e.g., a user), not the hostname as resolved via the Domain Name System; e.g., if the user specifies a hostname of "example.com" but a DNS SRV[SRV] lookup returned "im.example.com", the certificate MUST be checked as "example.com". """

Also, you can take into account the fact that CAs issues certificates on the XMPP domain, not on the XMPP server hostname (see the XMPP federation certificate instructions for more details).

I'd like to cross this discussion with #8787.

The discussion in this ticket should be limited to the login issue which was resolved; the certificate issues are better off in their own tickets. To be clear, the changeset mentioned above by am fixes the login issue only; the relevant diff is:

============================================================
--- libpurple/protocols/jabber/jabber.c	37a356263832da85c1ce5dac41c9c1204cb8f407
+++ libpurple/protocols/jabber/jabber.c	eea6e7d81fa04f0cc37dae64741e2b910f56b45c
@@ -536,12 +536,13 @@ static void tls_init(JabberStream *js)
 	purple_input_remove(js->gc->inpa);
 	js->gc->inpa = 0;
 	js->gsc = purple_ssl_connect_with_host_fd(js->gc->account, js->fd,
-			jabber_login_callback_ssl, jabber_ssl_connect_failure, js->serverFQDN, js->gc);
+			jabber_login_callback_ssl, jabber_ssl_connect_failure, js->host, js->gc);
 }
 

which you can see does not relate to trust issues.

Reopening, since there is no other ticket about just the "always trust this certificate" checkbox not working. The other part (the host name used for CN verification is wrong) is already fixed, see #8787.

I think you get a warning message even when the certificate is marked as trusted when the host name doesn't match the CN in the certificate. I'm not sure if this should be changed (even if it was possible, which it isn't).

One fix we could do would be to make the acceptedCertificates dictionary persistent, so you only had to accept a certificate once for a specific account. This could still be considered secure, since the user has to confirm this certificate once (calling the server admin and verifying the fingerprint), and it pops up again when the certificate changes. Further, accepting this certificate for one account wouldn't allow the owner of the certificate to launch a MITM attack on any other account of the user, since it's bound to that specific account. Evan, what do you think?

That seems like a fine idea am.

If we can't fix the 'always trust' checkbox, that sounds good... it'd be better to figure out why we're not working properly with the system's own credentials checking.

Replying to evands:

it'd be better to figure out why we're not working properly with the system's own credentials checking.

We are... the problem is that even when the certificate is set as trusted, the security framework is still performing the hostname check and fails. There's no way to tie a specific certificate to an Adium account, since the framework simply doesn't know about persistent accounts.

Hm. Yeah, the always trust checkbox does work for me for at least a couple servers - I see now what you mean about it being related to the host name check failing.

I don't think we should make acceptedCertificates persistent independent of the 'always trust' checkbox, because then we would effectively always trust a certificate even if not told to do so. That doesn't seem right. If we could check if 'always trust' had been checked, that'd be different.

if the Root certificate authority certificate is present, and trusted, in the X509Anchors keychain before a related site is visited, then the related certificate is added without question to the keychain of the user

Observation

1. Focusing on the first three (of four) PNGs above, which relate to jabber.org, to begin with I observed what I'll call a chain of authority,

   certificate for root authority —> certificate for intermediate authority —> certificate for *.jabber.org
   

Distinction

chain of authority (expression)
not to be confused with
keychain (used by Apple's Keychain Access utility).

Reference

certtool - create key pairs, certificates and certificate signing requests for use with Keychains

I don't understand the manual in its entirety but I gather that, for a .pem certificate relating to a root certificate authority, the proper place is

/System/Library/Keychains/X509Anchors  System root certificate database

Further observations

2. You may find some root certificates
   • in your own keychain
   • but not in the X509Anchors keychain.

3. If you are offered, or know where to obtain, an authority's root certificate, then you may:
   • open the .pem file in Keychain Access
   • add the certificate(s) to the X509Anchors keychain.

4. Then: if the root certificate is present (and presumably trusted) in the X509Anchors keychain, before a related site is visited:
   • the related certificate is seemingly added without question to your own keychain.

Chains of authority

Focusing on the fourth PNG above, which relates to a University at which I'm based:

1. I deleted both certficates
2. then opened a .pem file containing the root certificate
3. added the certificate to X509Anchors
4. launched Safari, visited <https://rt.sussex.ac.uk/> and unless I'm missing something, I was not prompted for the second certificate:
   • the certificate for rt.sussex.ac.uk appeared automatically in my keychain

and of most interest:

• clicking the padlock icon in Safari presents a clear relationship (chain of authority) between Sussex Root CA and rt.sussex.ac.uk.

An attempt to always trust all three certificates relating to *.jabber.org

1. Delete all three certificates from keychain(s)
2. obtain the root certificate from Free SSL Certification Authority
3. add the certificate to the X509Anchors keychain
4. launch Adium, connect to jabber.org
5. Show Certificate
6. review Trust Settings for each of the two certificates (you may find that both are already set to Always Trust)
7. tick Always trust these certificates
8. Continue.

Final observations

5. Adium presents a chain of authority between two certificates
   • intermediate certificate authority
   • certificate for *.jabber.org

— without presenting the root certificate.

6. Unlike Safari, which seemed to add the certificate for rt.sussex.ac.uk without prompting (presumably because I have trusted the root certificate), Adium does prompt for acceptance of (at least) the intermediate certificate that was (earlier) related to trusted Free SSL Certification Authority.

So I wonder:

• is the relationship between all three certificates properly recognised?

Trust settings and items in keychain

From what I can gather, trust settings are independent from the certificates to which they may relate:

1. delete from a keychain a trusted certificate
2. cause the same certificate to be added
3. at that point (before specifying any trust) it's remarkable that the certificate is already trusted.

I don't know (may not need to learn) how to change trust settings for a certificate that's no longer in the keychain.

---

Caution: some of what's outlined above is guesswork. Where security is concerned, proceed with caution!

Graham Perrin, Project/Media Development Officer
CENTRIM - the Centre for Research in Innovation Management
<http://www.brighton.ac.uk/centrim/>
+44-1273-877922

Replying to evands:

I don't think we should make acceptedCertificates persistent independent of the 'always trust' checkbox, because then we would effectively always trust a certificate even if not told to do so. That doesn't seem right. If we could check if 'always trust' had been checked, that'd be different.

Maybe this information can be obtained from the trust object passed as a reference to that sheet. I'll look into it.

Replying to zee:

I've got a google talk account which uses google apps for your domain and I can't get it working right in 1.2b1. First, for some reason your certificate checker uses the hostname part from my JID as domain (instead of using login server, those two are different in my case) and obviously fails. I think it's a bug and should be fixed. Second, there's an "Always trust" checkbox, but it doesn't work — the certificate gets marked as trusted, but Adium still shows me a warning message every time I start it.

I fought this exact issue myself. I finally resolved it by selecting the GTalk account in Preferences/Accounts and clicking Edit then Options. There are four checkboxes under "Security" and I deselected the one that says "Do strict certificate checks". I was able to sign off and back on, as well as quit Adium and reopen, without having to approve the certificate again. I don't know if the "Always Trust" issue and this strict certificate checking are directly related or not, but it seems one either enables the other or overrides it.

In case it's useful, I have only started having this problem since upgrading to 1.2.1 yesterday, and only on one of my Gtalk accounts. The problem account shows up with a Jabber lightbulb icon rather than the GTalk, since I set it up when GTalk first came out, and the talk.google.com address is editable. The newer account has a GTalk icon and talk.google.com is not editable. Both have the strict certificate checks box checked.

I just disabled the older account and re-created it with the GTalk option rather than Jabber, and can now log in without any trouble. The strict certificate checks box is still checked, so at least from where I am, it looks like the problem might have something to do with using the Jabber settings rather than GTalk.

Replying to Maeve:

In case it's useful, I have only started having this problem since upgrading to 1.2.1 yesterday, and only on one of my Gtalk accounts. The problem account shows up with a Jabber lightbulb icon rather than the GTalk, since I set it up when GTalk first came out, and the talk.google.com address is editable. The newer account has a GTalk icon and talk.google.com is not editable. Both have the strict certificate checks box checked. I just disabled the older account and re-created it with the GTalk option rather than Jabber, and can now log in without any trouble. The strict certificate checks box is still checked, so at least from where I am, it looks like the problem might have something to do with using the Jabber settings rather than GTalk.

It certainly looks like Maeve found a different way to correct the issue, but it makes me think that whatever two different things we did simply inadvertently triggered the same background activity. I never have never used any Jabber accounts or settings, nor did I delete and re-add my gtalk account.

A Gtalk account configured as a Jabber account will fail certificate checks. MaxtonIV, how is your GTalk account configured?

Connect Server: talk.google.com Resource: Adium Port: 5222 Available Priority: [blank] Away Priority: [blank] Mail: None Checked Security: None Checked Presence Subscriptions: Ask What To Do

Connect when Adium opens

Not connecting via proxy

My certificate says "This certificate is marked trusted for this account"

If I didn't give you the information you needed, let me know what else to send.

I actually didn't begin to troubleshoot this (figuring it was a bug that would be worked out) until 1.2.1 was released and it all the sudden was no longer an issue. Then one or two days later another update (1.2.1b, maybe?) came out and re-broke it. That's when I started poking around more to see what I could change or what was changed between the two versions. I'm sorry I can't be more specific about the versions but I feel like the version history excludes the first update I installed over that two day period (somewhere around the 18th).

Does your Google Talk account show a Google Talk icon or a Jabber lightbulb next to it in the Accounts preferences? (1.2.1b was the beta for 1.2.1. Adium 1.2.1 is the latest version).

Since 1.2.1 I am certainly having problems with *real* Google Talk certificates, that means with a Google Talk icon in the Accounts preferences. If I click "Continue" (is that what is says in English?, in my German localisation the word is "Fortfahren"), Adium does connect me but the next time I start Adium the problem's back.

I'll attach a screenshot in a few minutes, now.

I am not having any issues with Jabber certificate from jabber.org.

Window with Google Talk certificate problem

Ah! It's the googlemail.com vs. gtalk.com distinction, I believe.

I have the Google "talk" speech bubble icon next to the account in my list. Thank you for clarifying the beta distinction in the version history. I only recently began to use Adium for Google Talk, which is when I began having this problem. I assumed it was a bug in Adium [one version prior to 1.2.1 beta] with Google Apps For Your Domain so I didn't research it. Then I updated to 1.2.1 beta and the problem vanished, and I was happy. Then 1.2.1 official came out and the problem returned. That's when we met.

Maxton, could you please make me an account on your Google Apps For Your Domain setup so I can log in with your configuration and investigate this further? You can email me the login info.

(In [22500]) Handle Google Talk certificates properly, including Google Talk for Domains. Fixes #8529. Also, fixed a visual glitch as the certificate sheet closes; there's no reason to wait a run loop to close its parent window.

(In [22501]) Merged [22500]: Handle Google Talk certificates properly, including Google Talk for Domains. Fixes #8529. Also, fixed a visual glitch as the certificate sheet closes; there's no reason to wait a run loop to close its parent window.

You forgot googlemail.com

(In [22504]) Added support for googlemail.com. Fixes #8529.

(In [22506]) Merged [22504] & [22505]: Added support for googlemail.com. Fixes #8529.