[Security] an "XTLS" approach

Jakob Schroeter js at camaya.net
Thu Mar 22 12:36:36 CDT 2007

So here comes a brief description of my "XTLS" proof-of-concept.

I operate GnuTLS in client mode on one end and in server mode on the other 
end. When initiating a handhsake on the client side using anonymous 
(certificate-less) TLS, the optimized [*] flow is similar to the following:

C: handshake_data_1      // this handshake data is wrapped inside the stanza
S: handshake_data_2      // as shown below
C: handshake_data_3
S: handshake_data_4      // at this point the handshake is finished
                         // and the TLS lib announces that to the app
                         // the "XTLS tunnel" is usable
C: encrypted_payload     // also wrapped in stanzas below

[*] GnuTLS twice spits out 3 pieces of handshake data in a row. These can be 
combined and sent in one stanza.

The stanzas I was sending look like this:

<message ...>
  <xtls xmlns='xtls:test'>
    base64( raw_tls_data )

I do not start an additional XML stream here, so I believe this format is 
similar to what is used in ESessions, where all stanza child elements which 
don't contain routing information are encrypted and put in a <c/> element.
The difference seems to be the way the handshake is performed. ESessions do 
that more 'XMPPish'.

The 'client' code is in [1], the 'server' code is in [2]. The TLS backend 
stuff is in [3]. It lacks negotiation which is why 'client' and 'server' are 




[3] <http://svn.camaya.net/chora/browse.php?f=trunk%2Fsrc%2F> tls*.{h,cpp}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/security/attachments/20070322/51a5e3d2/attachment.pgp

More information about the Security mailing list