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 and closeSock, as well as listenSock function.

Note: The NoDelay, KeepAlive and ReuseAddr options are set on the socket. The maximum number of incoming queued connections is 2048.

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.

Obtain new default ServerParams for a particular server Credential.

• Don't require credentials from clients.
• Use an in-memory TLS session manager from the tls-session-manager package.
• Everything else as proposed by makeServerParams.

Make default ServerParams.

• 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, TLS 1.2 and TLS 1.3 protocols are supported by default.

If you are unsatisfied with any of these settings, please please refer to the Network.TLS module for more documentation on ServerParams.

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.

Like connect, but connects to the destination server over a SOCKS5 proxy.

Obtain new default ClientParams for a particular ServiceID.

• No client credentials sumbitted to the server.
• Use system-wide CA certificate store.
• Use an in-memory TLS session manager from the tls-session-manager package.
• Everything else as proposed by makeClientParams.

Make defaults ClientParams.

• 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, TLS 1.2 and TLS 1.3 protocols are supported by default.

If you are unsatisfied with any of these settings, please please refer to the Network.TLS module for more documentation on ClientParams.

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.

Encrypts the given lazy 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 ClientParams. 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.

Like connectTls, but connects to the destination server over a SOCKS5 proxy.

Accepts an incoming TCP connection and returns a TLS Context configured on top of it using the given ServerParams. 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 (version 2.6.0.2 or earlier) 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.

withSocketsDo is not necessary for the current network library. However, for compatibility with older versions on Windows, it is good practice to always call withSocketsDo (it's very cheap).

Preferred host to bind.

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".

Either a service name e.g., "http" or a numeric port number.

Basic type for a socket.

Socket addresses. The existence of a constructor does not necessarily imply that that socket address type is supported on your system: see isSupportedSockAddr.

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

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.