Change what Jabber checks for in the X.509 common name

[wehlhard]

I pulled this out of #6500 so it can be checked separately.

[deryni]

I'm not sure this patch is correct. The relevant section of the RFC (and a similar section in the bis draft) seem only to indicate that the DNS SRV (or similar) results for the hostname must never be used and that the hostname provided by the client must be. Both the jid domain and the connect server are provided by the user, so I'm pretty sure that checking the connect_server is acceptable.

That being said the case could be made that we should likely only check the connect server when the connect server is not an IP address.

[deryni]

So in discussing this some in the devel@ muc room it was decided that it is ok to check the connect server but that we should not be checking IP addresses (whether specified by the connect server or the jid domain).

(12:33:36) stpeter: but back to 6516
(12:34:04) stpeter: ok
(12:34:23) stpeter: so *if* the user configures in a connect server then it's ok to check that
(12:35:14) stpeter: however I agree that you would not check the connect server (or the xmpp-domain either) if it's an IP address, because certs are not issued for IP addresses
(12:36:46) mark.doliner: If the domain has an SRV record and no connect server has been specified, should the certificate be checked using the domain name or using the SRV name?
(12:37:52) stpeter: brb
(12:47:23) stpeter: mark.doliner: the domain of the user's JID, because DNS can be poisoned
(12:47:38) stpeter: so you can't really trust the SRV records
(12:47:55) stpeter: at least according to the security mafia :)
(12:49:10) elb: well, aside from DNS's poisoning or not, it's not a cryptographically secured relationship
(12:50:04) stpeter: elb: correct

So instead of the patch as it currently stands we need to check the connect server both for existance and for being a hostname and use that if it exists, otherwise just use the jid domain.

[LouCipher]

The ability in Pidgin for the user to specify a connect server different than the JID domain seems to be outside the scope of the RFC. Therefore, I believe that either:

* the user specified connect server specified should not be used, or
* the user specified connect server specified could be used as a fallback, in case the domain does not match

The existing behavior is to use the user specified connect server or the SRV record in preference over the JID domain. Both seem to contradict the RFC (and the SRV record checking is insecure, as mention above).

[deryni]

As I said I don't think the RFC indicates any method by which the user need provide the hostname only that the hostname provided by the user MUST be used and not the hostname retrieved via DNS SRV lookup. In that spirit my best reasoning about this (and stpeter's as well, as indicated by the chatroom log I posted) is that the connect server should most certainly be treated as a 'hostname as provided by the initiating entity' and not as one 'resolved via the Domain Name System' and as such should be checked.

Also as I indicated the code needs to be changed to only check the connect server when the connect server is a hostname and not an IP (the common case in all situations I've seen) so that this doesn't break things for people.

Yes, it would be nice to support fallback validation for the domain name if the connect server hostname matching fails (though I'm unsure about the technical correctness of such a mechanism). So to restate, the patch needs to be rewritten to use purple_ip_address_is_valid on the connect server as well as just testing it for existance before using it. Further work to support the fallback list is also welcome. Assuming I finally manage to get some time in the near future I will work on this myself should no one get to this before me.

I don't believe we use the SRV record to check the certificate at the moment, if we do I don't see how your patch fixes that either. Can you show me where you think we do that?

[LouCipher]

I'm not sure why I thought that the SRV response is picked up by the connect_server local variable. So there's no security implication here - my mistake.

[QuLogic]

Clearly not going in 2.5.0...