Start a TLS-secured TCP server that accepts incoming connections and handles each of them concurrently, in different threads.

Any acquired network resources are properly closed and discarded when done or in case of exceptions. This function binds a listening socket, accepts an incoming connection, performs a TLS handshake and then safely closes the connection when done or in case of exceptions. You don't need to perform any of those steps manually.

Bind a TCP listening socket and use it.

The listening socket is closed when done or in case of exceptions.

If you prefer to acquire and close the socket yourself, then use bindSock, closeSock and the listen function from Network.Socket instead.

Note: maxListenQueue is typically 128, which is too small for high performance servers. So, we use the maximum between maxListenQueue and 2048 as the default size of the listening queue. The NoDelay and ReuseAddr options are set on the socket.

Accepts a single incomming TLS-secured TCP connection and use it.

A TLS handshake is performed immediately after establishing the TCP connection and the TLS and TCP connections are properly closed when done or in case of exceptions. If you need to manage the lifetime of the connection resources yourself, then use acceptTls instead.

Like accept, except it uses a different thread to performs the TLS handshake and run the given computation.

Abstract type representing the configuration settings for a TLS server.

Use makeServerSettings to construct a ServerSettings value, and updateServerParams to update it.

Make default ServerSettings.

The supported cipher suites are those enumerated by ciphersuite_strong, in decreasing order of preference. The cipher suite preferred by the server is used.

Secure renegotiation initiated by the server is enabled, but renegotiation initiated by the client is disabled.

Only the TLS 1.1 and TLS 1.2 protocols are supported by default.

If you are unsatisfied with any of these settings, use updateServerParams to change them.

Update advanced TLS server configuration Params.

See the Network.TLS module for details.

A Lens into the TLS server configuration Params. See the Network.TLS and the lens package for details.

Connect to a TLS-secured TCP server and use the connection

A TLS handshake is performed immediately after establishing the TCP connection and the TLS and TCP connections are properly closed when done or in case of exceptions. If you need to manage the lifetime of the connection resources yourself, then use connectTls instead.

Abstract type representing the configuration settings for a TLS client.

Use makeClientSettings or getDefaultClientSettings to obtain a ClientSettings value.

Make defaults ClientSettings.

Certificate chain validation is done by validateDefault from the Data.X509.Validation module.

The Server Name Indication (SNI) TLS extension is enabled.

The supported cipher suites are those enumerated by ciphersuite_default, in decreasing order of preference.

Secure renegotiation is enabled.

Only the TLS 1.1 and TLS 1.2 protocols are supported by default.

If you are unsatisfied with any of these settings, use updateClientParams to change them.

Get the system default ClientSettings for a particular ServiceID.

Defaults: No client credentials, system certificate store.

See makeClientSettings to better understand the default settings used.

Update advanced TLS client configuration ClientParams.

See the Network.TLS module for details.

A Lens into the TLS client configuration ClientParams.

See the Network.TLS and the lens package for details.

Receives decrypted bytes from the given Context. Returns Nothing on EOF.

Up to 16384 decrypted bytes will be received at once.

Encrypts the given strict ByteString and sends it through the Context.

Perform a TLS handshake on the given Context, then perform the given action and at last gracefully close the TLS session using bye.

This function does not close the underlying TCP connection when done. Prefer to use useTlsThenClose or useTlsThenCloseFork if you need that behavior. Otherwise, you must call contextClose yourself at some point.

Like useTls, except it also fully closes the TCP connection when done.

Similar to useTlsThenClose, except it performs the all the IO actions in a new thread.

Use this instead of forking useTlsThenClose yourself, as that won't give the right behavior.

Estalbishes a TCP connection to a remote server and returns a TLS Context configured on top of it using the given ClientSettings. The remote end address is also returned.

Prefer to use connect if you will be using the obtained Context within a limited scope.

You need to perform a TLS handshake on the resulting Context before using it for communication purposes, and gracefully close the TLS and TCP connections afterwards using. The useTls, useTlsThenClose and useTlsThenCloseFork can help you with that.

Accepts an incoming TCP connection and returns a TLS Context configured on top of it using the given ServerSettings. The remote end address is also returned.

Prefer to use accept if you will be using the obtained Context within a limited scope.

You need to perform a TLS handshake on the resulting Context before using it for communication purposes, and gracefully close the TLS and TCP connections afterwards using. The useTls, useTlsThenClose and useTlsThenCloseFork can help you with that.

Make a client-side TLS Context for the given settings, on top of the given TCP Socket connected to the remote end.

Make a server-side TLS Context for the given settings, on top of the given TCP Socket connected to the remote end.

With older versions of the network library on Windows operating systems, the networking subsystem must be initialised using withSocketsDo before any networking operations can be used. eg.

main = withSocketsDo $ do {...}

It is fine to nest calls to withSocketsDo, and to perform networking operations after withSocketsDo has returned.

In newer versions of the network library it is only necessary to call withSocketsDo if you are calling the MkSocket constructor directly. However, for compatibility with older versions on Windows, it is good practice to always call withSocketsDo (it's very cheap).