[Security] TLS Certificates Verification
stpeter at stpeter.im
Wed Aug 20 13:37:36 CDT 2008
Jonathan Schleifer wrote:
> 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 real
>> Sure there is. See XEP-0246 and XEP-0247.
> Sorry? There is ABSOLUTELY nothing about TLS. Or I'm blind.
It's just XML streams as in RFC 3920, with possibly a different
underlying transport. Upgrade via STARTTLS and you're done.
But I'll add some examples about that.
>> And they won't need a lot of changes for ESessions? Please.
> Not when using Brendan Taylors library, no.
Where can this magical library be downloaded? As I understand it, he's
offered to write a C library, but he hasn't done so yet.
> For XML Stream in XML, I'm
> pretty sure some clients might even need changes to the XMPP parser core.
So let's take a poll of client developers then.
>> 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 :).
So all clients but one will need to be modified. Better for you, but not
necessarily better for all the client developers.
We tried to get developers interested in ESessions. Only one client
added support, thanks to the Google Summer of Code and the strong work
by Brendant Taylor. Every other client developer I approached said "oh
ESessions is hard, I need to do all that math and crypto stuff in my
client, but I'm just a Jabber developer who's accustomed to XMPP so I'd
rather use something that enables me to re-use an existing library". And
XTLS enables developers to do just that.
>> 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
Well, to make it a fair bet, we'd need to see how long it took Brendan's
GSoC 2007 code to make it into a released version of Gajim. Was it first
included in Gajim 0.12? If so that was about a year before release. And
in fact Gajim 0.12 is still alpha, so that's not an official release:
So half a year isn't right, let's bet on 1 year.
>> 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?
Because it works.
> 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…
Adducing mcabber as the model for a Jabber client is a bit misleading.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/eb7a4190/attachment.bin
More information about the Security