[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 )
</xtls>
</message>
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
hard-coded.
Jakob
[1]
<http://svn.camaya.net/chora/co.php?r=2026&f=trunk%2Fsrc%2Fexamples%2Fe2ee_client.cpp>
[2]
<http://svn.camaya.net/chora/co.php?r=2026&f=trunk%2Fsrc%2Fexamples%2Fe2ee_server.cpp>
[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