[MINA 3] SSL/TLS handling

[Emmanuel Lecharny <el...@gmail.com>]

Hi guys,

so after some readings, and some thoughts, I'm coming with a proposal 
for the SSL/TLS handling in MINA 3.

First of all, as we decided to get rid of the SSL filter, everything 
must be handled directly on the SelectorProcessor. That means we must 
have a way to tell the processor worker that the session will be 
secured, and how to handle the handshake and the data encryption.

1) SSLContext
We need to provide a SSLContext instance to be able to generate the 
SSLEngine in charge of the handshake handling and data wrapping. This 
SSLContext should be injected either when we create the service, or 
later directly in a session if we want to mutate a normal connection to 
a secured connection (TLS). So we will allow the developer to inject a 
SSLContext instance when he creates the service, and this will be the 
default SSLContext, or if the service is declared as secured, and if the 
developer hasn't provided any SSLContext instance, we will provide a 
default one, and last case, when a session must be secured, we should 
allow the user to use either a SSLContext instance he provide, or use 
the default one.

2) SSLHelper
Once the SSLContext instance is present, we will create a session 
instance of a SSLHelper class. Like in MINA 2, this instance will store 
the session's SSLEngine instance, and some helper methods. It will be 
stored into the session's attribute

3) Handshake handling
As soon as we have set the 'secured' flag for the session (it can be 
when we create a new session, inheriting this flag from the service, or 
when we switch from a normal session to a secured session), then we 
switch the session's state to 'securing', which means all the received 
data are supposed to belong to the handshake process. If there are some 
pending data waiting to be written, we flush them and don't accept 
anymore. The received data will be considered as part of the handshake 
process, as I said before

Then, until the handshake has been completed (successfully or not), we 
keep the state to securing, and if we got a success, then the session's 
state is switched to connected_secure. If we've got a failure, the 
session is closed.

Now, we can safely encrypt and decrypt the data before sending them to 
the applicatio or writing them into the channel.

I will come with some implementation in the next following days. I may 
improve this description.

Feel free to comment and correct me if anything is either fuzzy or even 
wrong.

Thanks !

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com