[Security] TLS Certificates Verification
js-xmpp-security at webkeks.org
Wed Aug 20 13:26:06 CDT 2008
Am 20.08.2008 um 20:16 schrieb Peter Saint-Andre:
> I posted that to this list. Did you not read what I said?
Seems I don't get it…
>> I was talking about c2c here.
> And that makes a big difference how?
As already discussed here, some clients have problems when it's
inbound and not a socket. And they need to handle a stream inside a
stream. Clients who can only handle one connection like mcabber will
very likely miserably fail.
> As to TLS encryption of XML streams, Dirk has support for it in his
> Python code and gloox has some preliminary support (but that was
> experimental, back when we were first talking about "XTLS").
> However, I grant that none of that code is deployed yet.
Then why not depoly it so we actually see how it'll perform in the
> Sure there is. See XEP-0246 and XEP-0247.
Sorry? There is ABSOLUTELY nothing about TLS. Or I'm blind.
> And they won't need a lot of changes for ESessions? Please.
Not when using Brendan Taylors library, no. For XML Stream in XML, I'm
pretty sure some clients might even need changes to the XMPP parser
> You do in Gajim. I don't in Psi, Adium, Exodus, Trillian, Pidgin, or
> any other codebase. But all of those codebases support TLS and most
> of them are adding Jingle support, thus enabling negotiation of end-
> to-end streams, then you just upgrade the stream via STARTTLS. That
> seems like a lot less work than building ESessions support into all
> the clients (and no it's not as easy as dropping in a library,
> because you know that's not how Gajim functions today -- Brendan's C
> lib is just a promise, not a reality).
Yeah, and none of them supports XTLS, so how is that better? :)
> Or maybe we just all need to use Gajim?
No, that's not an option. The solution is to add support to other
clients as well :).
> Shall we bet on that?
Sure, I'm pretty sure no client has a stable release in a half year
that supports it. Not even an alpha. Maybe in SVN and very unstable,
but not more.
> And deployment of TLS is merely theoretical? Yes it is for end-to-
> end XML streams (so far), but it's not for client-to-server streams
> or server-to-server streams, and extending that model to e2e streams
> seems quite reasonable.
Why you keep mentioning c2s TLS again and again? This is totally
different. That doesn't need another stream. That doesn't need jingle.
That doesn't need the client to handle multiple XML streams at once.
Etc., etc., etc.
For example, mcabber can only handle one XML stream at once and IIRC,
it is not easy to fix that. How should XTLS be done there? ESessions
would be possible…
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: This is a digitally signed message part
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/892bb9bb/attachment.pgp
More information about the Security