Libraries
Class Session
extends Object
TLS Session upgrades a reader/writer pair to a TLS encrypted communication channel.
The most common usage of a TLS session is for upgrading a TCP socket to secure TLS socket. For that use-case see Socket.
Class summary
| DEFAULT-HANDSHAKE-TIMEOUT -> any | |
|---|---|
| client reader_/CloseableReader writer_/CloseableWriter --server-name/string= --certificate/Certificate= --root-certificates/List= --session-state/ByteArray= --handshake-timeout/Duration= --skip-certificate-validation/bool= -> Session | Creates a new TLS session at the client-side. |
| server reader_/CloseableReader writer_/CloseableWriter --certificate/Certificate= --root-certificates/List= --handshake-timeout/Duration= -> Session | Creates a new TLS session at the server-side. |
Statics
client reader_/CloseableReader writer_/CloseableWriter --server-name/string=null --certificate/Certificate=null --root-certificates/List=[] --session-state/ByteArray=null --handshake-timeout/Duration=DEFAULT-HANDSHAKE-TIMEOUT --skip-certificate-validation/bool=false -> Session
Creates a new TLS session at the client-side.
If server-name is provided, it will validate the peer certificate against that. If the server-name is omitted, it will skip verification.
The root-certificates are used to validate the peer certificate.
If certificate is given, the certificate is used by the server to validate the authority of the client. This is not usually done on the web, where normally only the client verifies the server
The handshake routine requires at most handshake-timeout between each step in the handshake process.
If session-state is given, the handshake operation will use it to resume the TLS session from the previous stored session state. This can greatly improve the duration of a complete TLS handshake. If the session state is given, but rejected by the server, an error will be thrown, and the operation must be retried without stored session data.
server reader_/CloseableReader writer_/CloseableWriter --certificate/Certificate=null --root-certificates/List=[] --handshake-timeout/Duration=DEFAULT-HANDSHAKE-TIMEOUT -> Session
Creates a new TLS session at the server-side.
The root-certificates are used to validate the peer certificate.
If certificate is given, the certificate is used by the server to validate the authority of the client. This is not usually done on the web, where normally only the client verifies the server.
The handshake routine requires at most handshake-timeout between each step in the handshake process.
Methods
Closes the TLS session and releases any resources associated with it.
Closes the session for write operations.
Explicitly completes the handshake step.
This method will automatically be called by read and write if the handshake is not completed yet.
Whether this object is equal to the other.
Inheritance
Classes overwrite this operator to get an equality specific to their needs. Equality operators often compare the type and field contents. For example:
class Pin:
number/int
constructor .number:
operator == other:
if other is not Pin: return false
return number == other.number
A class doesn't have to follow the above format, but it must keep the operator in sync with any
hash-code method. That is, if a class has a hash-code member, then the equality and hash-code must agree. If two instances are equal (a == b), then their hash codes must also be equal (a.hash-code == b.hash-code).Returns true if the session was successfully resumed, rather than going through a full handshake with asymmetric crypto.
Returns false until the handshake is complete.
Stringifies this object.
Inheritance
Objects that need a human-friendly string representation should overwrite this method. The default string is based on the internal class-ID.
Fields
Gets the session state, a ByteArray that can be used to resume a TLS session at a later point.
The session can be read at any point after a handshake.
The session state is a Tison-encoded list of 3 byte arrays and an integer:
The first byte array is the session ID, the second is the session ticket, and the third is the master secret. The session ID and session ticket are mutually exclusive (only one of them has a non-zero length). The fourth item is an integer giving the ciphersuite used.