Adium

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#8787 closed defect (fixed)

Jabber SSL certificate incorrectly checked against server name

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

Description

This is a regression.

In version 1.2, Adium checks the SSL certificate provided by the Jabber server against the hostname to which it connects, instead of the XMPP domain name.

The resulting behavior is that Adium complains that the SSL certificate does not match the server hostname.

This is incorrect. The SSL certificate is issued against the XMPP domain name, which appears at the right side of a Jabber ID and can be different from the server hostname when DNS SRV records are in use.

Previous versions of Adium (up to 1.1.x) did the right thing, by checking the SSL certificate against the XMPP domain name.

(interestingly, iChat has the same bug -- which has been reported to apple since iChat supports Jabber)

Change History (26)

comment:1 Changed 12 years ago by Evan Schoenberg

Previous versions of Adium did not check SSL certificates at all.

I also don't think that the right side of the Jabber ID is necessarily the right thing to use; one can connect with an @jabber.org address to many non-jabber.org servers.

comment:2 Changed 12 years ago by Kena

evands,

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

comment:3 Changed 12 years ago by Kena

By the way, the guys at Psi IM had the same discussion a while ago: http://forum.psi-im.org/thread/2632

Now Psi is doing like the RFC says and that is good :)

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

Besides --

Replying to evands:

one can connect with an @jabber.org address to many non-jabber.org servers.

That is essentially non-true. The xmpp protocol forbids this.

Or maybe you are referring to the ability of a Jabber user to browse and use services on other Jabber servers than their primary server? I think this is not relevant to the point I raise in the initial bug description.

comment:5 in reply to:  4 ; Changed 12 years ago by Evan Schoenberg

Replying to kena:

Besides --

Replying to evands:

one can connect with an @jabber.org address to many non-jabber.org servers.

That is essentially non-true. The xmpp protocol forbids this.

Yeah, I thought it was non-true, too... but what do we do about 8698#comment:6 then?

comment:6 Changed 12 years ago by Evan Schoenberg

Owner: changed from nobody to Andreas Monitzer

comment:7 in reply to:  5 Changed 12 years ago by Kena

Replying to evands:

Replying to kena:

Besides --

Replying to evands:

one can connect with an @jabber.org address to many non-jabber.org servers.

That is essentially non-true. The xmpp protocol forbids this.

Yeah, I thought it was non-true, too... but what do we do about 8698#comment:6 then?

Well, I'd like to push the person sustaining this discussion to get more evidence. I believe we're looking at a non-issue.

comment:8 in reply to:  2 ; Changed 12 years ago by Andreas Monitzer

Replying to kena:

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

Hmm I didn't know about that. This is bad, it means that we either have to do it right, or support gtalk. You can (have to) set up Google for domains using SRV entries so that Adium can connect to it just by supplying your JID. However, you always get the certificate for talk.google.com, which is the wrong one when following the RFC.

The only workaround I can think of is that in these cases we require the users to supply talk.google.com as the connect server in the options tab, using the server's name when we have that, and using the domain-part of the JID otherwise. This would have to be implemented in libpurple ASAP somehow.

comment:9 in reply to:  8 ; Changed 12 years ago by Kena

Replying to am:

Hmm I didn't know about that. This is bad, it means that we either have to do it right, or support gtalk.

Or, you could do like iChat is doing, by separating google talk from "regular" jabber, with the following constraints:

1) google talk accounts are forced to connect to talk.google.com

2) google talk accounts have their own certificate check policy

comment:10 Changed 12 years ago by Carlos Morales

Milestone: Adium X 1.2.1

this goes into Milestone 1.2.1 right? Am or evands, please correct me if I'm wrong.

comment:11 Changed 12 years ago by Andreas Monitzer

Probably not 1.2.1, because we have to wait at least until the next libpurple release.

comment:12 Changed 12 years ago by Evan Schoenberg

If the fix is a diff which we can apply against libpurple 2.3.1, we can roll it into our build easily if you want.

comment:13 Changed 12 years ago by Andreas Monitzer

Fixed in libpurple version 6227c43549bf66022512f18bb36d70b7c57c4430. Leaving this open for evands to back-port into the version Adium is using.

