Luigi Rizzo <[EMAIL PROTECTED]> writes:
[...]
> 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.
If the encryption and decryption happens in a seperate process, there
are also some security advantages. Encryption code is complex and
difficult to understand, so it's hard to analyze for security bugs.
Isolating this code in a seperate process limits how much damage can
be done in the event of a security problem, such as a buffer overflow.
See:
http://www.openssl.org/news/secadv_20020730.txt
http://www.citi.umich.edu/u/provos/ssh/privsep.html
http://www.suspectclass.com/~sgifford/ucspi-tls/
----Scott.
_______________________________________________
--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
