A TLS Context keep tls specific state, parameters and backend information.

create a new context using the backend and parameters specified.

Handshake for a new TLS connection This is to be called at the beginning of a connection, and during renegotiation. Don't use this function as the acquire resource of bracket.

sendData sends a bunch of data. It will automatically chunk data to acceptable packet size

Get data out of Data packet, and automatically renegotiate if a Handshake ClientHello is received. An empty result means EOF.

Notify the context that this side wants to close connection. This is important that it is called before closing the handle, otherwise the session might not be resumable (for version < TLS1.2). This doesn't actually close the handle.

Proper usage is as follows:

ctx <- contextNew <backend> <params>
handshake ctx
...
bye

The following code ensures nothing but is no harm.

bracket (contextNew <backend> <params>) bye $ \ctx -> do
  handshake ctx
  ...

Connection IO backend

Default: Nothing

Define the name of the server, along with an extra service identification blob. this is important that the hostname part is properly filled for security reason, as it allow to properly associate the remote side with the given certificate during a handshake.

The extra blob is useful to differentiate services running on the same host, but that might have different certificates given. It's only used as part of the X509 validation infrastructure.

This value is typically set by defaultParamsClient.

Allow the use of the Server Name Indication TLS extension during handshake, which allow the client to specify which host name, it's trying to access. This is useful to distinguish CNAME aliasing (e.g. web virtual host).

Default: True

try to establish a connection using this session for TLS 1.2/TLS 1.3. This can be used for TLS 1.3 but for backward compatibility purpose only. Use clientWantSessionResume13 instead for TLS 1.3.

Default: Nothing

try to establish a connection using one of this sessions especially for TLS 1.3. This take precedence over clientWantSessionResume. For convenience, this can be specified for TLS 1.2 but only the first entry is used.

Default: '[]'

See the default value of Shared.

See the default value of ClientHooks.

In this element, you'll need to override the default empty value of of supportedCiphers with a suitable cipherlist.

See the default value of Supported.

See the default value of DebugParams.

Client tries to send early data in TLS 1.3 via sendData if possible. If not accepted by the server, the early data is automatically re-sent.

Default: False

Request a certificate from client.

Default: False

This is a list of certificates from which the disinguished names are sent in certificate request messages. For TLS1.0, it should not be empty.

Default: '[]'

Server Optional Diffie Hellman parameters. Setting parameters is necessary for FFDHE key exchange when clients are not compatible with RFC 7919.

Value can be one of the standardized groups from module Network.TLS.Extra.FFDHE or custom parameters generated with generateParams.

Default: Nothing

See the default value of ServerHooks.

See the default value of Shared.

See the default value of Supported.

See the default value of DebugParams.

Server accepts this size of early data in TLS 1.3. 0 (or lower) means that the server does not accept early data.

Default: 0

Lifetime in seconds for session tickets generated by the server. Acceptable value range is 0 to 604800 (7 days).

Default: 7200 (2 hours)

Parameters that are common to clients and servers.

The list of certificates and private keys that a server will use as part of authentication to clients. Actual credentials that are used are selected dynamically from this list based on client capabilities. Additional credentials returned by onServerNameIndication are also considered.

When credential list is left empty (the default value), no key exchange can take place.

Default: mempty

Callbacks used by clients and servers in order to resume TLS sessions. The default implementation never resumes sessions. Package tls-session-manager provides an in-memory implementation.

Default: noSessionManager

A collection of trust anchors to be used by a client as part of validation of server certificates. This is set as first argument to function onServerCertificate. Package crypton-x509-system gives access to a default certificate store configured in the system.

Default: mempty

Callbacks that may be used by a client to cache certificate validation results (positive or negative) and avoid expensive signature check. The default implementation does not have any caching.

See the default value of ValidationCache.

Additional extensions to be sent during the Hello sequence.

For a client this is always included in message ClientHello. For a server, this is sent in messages ServerHello or EncryptedExtensions based on the TLS version.

Default: []

A set of callbacks run by the clients for various corners of TLS establishment

Type for onCertificateRequest. This type synonym is to make document readable.

This action is called when the a certificate request is received from the server. The callback argument is the information from the request. The server, at its discretion, may be willing to continue the handshake without a client certificate. Therefore, the callback is free to return Nothing to indicate that no client certificate should be sent, despite the server's request. In some cases it may be appropriate to get user consent before sending the certificate; the content of the user's certificate may be sensitive and intended only for specific servers.

