Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#6516 closed patch (wontfix)

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

Reported by: wehlhard Owned by: deryni
Milestone: Component: XMPP
Version: 2.4.3 Keywords:
Cc: LouCipher, datallah, Root

Description

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

Attachments (1)

jabber_common_name.patch (732 bytes) - added by wehlhard 11 years ago.

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by wehlhard

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by 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).

comment:4 Changed 11 years ago by 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?

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by QuLogic

  • Milestone 2.5.0 deleted

Clearly not going in 2.5.0...

comment:7 Changed 11 years ago by rlaager

  • Resolution set to wontfix
  • Status changed from new to closed

comment:8 Changed 8 years ago by PeterLairo

I'm using Pidgin 2.8.0 on Windows 7 and still keep getting the "Accept certificate from talk.google.com" and am forced to use the unsatisfactory workaround (Pidgin / Account / Advanced / Use old style SSL & Connect Port 443. There must be a better solution than ignoring it and "wontfixing" all the bugs (at least the ones I could find).

BTW: How can I CC myself to a bug?

comment:9 Changed 8 years ago by deryni

Adding a comment automatically CCs you to the ticket but I believe there should also be a CC me link or something on the page as well.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!