741550 - Fix SSL cert hostname check for Jabber/XMPP

Status: RESOLVED DUPLICATE of bug 787369

(Chat Core :: XMPP, defect)

Description

[Ben Bucksch (:BenB)]

Situation:
* User jabber:[e-mail] has Jabber domain web.de.
* The hostname of the server for web.de is xmpp.web.de.
* The SSL certificate for server xmpp.web.de is on the name "web.de", not "xmpp.web.de".
  This is due to DNS SRV, but affects us even if we don't use DNS SRV.

Problem:
If you use nsISocketTransport and pass "xmpp.web.de" as hostname and turn on SSL, the SSL cert check will fail.

Cause:
nsISocketTransport assumes that the SSL cert name must match the hostname we connect to. That's true for HTTP, but not for XMPP.

Workaround:
Pass "web.de" as hostname and "xmpp.web.de" as proxy hostname. That will make nsISocketTransport connect to "xmpp.web.de", but check the cert against the name "web.de".
Downside: no proxy support anymore.

Alternatively, we could fix NSS and nsISocketTransport. I recommend to use the workaround first (as we can do that right away), then fix NSS (which will take a while), and then use the new NSS/nsISocketTransport API as soon as it's available.

Comment 1

[Neustradamus]

Ben, you can note that it is not jabber:[e-mail] but xmpp:[e-mail] ;)

Comment 2

[Eliot Lear]

Nice that you've added Jabber.  Unfortunately, this bug really should have blocked Bug 735215.

Let me explain the impact of this bug: any production XMPP service is hosted on no fewer than about six servers.  This bug puts the server in the unfortunate position of not knowing which certificate it should return.  For any other XMPP client it needs to return the matching hostname for the rhs of the @ in the jid.  For T-Bird, it's the server name.  Show me a CA that will do that for altSubjectName, and if they did one should be concerned.

Can someone please explain how hard it is to do an SRV query in your codebase?  As was pointed out in Bug 735215, you've already done it for MX.  Maybe if I could be pointed at the appropriate MX routine I could copy over the right code?

Comment 3

[Patrick Cloke [:clokep]]

(In reply to Eliot Lear from comment #2)
> Can someone please explain how hard it is to do an SRV query in your
> codebase?  As was pointed out in Bug 735215, you've already done it for MX. 
> Maybe if I could be pointed at the appropriate MX routine I could copy over
> the right code?

I think you misread, it uses a web service:
(In reply to Ben Bucksch (:BenB) from bug 735215, comment #17)
> In the mail account setup wizard, we needed DNS MX. We had the same problem
> as here, and decided to use a web service (and switch to client-side DNS
> requests as soon as it's possible in Mozilla).
DNS SRV support is a slightly different issue then this bug, please see bug 14328.

Comment 4

[Jules Blok]

I am also affected by this bug. Even when using libpurple in Instantbird that supports DNS SRV records it will only accept a certificate that matches the server domain while XMPP specifies the certificate should match the account domain.

This also happens when connecting directly to the server. I would advise to check the account domain in all cases, both in DNS SRV redirects and connecting directly to a server. This is according to the standard and makes it easier to live with the lack of DNS SRV support in Thunderbird.

Comment 5

[Jules Blok]

The correct behavior is specified in RFC3920 in section 1.5.8:
 
>   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 6

[aleth [:aleth]]

(In reply to Jules Blok from comment #4)
> I am also affected by this bug. Even when using libpurple in Instantbird

For the record, the error message is
Error: Handshake failed  (-8179)
Source File: http://hg.instantbird.org/instantbird/raw-file/94b13a23dac6/purple/libpurple/ssl-nss.c
Line: 332
nss: ssl_nss_handshake_cb

Comment 7

[Florian Quèze [:florian]]

(In reply to Jules Blok from comment #4)
> I am also affected by this bug. Even when using libpurple in Instantbird
> that supports DNS SRV records it will only accept a certificate that matches
> the server domain

Are you sure you haven't specified a value in the "Connect server" advanced option?

Comment 8

[Jules Blok]

At first I didn't specify it but later for testing purposes I did. When I removed that option again today InstantBird kept crashing, I removed the account and added it again and suddenly the handshake worked correctly for once.

But now I get the constant crashes again, from the reports it looks like a null pointer is being freed. There are no InstantBird crash reports or any dumps to send. I'll look into the problem further.

Comment 9

[Florian Quèze [:florian]]

(In reply to Jules Blok from comment #8)

> from the reports it looks like a
> null pointer is being freed. There are no InstantBird crash reports or any
> dumps to send.

I'm confused by you saying these 2 sentences at once. Are there crash reports to look at or not?

Comment 10

[Jules Blok]

Attachment: crash_report.txt

Sorry I forgot to mention that the report that said that a null pointer was being freed is the Mac OS X crash dialog. But it doesn't provide a stack trace or anything like that.

Comment 11

[Jules Blok]

Oh wait, it does, I just looked over it.

Comment 12

[Ben Bucksch (:BenB)]

Jules, could you please file a new bug about the crash and discuss there?
This one here is an important API design problem, and I don't want it clobbered with other discussion.

Comment 13

[Jules Blok]

I'm still affected by this problem:

> Error: Handshake failed  (-8179)
> Source File: http://hg.instantbird.org/instantbird/raw-file/94b13a23dac6/purple/libpurple/ssl-nss.c
> Line: 332
> nss: ssl_nss_handshake_cb

Comment 14

[Jules Blok]

This is on InstantBird 1.5 and happens both with and without a server address specified.

I've already confirmed in the past that changing the certificate to one that matches the server address fixes the problem. It should be checking the account domain instead as explained above.

Thunderbird is also affected by this problem. When using Thunderbird I am able to add an exception as outlined here: http://askubuntu.com/questions/196107/unable-to-connect-to-xmpp-account-with-thunderbird

Comment 15

[Ben Bucksch (:BenB)]

Jules, please use another bug to track your issue. The issue here is a serious design problem that can only be fixed with changes to the NSS APIs. Please keep this ticket focused on the design problem, not particular instances of problems. Thanks.

Comment 16

[Jules Blok]

I don't have any special instance of this problem, the previous crash I mentioned was resolved. Now I'm just affected by this design flaw.

Comment 17

[Ben Bucksch (:BenB)]

I've filed bug 989674. Jules, please discuss there and not here.

Comment 18

[Ben Bucksch (:BenB)]

RFC 3920, Section 5.1, point 8 <http://xmpp.org/rfcs/rfc3920.html>:
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".