GNOME Bugzilla – Bug 639417
SSL server validation should follow override server CancelOk
Last modified: 2011-03-31 06:00:56 UTC
This report was originally filled at: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/675666 I have email for my personal domain which uses a Jabber server with a different domain. If I configure a Jabber account for the user "chris@improbable.org" with the override server "talk.google.com" I will receive an SSL validation error every time I connect telling my that the name on the certificate doesn't match the expected "improbable.org". Either value should be accepted to match user expectations.
In master you can now "save" the certificate exception, so you won't be asked each time any more.
As I understand it, the fact that you can "save" the workaround doesn't actually fix the bug. There are now two problems: 1. As before, new users will think there's an error when there isn't one. 2. Now, unlike before, users will "save" the workaround and silently ignore future SSL errors. SSL errors should be emphasized, not silenced. Isn't Empathy supposed to expect "talk.google.com" and not "improbable.org", as this bug's reporter suggests? There were 25 million Google Apps users out there a year ago. There are surely millions more today. As I understand it, all of them will experience this error.
Stef: can you check this issue please?
Adam is right. Since the TLS X509 authentication is validating a connection to the host, the validation needs to use the hostname being connected to, and not the host part of the identity. I haven't looked at what's going on underneath the covers, but will do so shortly.
I was wrong, the XMPP specs say that the TLS should be validated against the identity of the server, which is the domain part of the user's full id. In any case though, we should be allowing these sort of exceptions to be saved.
(In reply to comment #5) > I was wrong, the XMPP specs say that the TLS should be validated against the > identity of the server, which is the domain part of the user's full id. > > In any case though, we should be allowing these sort of exceptions to be saved. I'd pretty strongly disagree with that last part for the reasons Adams mentioned. However, I'm not sure I see where the TLS specification actually says that - the relevant portion would appear to be http://xmpp.org/rfcs/rfc3920.html#rfc.section.5.1 where point 8 says: "Certificates MUST be checked against the hostname as provided by the initiating entity (e.g., a user)", which would seem to directly allow this case. Did I miss another reference?
Well in any case, I've fixed the first issue. And that's to allow saving of these sorts of exceptions: http://git.collabora.co.uk/?p=user/stefw/empathy.git;a=commit;h=c3eb5ce5e5c98bfbd6e190b2b1b7eac11d1d160d Guillaume, how does that look?
Looks good. Please merge to master and gnome-2.34.
Stef, awesome folks! thank you
Guillame, merged into master. Can you merge into gnome-2-34? I don't have a whole stack setup with gcr-0 < 2.91.
Done, I backported it to 2.34. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.
Chris Adams, It turns out that in http://xmpp.org/rfcs/rfc3920.html#rfc.section.5.1 the host name being referred to is the one that's part of the user's XMPP JID.
(In reply to comment #11) > Done, I backported it to 2.34. Actually we can't backport it as 2.34 doesn't have the certificates refactoring. I reverted the commit.
(In reply to comment #12) > Chris Adams, It turns out that in > http://xmpp.org/rfcs/rfc3920.html#rfc.section.5.1 the host name being referred > to is the one that's part of the user's XMPP JID. I'm not sure I see that strict of an interpretation, particularly given the fact that the feature in question (a user-provided override) isn't even discussed at all by the spec, but in any case, I think there's a strong argument that the security benefit from not training users to ignore TLS errors is more important: a user wants to know if someone is spoofing their server but by definition already knows that the override hostname which they provided isn't what would be derived from their JID since they would otherwise not have needed to use this feature.
Yeah, I agree that we don't want to be prompting unecessarily. I've posted something to the XMPP group, and will give this more thought as to how we can fix it in telepathy.
A solution for this has been worked on, and is being merged into telepathy-spec, telepathy-gabble, and empathy: https://bugs.freedesktop.org/show_bug.cgi?id=35408 https://bugs.freedesktop.org/show_bug.cgi?id=35410 https://bugs.freedesktop.org/show_bug.cgi?id=35415 bug #645119 bug #643745
*** Bug 646272 has been marked as a duplicate of this bug. ***