Re: [MINA 3] SSL
On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. I'm not a big user of SSL/TLS, there is use case like that ? If so we need to take them in account. I think it was the idea of a SSLFilter. We can do that in MINA 3 : - a transport level SSL/TLS engine and the session is opened when the handshake is completed - a filter for the more complex use case (which is going to be a bit more painful) Julien
Re: [MINA 3] SSL
On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. Sure, we need to include TLS in the whole picture. i' going to spend a few days on this matter. I'm not a big user of SSL/TLS, there is use case like that ? Yes. In LDAP, you can communicate through LDAPS (now depracated but still largely used) and using a StartTLS operation (which is supposed to be the way to go). -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] SSL
On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. So, after some more investigation, here is what I'm coming to : - we can't initiate the HS before the session has been created - when we require a secure connection (either by connecting to a SSL server, or by sending the server the information we want to switch to TLS), then until the HS is completed (either successfully, or failing), no other data can be sent to the server (or to the client) - that means we must add a flag in the session that tells we are doing a HS - if we try to send some data on a session which is in the middle of a HS, we will get an error - if we try to secure a connection while we have some pending operation, we will get an error Is that ok ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] SSL
On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharny elecha...@gmail.com wrote: On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. So, after some more investigation, here is what I'm coming to : - we can't initiate the HS before the session has been created - when we require a secure connection (either by connecting to a SSL server, or by sending the server the information we want to switch to TLS), then until the HS is completed (either successfully, or failing), no other data can be sent to the server (or to the client) - that means we must add a flag in the session that tells we are doing a HS - if we try to send some data on a session which is in the middle of a HS, we will get an error - if we try to secure a connection while we have some pending operation, we will get an error Is that ok ? Maybe we could simply wait for queue to be empty and send an error for any write during the handshake (a bit like we do for close) ?
Re: [MINA 3] SSL
On 11/24/11 4:16 PM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. So, after some more investigation, here is what I'm coming to : - we can't initiate the HS before the session has been created - when we require a secure connection (either by connecting to a SSL server, or by sending the server the information we want to switch to TLS), then until the HS is completed (either successfully, or failing), no other data can be sent to the server (or to the client) - that means we must add a flag in the session that tells we are doing a HS - if we try to send some data on a session which is in the middle of a HS, we will get an error - if we try to secure a connection while we have some pending operation, we will get an error Is that ok ? Maybe we could simply wait for queue to be empty and send an error for any write during the handshake (a bit like we do for close) ? It could be optionnal. The pb on the client side is that we have no idea if we will receive some data from the server other than the one used by the HS. We may have long pending read that can interfer with the HS : there is little we can do in this case, but to fail during the HS (ie, everything we read is supposed to be used by the SslEngine to terminate the HS). On the remote side, if we receive a TLS request, we could either empty the write queue, and then start the HS, or generate an error if the queue is not empty, or wait until the queue is empty to start the HS. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [MINA 3] SSL
On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 11/24/11 4:16 PM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. So, after some more investigation, here is what I'm coming to : - we can't initiate the HS before the session has been created - when we require a secure connection (either by connecting to a SSL server, or by sending the server the information we want to switch to TLS), then until the HS is completed (either successfully, or failing), no other data can be sent to the server (or to the client) - that means we must add a flag in the session that tells we are doing a HS - if we try to send some data on a session which is in the middle of a HS, we will get an error - if we try to secure a connection while we have some pending operation, we will get an error Is that ok ? Maybe we could simply wait for queue to be empty and send an error for any write during the handshake (a bit like we do for close) ? It could be optionnal. The pb on the client side is that we have no idea if we will receive some data from the server other than the one used by the HS. We may have long pending read that can interfer with the HS : there is little we can do in this case, but to fail during the HS (ie, everything we read is supposed to be used by the SslEngine to terminate the HS). On the remote side, if we receive a TLS request, we could either empty the write queue, and then start the HS, or generate an error if the queue is not empty, or wait until the queue is empty to start the HS. I was thinking about the write queue on the server, for the client it should be fine.
Re: [MINA 3] SSL
On 11/24/11 4:35 PM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 4:31 PM, Emmanuel Lécharnyelecha...@apache.org wrote: On 11/24/11 4:16 PM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 4:11 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 11/24/11 10:40 AM, Julien Vermillard wrote: On Thu, Nov 24, 2011 at 5:08 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi guys, yesterday, I fought with the way MINA 2 is dealing with SSL. Down the line, we use a filter for that, which handles the handhsake using the SslEngine class. The problem is that at the same time, the session is considered as opened, even if we haven't done any handshake, as we can't add the SslFilter to the session if it's not created yet. That leads to a situation where we could perfectly have an opened session but with a failed HandShake. For instance, as the handshake can be done when the first data is sent by the client, we will generate an exceptionCaught event, process it, but leave to the handler to close the session. From the user PoV, it makes no sense to continue to use a session which has failed during the SSL handshake. IMO, the server should not even open the session (the session should remain in the 'created' state, until the handshake has been completed. Now, if we do that, the Connector won't be able to send anything as the session is not connected. That leave us with a dilemna : we need the connection to be opened, but the connection should not be considered as valid until the handshake is done... How can we deal with this problem ? We decided that Ssl should be handled by the processor, not as a filter in the chain. That means : - we can keep the session in the 'created' mode until the handshake has been done on the server side - we can force the handshake to be done while creating the connection on the client side when using the Connector - in all other case (ie if the client uses a plain Socket), we have no problem as the session is not seen by the user. wdyt ? This use case cover only the I want my whole session SSLed, but not the use case when you start talking in plain unsecure TCP and a command trigger the TLS handshake. I wonder if there is use case where you try to TLS handshake and if it fail you continue talking using plain unsecure TCP. So, after some more investigation, here is what I'm coming to : - we can't initiate the HS before the session has been created - when we require a secure connection (either by connecting to a SSL server, or by sending the server the information we want to switch to TLS), then until the HS is completed (either successfully, or failing), no other data can be sent to the server (or to the client) - that means we must add a flag in the session that tells we are doing a HS - if we try to send some data on a session which is in the middle of a HS, we will get an error - if we try to secure a connection while we have some pending operation, we will get an error Is that ok ? Maybe we could simply wait for queue to be empty and send an error for any write during the handshake (a bit like we do for close) ? It could be optionnal. The pb on the client side is that we have no idea if we will receive some data from the server other than the one used by the HS. We may have long pending read that can interfer with the HS : there is little we can do in this case, but to fail during the HS (ie, everything we read is supposed to be used by the SslEngine to terminate the HS). On the remote side, if we receive a TLS request, we could either empty the write queue, and then start the HS, or generate an error if the queue is not empty, or wait until the queue is empty to start the HS. I was thinking about the write queue on the server, for the client it should be fine. IMO, we should make it optional. For instance, in LDAP, it's up to the StartTLS sender to be sure that there is no pending operation. That means we don't have to take care of such a scenario on the Connector, as it's already handled by the LDAP implementation. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
