[jitsi-dev] SSL cert common matched against ID domain even if Connect Server provided


#1

I opened JITSI-1029 on recommendation from someone in #jitsi - sorry for bypassing protocol :slight_smile:

When connecting to ejabberd, the common name returned is matched against the domain part of the jabber ID even if a Connect Server is provided in the Connection tab.

ID: user@name.com
Connect Server: ssl.someprovider.com

I would expect that the common name of the certificate should match ssl.someprovider.com, but Jitsi reports that it does not match name.com.
If no Connect Server is provided, then naturally it would default to the domain of the jabber ID.

Cheers,
Ben


#2

Hey Ben,

I opened JITSI-1029 on recommendation from someone in #jitsi

Ah ok. That would be ok ... (if the person was a Jitsi developer).

Do you happen to remember the nick?

That said the following is still worth a discussion.

- sorry for
bypassing protocol :slight_smile:

When connecting to ejabberd, the common name returned is matched against
the domain part of the jabber ID even if a Connect Server is provided in
the Connection tab.

ID: user@name.com
Connect Server: ssl.someprovider.com

I would expect that the common name of the certificate should match
ssl.someprovider.com, but Jitsi reports that it does not match name.com.
If no Connect Server is provided, then naturally it would default to the
domain of the jabber ID.

I am not so sure about that. The idea is that generally users expect to
log into a server that's responsible for the domain part of their id, so
that's what we try to check when logging. We consider any other case to
warrant a warning.

Any references (e.g. RFCs) that would recommend the contrary?

Cheers,
Emil

路路路

On 25.03.12 12:00, Ben Dechrai wrote:

--
http://jitsi.org


#3

Hi,

I can't remember the nick and am at another machine, so no logs. He or she referred to the devs in the third-person and submitted a ticket at around the same time, so I assume not a dev.

I am not so sure about that. The idea is that generally users expect to
log into a server that's responsible for the domain part of their id, so
that's what we try to check when logging. We consider any other case to
warrant a warning.

This would require an IP address and jabber daemon for every domain though. I run an ISP and offer jabber services on one domain (orange.securityprotected.net), and have a number of domains using that service.

I would expect under normal circumstances that if I logged in as ben@dechrai.com to be checked against dechrai.com, but as I have overridden the Connect Server to orange.securityprotected.net, would now expect the SSL check to be done against orange.securityprotected.net.

The other option would be to check the certificate against the SRV record and then I'd use

_xmpp-client._tcp.dechrai.com. 900 IN SRV 5 0 5222 orange.securityprotected.net.

Any references (e.g. RFCs) that would recommend the contrary?

Nope, just going on a hunch based on the fact I've not had SSL cert errors with any other jabber client that I've tried.

Cheers,
Ben


#4

Hey

I am not so sure about that. The idea is that generally users expect
to
log into a server that's responsible for the domain part of their id,
so
that's what we try to check when logging. We consider any other case
to
warrant a warning.

This would require an IP address and jabber daemon for every domain
though. I run an ISP and offer jabber services on one domain
(orange.securityprotected.net), and have a number of domains using that
service.

Ahm, no. This is true for HTTP where TLS negotiation happens before any data from the client is sent to the server. But XMPP uses STARTTLS (upgrade of an existing TCP connection to TLS). The client supplies his from address before the TLS upgrade and the server can select the matching certificate based on that address.

I would expect under normal circumstances that if I logged in as
ben@dechrai.com to be checked against dechrai.com, but as I have
overridden the Connect Server to orange.securityprotected.net, would now
expect the SSL check to be done against orange.securityprotected.net.

We have such a comparison set up for SIP, but I'd rather prefer to avoid it as all XMPP clients are required to support SRVs in the subjectAlternativeName. With that, it is possible to separate certificate based on their intended usage. A certificate issued for _xmpp-client.example.com cannot be used for anything else. A potential customer of yours could therefore submit you a certificate for this SRV, but you fake his website, issued to example.com and www.example.com

The other option would be to check the certificate against the SRV
record and then I'd use

_xmpp-client._tcp.dechrai.com. 900 IN SRV 5 0 5222
orange.securityprotected.net.

The comparison against SRVs is implemented in Jitsi, but then again the check is made against _xmpp-client.dechrai.com and not orange.securityprotected.net (because DNS is an unreliable source, DNSSEC left aside).