The action should select a certificate chain of one of the given certificate types and one of the certificates in the chain should (if possible) be signed by one of the given distinguished names. Some servers, that don't have a narrow set of preferred issuer CAs, will send an empty DistinguishedName list, rather than send all the names from their trusted CA bundle. If the client does not have a certificate chaining to a matching CA, it may choose a default certificate instead.

Each certificate except the last should be signed by the following one. The returned private key must be for the first certificates in the chain. This key will be used to signing the certificate verify message.

The public key in the first certificate, and the matching returned private key must be compatible with one of the list of HashAndSignatureAlgorithm value when provided. TLS 1.3 changes the meaning of the list elements, adding explicit code points for each supported pair of hash and signature (public key) algorithms, rather than combining separate codes for the hash and key. For details see RFC 8446 section 4.2.3. When no compatible certificate chain is available, return Nothing if it is OK to continue without a client certificate. Returning a non-matching certificate should result in a handshake failure.

While the TLS version is not provided to the callback, the content of the signature_algorithms list provides a strong hint, since TLS 1.3 servers will generally list RSA pairs with a hash component of Intrinsic (0x08).

Note that is is the responsibility of this action to select a certificate matching one of the requested certificate types (public key algorithms). Returning a non-matching one will lead to handshake failure later.

Default: returns Nothing anyway.

Type for onServerCertificate. This type synonym is to make document readable.

Used by the client to validate the server certificate. The default implementation calls validateDefault which validates according to the default hooks and checks provided by Data.X509.Validation. This can be replaced with a custom validation function using different settings.

The function is not expected to verify the key-usage extension of the end-entity certificate, as this depends on the dynamically-selected cipher and this part should not be cached. Key-usage verification is performed by the library internally.

Default: validateDefault

This action is called when the client sends ClientHello to determine ALPN values such as '["h2", "http/1.1"]'.

Default: returns Nothing

This action is called to validate DHE parameters when the server selected a finite-field group not part of the "Supported Groups Registry" or not part of supportedGroups list.

With TLS 1.3 custom groups have been removed from the protocol, so this callback is only used when the version negotiated is 1.2 or below.

The default behavior with (dh_p, dh_g, dh_size) and pub as follows:

1. rejecting if dh_p is even
2. rejecting unless 1 < dh_g && dh_g < dh_p - 1
3. rejecting unless 1 < dh_p && pub < dh_p - 1
4. rejecting if dh_size < 1024 (to prevent Logjam attack)

See RFC 7919 section 3.1 for recommandations.

When a handshake is done, this hook can check Information.

A set of callbacks run by the server for various corners of the TLS establishment

This action is called when a client certificate chain is received from the client. When it returns a CertificateUsageReject value, the handshake is aborted.

The function is not expected to verify the key-usage extension of the certificate. This verification is performed by the library internally.

Default: returns the followings:

CertificateUsageReject (CertificateRejectOther "no client certificates expected")

This action is called when the client certificate cannot be verified. Return True to accept the certificate anyway, or False to fail verification.

Default: returns False

Allow the server to choose the cipher relative to the the client version and the client list of ciphers.

This could be useful with old clients and as a workaround to the BEAST (where RC4 is sometimes prefered with TLS < 1.1)

The client cipher list cannot be empty.

Default: taking the head of ciphers.

Allow the server to indicate additional credentials to be used depending on the host name indicated by the client.

This is most useful for transparent proxies where credentials must be generated on the fly according to the host the client is trying to connect to.

Returned credentials may be ignored if a client does not support the signature algorithms used in the certificate chain.

Default: returns mempty

At each new handshake, we call this hook to see if we allow handshake to happens.

Default: returns True

Allow the server to choose an application layer protocol suggested from the client through the ALPN (Application Layer Protocol Negotiation) extensions. If the server supports no protocols that the client advertises an empty ByteString should be returned.

Default: Nothing

Allow to modify extensions to be sent in EncryptedExtensions of TLS 1.3.

Default: return

record some data about this connection.

number of handshakes on this context

bytes received since last handshake

bytes sent since last handshake

List all the supported algorithms, versions, ciphers, etc supported.

Supported versions by this context. On the client side, the highest version will be used to establish the connection. On the server side, the highest version that is less or equal than the client version will be chosen.

