[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 20 13:16:29 CDT 2008

Jonathan Schleifer wrote:
> Am 20.08.2008 um 19:43 schrieb Peter Saint-Andre:
>> That is a very big if.
> What would be the problem with contacting Google?

I posted that to this list. Did you not read what I said?

>> TLS has undergone many many years of cryptanalysis, hacking attempts, 
>> and incremental improvement. One crytpanalysis does not make a secure 
>> protocol.
> Yeah, but that would be a start. Stating it is not several years old and 
> thus can't be good is very, very conservative. We could also say Jabber 
> can't be good because it's not as old, tested and used as IRC…

Non sequitur.

>> Excuse me, but we already "play around" with TLS libs -- unless you 
>> hadn't noticed, that's how we do channel encryption right now, and 
>> every Jabber client under the sun already supports it. It's very 
>> attractive to use the same underlying technology for encryption of 
>> c2s, s2s, and e2e streams (whether the latter are link-local or happen 
>> over TCP, XMPP, or whatever).
> I was talking about c2c here.

And that makes a big difference how?

>> Jonathan, you don't seem to be listening very well. I suggest that you 
>> stop beating the ESessions drum for just a little while and take a bit 
>> of a break to reflect on ekr's posts, read the relevant specs, and 
>> think seriously about how we could have e2e pretty much *today* in all 
>> clients using TLS-over-XMPP, reuse *any* existing TLS library, and 
>> incrementally add new features (e.g., SAS) to TLS if we need them 
>> (thus benefiting the entire Internet community).
> Let me summarize:
> * There is no client using it.

There is one client using ESessions, so ESessions has *infinitely* more 
implementations. That must be good.

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.

> * There is not even a XEP for it yet.

Sure there is. See XEP-0246 and XEP-0247.

> * Clients would need to be able to handle a second stream, that is 
> inside another stream.
> * Some clients may need a lot of changes for that.

And they won't need a lot of changes for ESessions? Please.

> So, how could we have that today? Today, we already HAVE ESessions. :) 

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).

Or maybe we just all need to use Gajim?

> I 
> assume it's at least half a year until we have the FIRST client to 
> implement it. 

Shall we bet on that?

> And then we will the the real world problems that you 
> don't think of in theory, whereas ESessions is already in use in the 
> real world.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/bfb51a86/attachment.bin 

More information about the Security mailing list