Any references (e.g. RFCs) that would recommend the contrary?

Nope, just going on a hunch based on the fact I've not had SSL cert
errors with any other jabber client that I've tried.

Could you name a few please? Because last time I was using some I got a warning for my Google Web Apps account: such hosted accounts at Google face the exact same problem. The certificate presented by Google is for gmail.com for world-wide users, googlemail.de for German users (because of a stupid lawsuit that forbids them the use of gmail) and talk.google.com for all hosted domains. The servers behind however are all hosted at talk.google.com (take a look the SRVs). So Google uses the 'from'-info as mentioned above.

Cheers,
Ben

Regards,
Ingo


#5

Hi all,

Just wondering if anything came of this? I've now added another domain to my ejabberd instance for very non-technical users, and trying to explain that this is the easiest and most secure form of video chat available to them is hard when they get certificate mismatch warnings.

Further to your suggestion that users are expected to log in to a server responsible for the domain part of their ID, you could argue the same for email. Many providers use the full email address as the username, in particular if they host email for many domains. The IMAP or SMTP server will be secured using a certificate on the servername, rather than one certificate per domain for which the provider hosts email.

Ultimately, though, I think that making this change, to match the certificate with the server name, and not the domain part of the user ID, will cause no noticeable effect to those who don't experience issues right now, where the server name defaults to the domain of the user ID, while allowing those who virtually host their jabber ID on another server to authenticate without warning. I don't see any security concern, because the user will be specifically choosing to connect to a server other than the domain part of their ID, and hence to find a certificate matching the server name.

I'm still keen to discuss this if you are.

Cheers,
Ben

路路路

On Mon, 26 Mar 2012 09:36:46 +1100, Ben Dechrai wrote:

Hi,

I can't remember the nick and am at another machine, so no logs. He
or she referred to the devs in the third-person and submitted a ticket
at around the same time, so I assume not a dev.

I am not so sure about that. The idea is that generally users expect to
log into a server that's responsible for the domain part of their id, so
that's what we try to check when logging. We consider any other case to
warrant a warning.

This would require an IP address and jabber daemon for every domain
though. I run an ISP and offer jabber services on one domain
(orange.securityprotected.net), and have a number of domains using
that service.

I would expect under normal circumstances that if I logged in as
ben@dechrai.com to be checked against dechrai.com, but as I have
overridden the Connect Server to orange.securityprotected.net, would
now expect the SSL check to be done against
orange.securityprotected.net.

The other option would be to check the certificate against the SRV
record and then I'd use

_xmpp-client._tcp.dechrai.com. 900 IN SRV 5 0 5222
orange.securityprotected.net.

Any references (e.g. RFCs) that would recommend the contrary?

Nope, just going on a hunch based on the fact I've not had SSL cert
errors with any other jabber client that I've tried.

Cheers,
Ben


#6

Hey Ben,

Hi all,

Just wondering if anything came of this?

Have you checked the archives?

http://goo.gl/Pi8lG

People do not generally get an indication as to whether or not you are
subscribed to the mailing list so they would not necessarily CC you in
their responses. You may hence want to subscribe at least during the
discussions you are interested or at least go back to the archives
regularly.

Cheers,
Emil

路路路

On 26.04.12 06:11, Ben Dechrai wrote:

I've now added another domain
to my ejabberd instance for very non-technical users, and trying to
explain that this is the easiest and most secure form of video chat
available to them is hard when they get certificate mismatch warnings.

Further to your suggestion that users are expected to log in to a
server responsible for the domain part of their ID, you could argue the
same for email. Many providers use the full email address as the
username, in particular if they host email for many domains. The IMAP or
SMTP server will be secured using a certificate on the servername,
rather than one certificate per domain for which the provider hosts
email.

Ultimately, though, I think that making this change, to match the
certificate with the server name, and not the domain part of the user
ID, will cause no noticeable effect to those who don't experience issues
right now, where the server name defaults to the domain of the user ID,
while allowing those who virtually host their jabber ID on another
server to authenticate without warning. I don't see any security
concern, because the user will be specifically choosing to connect to a
server other than the domain part of their ID, and hence to find a
certificate matching the server name.

I'm still keen to discuss this if you are.

Cheers,
Ben

On Mon, 26 Mar 2012 09:36:46 +1100, Ben Dechrai wrote:

