iaik.security.ssl
Class TLS13PostHandshakeConfig

java.lang.Object
  extended by iaik.security.ssl.TLS13PostHandshakeConfig
All Implemented Interfaces:
java.lang.Cloneable
Direct Known Subclasses:
TLS13PostHandshakeConfig.TLS13KeyUpdateConfig, TLS13PostHandshakeConfig.TLS13NewSessionTicketConfig, TLS13PostHandshakeConfig.TLS13PostHandshakeAuthConfig

public abstract class TLS13PostHandshakeConfig
extends java.lang.Object
implements java.lang.Cloneable

TLS 1.3 post handshake configuration.

This class may be used by an application to provide some configuration options when triggering some post handshake action. At minimum the TLS13PostHandshakeConfig specifies the type of post handshake to be performed (either NEW_SESSION_TICKET to send a new session ticket to the client, POST_HANDSHAKE_AUTH to request post client authentication, or KEY_UPDATE to perform a key update). Sending a new session ticket or requesting post client authentication may be only triggered on the server side, a key update may be done on both, client or server side.

For triggering some post handshake action method SSLSocket.postHandshake(TLS13PostHandshakeConfig) has to be called on the SSLSocket/SSLTransport in use. When calling sslSocket.postHandshake() to explicitly trigger a post handshake action care has to be taken that the regular handshake has been already finished (and some data has been exchanged) and a protocol version >=1.3 has been negotiated, e.g.:

 SSLSocket sslSocket = ...;
 ...
 sslSocket.startHandshake();
 ...
 // do some data reading/writing
 ...
 boolean triggerKeyUpdate = true;
 TLS13KeyUpdateConfig keyUpdateConfig = new TLS13KeyUpdateConfig(triggerKeyUpdate);
 sslSocket.postHandshake(keyUpdateConfig);
 
In practice post handshaking may be used very carefully and may depend on the post handshake capabilities of the peer. For instance, it does not make sense to request post handshake authentication from a client that has not sent a PostHandshakeAuth extension indicating that it is able to do post handshake authentication. Furthermore successful post handshaking may depend on the way the peer does handle it. For instance, a client may send its post handshake authentication messages immediately after having received the post handshake authentication request from the server or may send some amount of application data before sending the post handshake authentication messages. iSaSiLk provides several configuration options that may be tried to handle post handshaking in a way most suitable for the intended peer.


Nested Class Summary
static class TLS13PostHandshakeConfig.TLS13KeyUpdateConfig
          Configuration for post handshake type KEY_UPDATE.
static class TLS13PostHandshakeConfig.TLS13NewSessionTicketConfig
          Configuration for post handshake type NEW_SESSION_TICKET.
static class TLS13PostHandshakeConfig.TLS13PostHandshakeAuthConfig
          Configuration for post handshake type POST_HANDSHAKE_AUTH.
 
Field Summary
static int KEY_UPDATE
          Post handshake type key_update.
static int NEW_SESSION_TICKET
          Post handshake type new_session_ticket.
static int POST_HANDSHAKE_AUTH
          Post handshake type post_handshake_auth.
 
Method Summary
 java.lang.Object clone()
          Returns a clone of this TLS13PostHandshakeAuthConfig.
static void setMaxNumberOfSubsequentPostHandshakeMessages(int maxNumber)
          Sets the maximum number of subsequent TLS 1.3 post handshake messages to be allowed.
 
Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Field Detail

NEW_SESSION_TICKET

public static final int NEW_SESSION_TICKET
Post handshake type new_session_ticket.
Maybe triggered on the server side to send a new session ticket.

See Also:
TLS13PostHandshakeConfig.TLS13NewSessionTicketConfig, Constant Field Values

POST_HANDSHAKE_AUTH

public static final int POST_HANDSHAKE_AUTH
Post handshake type post_handshake_auth.
Maybe triggered on the server side to request client authentication at any time the regular handshake has been completed. Can be only used if the client has sent a PostHandshakeAuth in its ClientHello message.

See Also:
TLS13PostHandshakeConfig.TLS13PostHandshakeAuthConfig, Constant Field Values

KEY_UPDATE

public static final int KEY_UPDATE
Post handshake type key_update.
Maybe triggered on client or server side to notify the peer that the write keys have been updated (and maybe requesting that the peer also updates its write keys).

See Also:
TLS13PostHandshakeConfig.TLS13KeyUpdateConfig, Constant Field Values
Method Detail

setMaxNumberOfSubsequentPostHandshakeMessages

public static void setMaxNumberOfSubsequentPostHandshakeMessages(int maxNumber)
Sets the maximum number of subsequent TLS 1.3 post handshake messages to be allowed.

This method may be used to configure the maximum number of TLS 1.3 post handshake messages that may arrive in subsequent order without any other kind of (application data) message in between. The default value is 15 meaning that up to 15 post handshake messages may arrive in subsequent order before the connection will be shutdown with an unexpected_message alert. This post handshake message boundary shall prevent from receiving too many post handshake messages without receiving any data in between so that a malicious peer cannot force the connection in an endless key update loop.

Parameters:
maxNumber - the maximum number of subsequent TLS 1.3 post handshake messages to be allowed (default: 15)
Throws:
java.lang.IllegalArgumentException - if the specified maximum number is <1

clone

public java.lang.Object clone()
Returns a clone of this TLS13PostHandshakeAuthConfig.

Overrides:
clone in class java.lang.Object
Returns:
a clone of this TLS13PostHandshakeAuthConfig

This Javadoc may contain text parts from text parts from IETF Internet Standard specifications (see copyright note).

iSaSiLk 6.0, (c) 2002 IAIK, (c) 2003 - 2015 SIC