Push IPs address to SSLEngine session #73
Conversation
|
The build fails because require the modified JSS. |
| @@ -0,0 +1,77 @@ | |||
| package org.dogtagpki.tomcat; | |||
There was a problem hiding this comment.
The methods from this and the following class come from tomcat. Should we put a note to indicate the origin?
There was a problem hiding this comment.
I'm not sure about the copyright/licensing issue, but is it possible to make some changes in Tomcat so that the code that we need to copy is minimized? For now we just need to make the changes in downstream Tomcat, but later we can try to merge it upstream too.
There was a problem hiding this comment.
Regardless of copyright/licensing issue, I'd suggest to document the origin of the code if it resembles an existing code somewhere else.
There was a problem hiding this comment.
@fmarco76 I'm not familiar with Tomcat enough to make any assessment, but in general, you are right to be concerned about copying the code. I'm with @edewata there. Is there a way to talk to the Tomcat team to make an adjustment so that the class will become extensible in some way? Also, if you are allowed to copy the code, I'd suggest that you add a comment in there detailing where the code came from, and if you had made changes to the copied code, create a block (use comments to state begin and end of changed code) so the readers know exactly what has been changed.
There was a problem hiding this comment.
Added some comments about the origin of the code and what has been modified
| socketProperties.getAppWriteBufSize(), | ||
| socketProperties.getDirectBuffer()); | ||
| if (isSSLEnabled()) { | ||
| channel = new JSSSecureNioChannel(bufhandler, this); |
There was a problem hiding this comment.
Does the original SecureNioChannel have the correct local & remote addresses? I was wondering if we can do something like this:
SecureNioChannel secureNioChannel = new SecureNioChannel(bufhandler, this);
SSLEngine sslEngine = secureNioChannel.getSslEngine();
JSSSession jssSession = (JSSSession) sslEngine.getSession();
jssSession.setLocalAddr(secureNioChannel.getLocalAddr());
jssSession.setRemoteAddr(secureNioChannel.getRemoteAddr());
channel = secureNioChannel;
There was a problem hiding this comment.
The SSLEngine is not created with the SecureNioChannel but when the handshake is performed. Actually, when the handshake is requested, among the initial operations there is the SNI process and the SSLEngine is created there:
Therefore, you have to perform this operation after the method performSNI() and before to complete the method handshake() because after the method the audit is written.
fmarco76
force-pushed
the
EventACCESSMissIP
branch
from
87b0947
to
7164ca9
Compare
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation.
fmarco76
force-pushed
the
EventACCESSMissIP
branch
from
7164ca9
to
4283603
Compare
|
Kudos, SonarCloud Quality Gate passed! |
|
This PR is closed because the code for future versions of tomcat-jss has migrated to the JSS project. The proposed changes will be submitted to that JSS project. |
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation. Replace the tomcatJSS PR#73 (dogtagpki/tomcatjss#73)
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation. Replace the tomcatJSS PR#73 (dogtagpki/tomcatjss#73)
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation. Replace the tomcatJSS PR#73 (dogtagpki/tomcatjss#73)
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation. Replace the tomcatJSS PR#73 (dogtagpki/tomcatjss#73)
**SSLEngine** is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes `NioEndpoint` and it is maintained in `SecureNioChannel` which will create the buffer used with the SSLEngine in order to wrap and unwrap the messages. To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation. Replace the tomcatJSS PR#73 (dogtagpki/tomcatjss#73)
SSLEngine is by design unaware of the underlying communication channel. In tomcat the communication channel is started by the classes
NioEndpointand it is maintained inSecureNioChannelwhich will create the buffer used with the SSLEngine in order to wrap and unwrap the messages.To allow the audit of TLS messages to include IP addresses of the client and server, the above classed have been extended in order to store the IPs in the SSLEngine session after its creation.
This require the JSS PR 972