[asterisk-dev] TLS/SSL futures

[Luigi Rizzo]

On Sat, Nov 04, 2006 at 11:59:41PM +0100, Olle E Johansson wrote:
> Friends,
> We're in SSL/TLS hell and need a strategy to get to SSL/TLS heaven,  
> if it exists ;-)
> 
> Currently we have many different implementations:
> 
> * John Todd's SSL for manager API in the bug tracker (OpenSSL)
> * The experimental SSL for Manager HTTP server that was committed to  
> svn trunk a bit too early (OpenSSL)
> * Asterisk-netsec uses OpenSSL for midcom
> * iksemel, used for jabber/gtalk, use GnuTLS
> 
> John Todd's code seems to take a more generic approach with the SSL  
> interface broken out
> in separate files.
> 
> Personally I'm not aware on how best to code for SSL/TLS, but I think  
> we need one common strategy
> here for svn trunk.
> 
> I would propose
> 
> * Standardizing on one external library
> * Building an internal module that handles setup of the socket and  
> authentication with certs
> * A common set of configuration options
> * A common configuration file for SSL - to handle certificate store
> 
> We need SSL/TLS for many things - from SIP/TLS to manager, http,  
> fastagi, gtalk, jabber, midcom.
> 
> Any ideas, coders, other thoughts?

Regarding the use of openssl vs gnutls, there isn't much to say.

iksemel is third party software that uses whatever its authors
decided to use, and i don't think anyone has the interest of rewriting
it to use openssl.  On the other hand, it doesn't make sense to
have that decision force asterisk to make the same decisions.  So
iksemel will keep using gnutls if configured to do so, and asterisk
will use whatever asterisk decides to use (and there seems to be
an overwhelming preference for openssl judging from your summary).

Regarding the "different implementations", they are for different
things so there is very little (if any) duplication of effort.

i have posted a comment to http://bugs.digium.com/view.php?id=6812
which gives more details and i invite those interested to read there.

But the bottom line, in my view is that nobody objects to
having a generic, centralized, implementation of encrypted
sockets. unfortunately there isn't one available.

The implementation of ssl-ami in the bug tracker
only works for raw file descriptors but not for e.g. FILE *.
Also, it poses significant mainteinance difficulties as it requires
you to replace calls to the I/O functions (read() and write() etc.)
with your own ssl-aware ones.

The implementation in http.c is only good for FILE * but not for
raw file descriptors; however it has the advantage of
being transparent, hence easy to use and maintain.

Other than playing tricks with the linker (to replace the
system read/write/recv... with our own tls-aware routines),
the other approach would be, for encrypted sockets, to
pass the data to an intermediate thread which does the
encrypted I/O. You cannot do this transparently in the thread
handling the connection after the accept. However, you can still
live with a single thread doing encryption/decryption for all
encrrypted sockets, if you want to limit the number of threads
in the system.

One might argue that given the cost of encryption/decryption,
going through an intermediate thread for the encrypted session
is a negligible overhead, and this is the way to go.

when i have time i will have a look at this approach.

cheers
luigi

> /O
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev