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 _______________________________________________ --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