Versions should be listed in preference order, i.e. higher versions first.

Default: [TLS13,TLS12]

Supported cipher methods. The default is empty, specify a suitable cipher list. ciphersuite_default is often a good choice.

Default: []

Supported compressions methods. By default only the "null" compression is supported, which means no compression will be performed. Allowing other compression method is not advised as it causes a connection failure when TLS 1.3 is negotiated.

Default: [nullCompression]

All supported hash/signature algorithms pair for client certificate verification and server signature in (EC)DHE, ordered by decreasing priority.

This list is sent to the peer as part of the "signature_algorithms" extension. It is used to restrict accepted signatures received from the peer at TLS level (not in X.509 certificates), but only when the TLS version is 1.2 or above. In order to disable SHA-1 one must then also disable earlier protocol versions in supportedVersions.

The list also impacts the selection of possible algorithms when generating signatures.

Note: with TLS 1.3 some algorithms have been deprecated and will not be used even when listed in the parameter: MD5, SHA-1, SHA-224, RSA PKCS#1, DSA.

Default:

  [ (HashIntrinsic,     SignatureEd448)
  , (HashIntrinsic,     SignatureEd25519)
  , (Struct.HashSHA256, SignatureECDSA)
  , (Struct.HashSHA384, SignatureECDSA)
  , (Struct.HashSHA512, SignatureECDSA)
  , (HashIntrinsic,     SignatureRSApssRSAeSHA512)
  , (HashIntrinsic,     SignatureRSApssRSAeSHA384)
  , (HashIntrinsic,     SignatureRSApssRSAeSHA256)
  , (Struct.HashSHA512, SignatureRSA)
  , (Struct.HashSHA384, SignatureRSA)
  , (Struct.HashSHA256, SignatureRSA)
  , (Struct.HashSHA1,   SignatureRSA)
  , (Struct.HashSHA1,   SignatureDSA)
  ]

Secure renegotiation defined in RFC5746. If True, clients send the renegotiation_info extension. If True, servers handle the extension or the renegotiation SCSV then send the renegotiation_info extension.

Default: True

If True, renegotiation is allowed from the client side. This is vulnerable to DOS attacks. If False, renegotiation is allowed only from the server side via HelloRequest.

Default: False

The mode regarding extended main secret. Enabling this extension provides better security for TLS versions 1.2. TLS 1.3 provides the security properties natively and does not need the extension.

By default the extension is RequireEMS. So, the handshake will fail when the peer does not support the extension.

Default: RequireEMS

Set if we support session.

Default: True

Support for fallback SCSV defined in RFC7507. If True, servers reject handshakes which suggest a lower protocol than the highest protocol supported.

Default: True

In ver <= TLS1.0, block ciphers using CBC are using CBC residue as IV, which can be guessed by an attacker. Hence, an empty packet is normally sent before a normal data packet, to prevent guessability. Some Microsoft TLS-based protocol implementations, however, consider these empty packets as a protocol violation and disconnect. If this parameter is False, empty packets will never be added, which is less secure, but might help in rare cases.

Default: True

A list of supported elliptic curves and finite-field groups in the preferred order.

The list is sent to the server as part of the "supported_groups" extension. It is used in both clients and servers to restrict accepted groups in DH key exchange. Up until TLS v1.2, it is also used by a client to restrict accepted elliptic curves in ECDSA signatures.

The default value includes all groups with security strength of 128 bits or more.

Default: [X25519,X448,P256,FFDHE3072,FFDHE4096,P384,FFDHE6144,FFDHE8192,P521]

All settings should not be used in production

Disable the true randomness in favor of deterministic seed that will produce a deterministic random from. This is useful for tests and debugging purpose. Do not use in production

Default: Nothing

Add a way to print the seed that was randomly generated. re-using the same seed will reproduce the same randomness with debugSeed

Default: no printing

Force to choose this version in the server side.

Default: Nothing

Printing main keys.

Default: no printing

try to create a new credential object from a public certificate and the associated private key that are stored on the filesystem in PEM format.

similar to credentialLoadX509 but take the certificate and private key from memory instead of from the filesystem.

similar to credentialLoadX509 but also allow specifying chain certificates.

similar to credentialLoadX509FromMemory but also allow specifying chain certificates.