Hi,

I can't remember the nick and am at another machine, so no logs. He
or she referred to the devs in the third-person and submitted a
ticket
at around the same time, so I assume not a dev.

I am not so sure about that. The idea is that generally users expect
to
log into a server that's responsible for the domain part of their
id, so
that's what we try to check when logging. We consider any other case
to
warrant a warning.

This would require an IP address and jabber daemon for every domain
though. I run an ISP and offer jabber services on one domain
(orange.securityprotected.net), and have a number of domains using
that service.

I would expect under normal circumstances that if I logged in as
ben@dechrai.com to be checked against dechrai.com, but as I have
overridden the Connect Server to orange.securityprotected.net, would
now expect the SSL check to be done against
orange.securityprotected.net.

The other option would be to check the certificate against the SRV
record and then I'd use

_xmpp-client._tcp.dechrai.com. 900 IN SRV 5 0 5222
orange.securityprotected.net.

Any references (e.g. RFCs) that would recommend the contrary?

Nope, just going on a hunch based on the fact I've not had SSL cert
errors with any other jabber client that I've tried.

Cheers,
Ben

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#7

Hi Emil,

It honestly hadn't occurred to me to join the list - something for me to
remember in future.

Thanks to Ingo's comment on STARTTLS, I noticed I was still using the
old TLS and I've resolved my issue and learned something new... thanks Ingo!

In response to the clients that don't give me errors; Pidgin and Adium
(although Adium might have an 'ignore invalid cert' option - can't
remember, and don't use it any more).

As you say, this was a configuration issue, not an implementation one,
and I thank you all for your time in helping me. I have not subscribed
to the dev list.

Cheers,
Ben

路路路

On 26/04/12 14:57, Emil Ivov wrote:

Hey Ben,

On 26.04.12 06:11, Ben Dechrai wrote:

Hi all,

Just wondering if anything came of this?

Have you checked the archives?

http://goo.gl/Pi8lG

People do not generally get an indication as to whether or not you are
subscribed to the mailing list so they would not necessarily CC you in
their responses. You may hence want to subscribe at least during the
discussions you are interested or at least go back to the archives
regularly.

Cheers,
Emil

I've now added another domain
to my ejabberd instance for very non-technical users, and trying to
explain that this is the easiest and most secure form of video chat
available to them is hard when they get certificate mismatch warnings.

Further to your suggestion that users are expected to log in to a
server responsible for the domain part of their ID, you could argue the
same for email. Many providers use the full email address as the
username, in particular if they host email for many domains. The IMAP or
SMTP server will be secured using a certificate on the servername,
rather than one certificate per domain for which the provider hosts
email.

Ultimately, though, I think that making this change, to match the
certificate with the server name, and not the domain part of the user
ID, will cause no noticeable effect to those who don't experience issues
right now, where the server name defaults to the domain of the user ID,
while allowing those who virtually host their jabber ID on another
server to authenticate without warning. I don't see any security
concern, because the user will be specifically choosing to connect to a
server other than the domain part of their ID, and hence to find a
certificate matching the server name.

I'm still keen to discuss this if you are.

Cheers,
Ben

On Mon, 26 Mar 2012 09:36:46 +1100, Ben Dechrai wrote:

Hi,

I can't remember the nick and am at another machine, so no logs. He
or she referred to the devs in the third-person and submitted a
ticket
at around the same time, so I assume not a dev.

I am not so sure about that. The idea is that generally users expect
to
log into a server that's responsible for the domain part of their
id, so
that's what we try to check when logging. We consider any other case
to
warrant a warning.

This would require an IP address and jabber daemon for every domain
though. I run an ISP and offer jabber services on one domain
(orange.securityprotected.net), and have a number of domains using
that service.

I would expect under normal circumstances that if I logged in as
ben@dechrai.com to be checked against dechrai.com, but as I have
overridden the Connect Server to orange.securityprotected.net, would
now expect the SSL check to be done against
orange.securityprotected.net.

The other option would be to check the certificate against the SRV
record and then I'd use

_xmpp-client._tcp.dechrai.com. 900 IN SRV 5 0 5222
orange.securityprotected.net.

Any references (e.g. RFCs) that would recommend the contrary?

Nope, just going on a hunch based on the fact I've not had SSL cert
errors with any other jabber client that I've tried.

Cheers,
Ben