comment:14 Changed 12 years ago by Carlos Morales

I just love the libpurple DCS versions.

comment:15 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: newclosed

(In [22193]) libpurple 2.3.1 with patches as of [22189] which includes im.pidgin.pidgin 6227c43549bf66022512f18bb36d70b7c57c4430 to fix jabber cert checking to use the domain of the JID. Fixes #8787

comment:16 Changed 12 years ago by Evan Schoenberg

(In [22194]) Merged [22189] and [22193]: libpurple 2.3.1 with patches as of [22189] which includes im.pidgin.pidgin 6227c43549bf66022512f18bb36d70b7c57c4430 to fix jabber cert checking to use the domain of the JID. Fixes #8787

comment:17 in reply to:  9 Changed 12 years ago by Peter Saint-Andre

Replying to kena:

Replying to am:

Hmm I didn't know about that. This is bad, it means that we either have to do it right, or support gtalk.

Or, you could do like iChat is doing, by separating google talk from "regular" jabber, with the following constraints:

1) google talk accounts are forced to connect to talk.google.com

2) google talk accounts have their own certificate check policy

I posted a long message about this to the adium-devl discussion list. /psa

comment:18 Changed 12 years ago by Jorj Bauer

I question your conclusions in this thread.

The RFC specifically states that it's the *hostname* to which the client asked to connect, not the XMPP domain. So this would have to match the *connect server* and NOT necessarily the RHS of the JID.

If a client implements their connection such that the RHS is used specifically as the hostname to which they connect, then under that specific condition it is true that you would want to check against the RHS. But if the end-user provides the hostname as a connect server (as Adium allows) then that would be what is checked.

The RFC is crystal clear: it's the "hostname as provided by the initiating entity (e.g., a user)". And when a connect server is provided, that's the hostname. The other thing is just the domain part of a JID, and is clearly not a hostname.

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

... and having just seen that PSA commented, listen to whatever he said on the adium-devel list. :)

comment:20 Changed 12 years ago by oliverhumpage

This problem has really bitten me and my users - surely (as jorj said) if you ask a client to connect to a hostname using SSL, it should check the SSL cert against that hostname rather than any part of a username which you might then pass over the SSL connection.

Could there at least be an option somewhere to choose which name (hostname or XMMP domain) is used against the SSL cert? I have a valid, real, paid-for SSL cert for my jabber.domain.com server, but since Adium now wants the cert to be for just domain.com (since user@… is the username format) it complains on every connection.

comment:21 Changed 12 years ago by Andreas Monitzer

This is already implemented. Once Adium 1.2.1 is out and you're rolling it out, you have to advise your user to enter the correct jid, and in addition fill out the hostname as jabber.domain.com in the options tab.

comment:22 in reply to:  21 Changed 12 years ago by oliverhumpage

Thank you, I wasn't sure from the above discussion what conclusion had been gotten to. Looking forward to 1.2.1 :)

comment:23 Changed 12 years ago by Evan Schoenberg

Milestone: Adium X 1.2.1Adium X 1.2.2

comment:24 Changed 12 years ago by Evan Schoenberg

Milestone: Adium X 1.2.2Adium X 1.2.1

comment:25 Changed 12 years ago by Dax Kelson

Having to fill out the hostname in the "Connect Server" box completely defeats the purpose of the SRV record. When libpurple didn't support SRV records, you had to specify the "Connect Server". Having hacks for specific services "to do the right thing" is unspeakably ugly (re Google Talk).

Can anyone give any practical or security related benefits to the RFC specified behavior?

If not, then don't blindly follow the RFC over a cliff and revert this monstrosity. RFCs have been wrong before.

comment:26 Changed 12 years ago by Andreas Monitzer

You don't have to fill out that field, only when you server's certificate is broken in a certain way (uses a CN different from your jabber id host part). There's nothing I can do about that, your other option is to disable certificate verification altogether.

The RFC is quite logical in that part, no need to break it. Especially when it means that users of RFC-abiding servers would get a nag screen every time they connect.

Additionally, using the name resolved from the SRV records for the CN check would mean that it'd be trivially easy to do a man-in-the-middle-attack, which quite defeats the purpose of certificate checking.

Note: See TracTickets for help on using tickets.