A session manager. In the server side, all fields are used. In the client side, only sessionEstablish is used.

The session manager to do nothing.

Used on TLS 1.2/1.3 servers to lookup SessionData with SessionID or to decrypt Ticket to get SessionData.

Used for 0RTT on TLS 1.3 servers to lookup SessionData with SessionID or to decrypt Ticket to get SessionData.

Used on TLS 1.2/1.3 servers to store SessionData with SessionID or to encrypt SessionData to get Ticket ignoring SessionID. Used on TLS 1.2/1.3 clients to store SessionData with SessionIDorTicket and then return Nothing. For clients, only this field should be set with noSessionManager.

Used TLS 1.2 servers to delete SessionData with SessionID on errors.

Used on TLS 1.2 servers to decide to use SessionID or Ticket. Note that SessionID and Ticket are integrated as identity in TLS 1.3.

A session ID

Identity

Encrypted session ticket (encrypt(encode SessionData)).

Session data to resume

Some session flags

All the callbacks needed for querying and adding to the cache.

Validation cache query callback type

Validation cache callback type

The result of a cache query

create a simple constant cache that list exceptions to the certification validation. Typically this is use to allow self-signed certificates for specific use, with out-of-bounds user checks.

No fingerprints will be added after the instance is created.

The underlying structure for the check is kept as a list, as usually the exception list will be short, but when the list go above a dozen exceptions it's recommended to use another cache mechanism with a faster lookup mechanism (hashtable, map, etc).

Note that only one fingerprint is allowed per ServiceID, for other use, another cache mechanism need to be use.

Versions known to TLS

every compression need to be wrapped in this, to fit in structure

default null compression

Client or server policy regarding Extended Main Secret

Group usage callback possible return values.

Certificate Usage callback possible returns values.

Certificate and Chain rejection reason

Some of the IANA registered code points for CertificateType are not currently supported by the library. Nor should they be, they're are either unwise, obsolete or both. There's no point in conveying these to the user in the client certificate request callback. The request callback will be filtered to exclude unsupported values. If the user cannot find a certificate for a supported code point, we'll go ahead without a client certificate and hope for the best, unless the user's callback decides to throw an exception.

Either a host name e.g., "haskell.org" or a numeric host address string consisting of a dotted decimal IPv4 address or an IPv6 address e.g., "192.168.0.1".

return the backend object associated with this context

A shortcut for 'backendFlush . ctxBackend'.

A shortcut for 'backendClose . ctxBackend'.

Information related to a running context, e.g. current cipher

Information about the current context

Type to show which handshake mode is used in TLS 1.3.

Getting certificates from a client, if any. Note that the certificates are not sent by a client on resumption even if client authentication is required. So, this API would be replaced by the one which can treat both cases of full-negotiation and resumption.

If the ALPN extensions have been used, this will return get the protocol agreed upon.

If the Server Name Indication extension has been used, return the hostname specified by the client.

Updating appication traffic secrets for TLS 1.3. If this API is called for TLS 1.3, True is returned. Otherwise, False is returned.

How to update keys in TLS 1.3

Post-handshake certificate request with TLS 1.3. Returns True if the request was possible, i.e. if TLS 1.3 is used and the remote client supports post-handshake authentication.

Getting the "tls-unique" channel binding for TLS 1.2 (RFC5929). For TLS 1.3, Nothing is returned. supportedExtendedMainSecret must be RequireEMS But in general, it is highly recommended to upgrade to TLS 1.3 and use the "tls-exporter" channel binding via getTLSExporter.

Getting the "tls-exporter" channel binding for TLS 1.3 (RFC9266). For TLS 1.2, Nothing is returned.

Getting the "tls-server-end-point" channel binding for TLS 1.2 (RFC5929). For 1.3, there is no specifications for how to create it. In this implementation, a certificate chain without extensions is hashed like TLS 1.2.

Getting TLS Finished sent to peer.

Getting TLS Finished received from peer.

A collection of hooks actions.

called at each handshake message received

called at each handshake message received for TLS 1.3

called at each certificate chain message received

hooks on IO and packets, receiving and sending.

Hooks for logging

This is called when sending and receiving packets and IO

TLSError that might be returned through the TLS stack.

Prior to version 1.8.0, this type had an Exception instance. In version 1.8.0, this instance was removed, and functions in this library now only throw TLSException.