Adium

Opened 12 years ago

Closed 9 years ago

#8529 closed defect (outofdate)

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

Reported by: zee Owned by: am
Milestone: Component: Service/XMPP (Jabber)
Version: Severity: normal
Keywords: Cc:
Patch Status:

Description

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.

Attachments (5)

jabber.org certificate.png (72.0 KB) - added by Graham Perrin 12 years ago.
StartCom Class 1 Intermediate CA - Jabber Software Foundation.png (72.3 KB) - added by Graham Perrin 12 years ago.
Free SSL Certification Authority - Root certificate authority for jabber.org.png (68.6 KB) - added by Graham Perrin 12 years ago.
a simpler relationship between (a) the trusted root certificate authority and (b) an issued certificate.png (29.1 KB) - added by Graham Perrin 12 years ago.
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
Bild 1.png (65.1 KB) - added by Robert 12 years ago.
Window with Google Talk certificate problem

Download all attachments as: .zip

Change History (45)

comment:1 Changed 12 years ago by Jordan

Milestone: Needs dev review
Owner: changed from nobody to Andreas Monitzer

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?

comment:2 Changed 12 years ago by Andreas Monitzer

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.

comment:3 Changed 12 years ago by Andreas Monitzer

Resolution: fixed
Status: newclosed

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

comment:4 Changed 12 years ago by Robert

This needs a different milestone.

comment:5 Changed 12 years ago by Jordan

Milestone: Needs dev reviewAdium X 1.2.1

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.

comment:6 in reply to:  1 Changed 12 years ago by Kena

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

comment:7 Changed 12 years ago by Kena

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

comment:8 Changed 12 years ago by Evan Schoenberg

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.

comment:9 Changed 12 years ago by Andreas Monitzer

Resolution: fixed
Status: closedreopened

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?

comment:10 Changed 12 years ago by Chris Forsythe

That seems like a fine idea am.

comment:11 Changed 12 years ago by Evan Schoenberg

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.

comment:12 in reply to:  11 Changed 12 years ago by Andreas Monitzer

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.

comment:13 Changed 12 years ago by Evan Schoenberg

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.

Changed 12 years ago by Graham Perrin

Attachment: jabber.org certificate.png added

Changed 12 years ago by Graham Perrin

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

comment:14 Changed 12 years ago by Graham Perrin

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

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

  1. 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.
  1. 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

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

— without presenting the root certificate.

  1. 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

comment:15 in reply to:  13 Changed 12 years ago by Andreas Monitzer

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.

comment:16 Changed 12 years ago by Evan Schoenberg

Milestone: Adium X 1.2.1Adium X 1.2.2

comment:17 in reply to:  description Changed 12 years ago by Tommy

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.

comment:18 Changed 12 years ago by 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.

comment:19 in reply to:  18 Changed 12 years ago by Tommy

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.

comment:20 Changed 12 years ago by Evan Schoenberg

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

comment:21 Changed 12 years ago by Tommy

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.

comment:22 Changed 12 years ago by Tommy

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

comment:23 Changed 12 years ago by Evan Schoenberg

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

comment:24 in reply to:  description Changed 12 years ago by Robert

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.

Changed 12 years ago by Robert

Attachment: Bild 1.png added

Window with Google Talk certificate problem

comment:25 Changed 12 years ago by Evan Schoenberg

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

comment:26 Changed 12 years ago by Tommy

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.

comment:27 Changed 12 years ago by Evan Schoenberg

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.

comment:28 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: reopenedclosed

(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.

comment:29 Changed 12 years ago by Evan Schoenberg

(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.

comment:30 Changed 12 years ago by Andreas Monitzer

Resolution: fixed
Status: closedreopened

You forgot googlemail.com

comment:31 Changed 12 years ago by Andreas Monitzer

Resolution: fixed
Status: reopenedclosed

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

comment:32 Changed 12 years ago by Andreas Monitzer

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

comment:33 Changed 11 years ago by Jan Thomä

This is not working here. I tried 1.3b11, and still the certificate is NOT accepted, even when I tick the "always trust" checkbox. I am running an ejabberd and using self-signed certificate.

comment:34 in reply to:  33 Changed 11 years ago by Johannes

Replying to kork:

This is not working here. I tried 1.3b11, and still the certificate is NOT accepted, even when I tick the "always trust" checkbox. I am running an ejabberd and using self-signed certificate.

Yes, I have to confirm this. The bug still (or: again) exists using 1.3b11. Please reopen this ticket!

comment:35 Changed 11 years ago by Ryan Govostes

Milestone: Adium X 1.2.2Adium X 1.3.x
Resolution: fixed
Status: closedreopened
Version: 1.2b11.3b11

comment:36 Changed 10 years ago by bikefridaywalter

It seems this problem is with Jabber in general and not just GTalk.

I have the problem with Meebo.org, as reported here.

I also have it, oddly enough, with my school's Jabber server.

comment:37 Changed 10 years ago by bikefridaywalter

Oh and I DON'T have the problem with GTalk. Duh duh duuuuuh.

I AM using the "Jabber" protocol with the aforementioned and GTalk with GTalk, even though Jabber would work fine in theory. Same with Livejournal and Facebook. Don't know if Twitter or Myspace use Jabber but using their protocols I no problem.

Short version of the story: it doesn't seem to be a problem on Jabber services that do not use the generic "Jabber" protocol on Adium.

comment:38 Changed 10 years ago by Robert

Ticket #13970 has been marked as a duplicate of this ticket.

comment:39 Changed 10 years ago by John Kelly

I am having this issue on 1.3.10 with a self-signed certificate from an internal Jabber server. I have told Adium to always trust the certificate, and I see it in my login keychain. I've since turned off "Do strict certificate checks" because I found it extremely annoying to have to accept it again every time I launch.

comment:40 Changed 9 years ago by Robert

Milestone: Adium 1.4.x
Resolution: outofdate
Status: newclosed

I'm going to close this ticket since many of the original issues were fixed. If you are still seeing this in 1.4b19 from beta.adium.im, please file a new ticket.

Note: See TracTickets for help on using tickets.