[Bug 36215] Support client certificates on XMPP connections

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36215

--- Comment #1 from Stef Walter <stefw at collabora.co.uk> 2011-04-13 10:19:53 PDT ---
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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.