Jabber SSL certificate incorrectly checked against server name

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.

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

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

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.

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?

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.

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.

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

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

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

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.

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

I just love the libpurple DCS versions.

(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

(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

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

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.

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

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@domain.com is the username format) it complains on every connection.

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.

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

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.

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.