You must make sure not to write a message while the {@linkplain #handshake() handshake} is in progress unless you arerenegotiating. You will be notified by the {@link ChannelFuture} which isreturned by the {@link #handshake()} method when the handshakeprocess succeeds or fails.
If {@link #isIssueHandshake()} is {@code false}(default) you will need to take care of calling {@link #handshake()} by your own. In mostsituations were {@link SslHandler} is used in 'client mode' you want to issue a handshake oncethe connection was established. if {@link #setIssueHandshake(boolean)} is set to {@code true}you don't need to worry about this as the {@link SslHandler} will take care of it.
If {@link #isEnableRenegotiation() enableRenegotiation} is {@code true}(default) and the initial handshake has been done successfully, you can call {@link #handshake()} to trigger the renegotiation.
If {@link #isEnableRenegotiation() enableRenegotiation} is {@code false}, an attempt to trigger renegotiation will result in the connection closure.
Please note that TLS renegotiation had a security issue before. If your runtime environment did not fix it, please make sure to disable TLS renegotiation by calling {@link #setEnableRenegotiation(boolean)} with{@code false}. For more information, please refer to the following documents:
To close the SSL session, the {@link #close()} method should becalled to send the {@code close_notify} message to the remote peer. Oneexception is when you close the {@link Channel} - {@link SslHandler}intercepts the close request and send the {@code close_notify} messagebefore the channel closure automatically. Once the SSL session is closed, it is not reusable, and consequently you should create a new {@link SslHandler} with a new {@link SSLEngine} as explained in thefollowing section.
To restart the SSL session, you must remove the existing closed {@link SslHandler} from the {@link ChannelPipeline}, insert a new {@link SslHandler} with a new {@link SSLEngine} into the pipeline,and start the handshake process as described in the first section.
StartTLS is the communication pattern that secures the wire in the middle of the plaintext connection. Please note that it is different from SSL · TLS, that secures the wire from the beginning of the connection. Typically, StartTLS is composed of three steps:
The client-side implementation is much simpler.
Because of a known issue with the current implementation of the SslEngine that comes with Java it may be possible that you see blocked IO-Threads while a full GC is done.
So if you are affected you can workaround this problem by adjust the cache settings like shown below:
SslContext context = ...; context.getServerSessionContext().setSessionCacheSize(someSaneSize); context.getServerSessionContext().setSessionTime(someSameTimeout);
What values to use here depends on the nature of your application and should be set based on monitoring and debugging of it. For more details see #832 in our issue tracker. @apiviz.landmark @apiviz.uses com.facebook.presto.jdbc.internal.netty.handler.ssl.SslBufferPool
|
|
|
|
|
|