Bug 36215 - Support client certificates on XMPP connections
Summary: Support client certificates on XMPP connections
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2011-04-13 10:19 UTC by Stef Walter
Modified: 2012-02-01 15:25 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Stef Walter 2011-04-13 10:19:20 UTC
Support client certificates on XMPP connections. This would be built around gtls and use its client certificate support.
Comment 1 Stef Walter 2011-04-13 10:19:53 UTC
Some discussion:

<wjt> sjoerd: hey, stefw and i are just chatting about how client certificates might work
* stefw thinks that ServerAuthentication is for server certificates, not necessarily for client ones.
<wjt> *ServerTLSConnection?
<stefw> oops, yeah right, that one :)
<wjt> sjoerd: IIRC you had some ideas about this?
<sjoerd> not about client certificates, we had some ideas about channel binding though
<wjt> sjoerd: i'm not sure at which point the client certificate would get poked into Gabble — a pre-connection ServerAuthentication channel, with Gabble (or Wocky) handling SASL EXTERNAL internally, maybe?
<sjoerd> but that's different
<-- lamalex has quit (Quit: Ex-Chat)
<sjoerd> have an interface on Channel.Type.ServerTLSConnection for it?
 i don't know what the ordering is tbh
<sjoerd> stefw: how do client certificates work, does the server first give you its certificates and then you give it yours or ?
<stefw> no, you start off a handshake with the client certificates.
<sjoerd> right, so client-first
<wjt> yeah, there could be an interface on ServerTLSConnection for it. Either way, we need a way for the CM to know whether or not a UI is going to offer a cert
<stefw> the gtls model is that if you got it wrong, then the handshake happens again.
<wjt> we could have a connection parameter which means “i've got a client cert for this account”
<sjoerd> hrm
<wjt> and then have the ServerTLSConnection channel pop up early with an extra poke-in-a-client-cert method?
<sjoerd> if it's client first it shouldn't be a ServerTLSConnection really
<stefw> sjoerd: no the client certificate is generally requested by the server as part of the handshake
 the server sends the DN's it'll accept.
<sjoerd> because that assume it has the server certificate by the time it pops up
<wjt> that's true
 there could be a new channel type
<stefw> but that's irrelevant, since we should probably use this disconnect-and-try-again model.
<wjt> which could pop up, and if there's no client which handles it MC will Close() it
<sjoerd> nod
<wjt> and then the CM would just start the TLS session without a client certificate
<sjoerd> pop up a channel saying: Do we have client certificates for these DNs and then it pokes it in indeed
<stefw> sjoerd: wjt: but in many cases we won't really know which client certificate to send until a connection has already happened.
<wjt> but if there's a handler for Channel.Type.TLSClientCertificate, that handler can decide yay or nay
<stefw> s/connection/handshake
<wjt> sure, the handshake can start
 and if the server asks for a client cert, we can pop up the channel
 if the channel gets Close()d with no cert, the CM can tell the server “sorry, don't have that”?
<stefw> wjt: technically yes, but if we're going to use gtls that would require changes to the API.
 although we can try and push for those changes.
<sjoerd> stefw: so how does gtls ask for client certificates ?
<stefw> it makes does one handshake, sees that the server wants client certificates, disconnects, then fires off the signal
 when it gets its client certificates, it does another handshake.
<sjoerd> by disconnect do you mean, it closes the tcp connection completely ?
<stefw> yes
<wjt> interesting strategy
<sjoerd> also, makes me sad
<stefw> it seems a bit broken to me
<wjt> and by interesting, i mean broken :)
<stefw> because the server can either request or require client certificates
 the gtls model works okay with 'require'
<wjt> right
<stefw> but not so well with 'request'
<sjoerd> looks like we should fix gtls
<wjt> yeah, i'd vote for fixing gtls
<stefw> yeah, dan said it was very complex
<wjt> and then we could pop up the channels as needed
<stefw> but i think it's worth getting this right.
<sjoerd> nod
<wjt> okay, so this sounds like a plausible strategy

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.