[asterisk-dev] TLS/SSL futures

[Scott Gifford]

Luigi Rizzo <rizzo at icir.org> 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.