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
