Connect to a Noise-secured TCP server and use the connection.

Any acquired network resources are properly closed and discarded when done or in case of exceptions.

Start a Noise-secured TCP server which 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.

Internally, this function just performs listen and acceptFork.

Bind a TCP listening socket and use it

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

Note: maxListenQueue is tipically 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.

Accept a single incoming connection and use it.

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

Accept a single incoming connection and use it in another thread.

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

Encrypts the given ByteString, and writes the bytes to the socket in a single message. The data can also be padded with random data to obscure the plaintext length.

Receives data over the connection, decrypts it and returns the resulting ByteString. This receives a single Noise message.

Returns Nothing if the remote end closed the connection or end-of-input was reached.

A message to send down a noise pipe - simply a message paired with an amount of random padding to add to the message.

Turn an InputStream and OutputStream into encrypted noise pipes for use by clients to talk to servers.

Turn an InputStream and OutputStream into encrypted noise pipes for use by servers to talk to clients.

Pull out the underlying InputStream and OutputStream from the given TCP Context. Any data written/read from these streams will be encrypted/decrypted from the other side.

Pull out the underlying Socket from the Context.

Close the given Context.

Type of functions which pad pipe messages.

Given an OutputStream for a PipeMsg, create an OutputStream that attaches a random number of bytes (within the specified range) to every message sent down the pipe, to make plaintext analysis more difficult.

For example

let outStream' = randomPadStream (0, 64) outStream

creates an OutputStream where every message has between 0 and 64 bytes of padding, chosen randomly.

Given an OutputStream for a PipeMsg, create an OutputStream that attaches a constant number of random bytes to every message sent down the pipe.

For example

let outStream' = constantPadStream 0 outStream

creates an OutputStream where there is no padding for the messages sent down the pipe.

Offer up an X509 certificate chain as part of the initial handshake. Given a FilePath specifying a certificate, this will cause the configured party to issue the certificate as part of its initial message.

Note the other party MUST validate this response using validateX509 in their confInitialResponse setting.

When this function cannot parse the certificate chain correctly (for example, using an invalid file), it will throw an InvalidNoiseX509Certificate.

Simple X509 certificate chain validation for initial handshakes.

This is a simple, easy-to-use client API that allows you to validate server-offered certificates using the system certificate store. All it needs is the expected FQDN of the certificate.

If you need more control (for example, TOFU policies or validation exceptions), please use validateX509_ instead.

Note the server MUST send the initial certificate using offerX509 in their confInitialMsg setting.

When this function cannot validate the X509 certificate offered to it, it will throw an InvalidNoiseX509Certificate exception.

X509 certificate validation. This is the 'extended' version of the basic x509ClientValidate API, allowing more control. Given an optional hostname and the input certificate chain (encoded), as well as control over the validation cache and a predicate, this validates the certificate against the system store.

Note the server MUST send the initial certificate using x509ServerMsg in their serverInitialMsg setting.

When this function cannot validate the X509 certificate offered to it, it will throw an InvalidNoiseX509Certificate exception.

On Windows operating systems, the networking subsystem has to be initialised using withSocketsDo before any networking operations can be used. eg.

main = withSocketsDo $ do {...}

Although this is only strictly necessary on Windows platforms, it is harmless on other platforms, so for portability it is good practice to use it all the time.

TCP connection context, containing internal connection streams.

Pipe configuration. This sets options for the long-term connection and initial setup phase. Most people are probably fine using defaultPipeConfig, although depending on your use case, you may also want to customise the padder (probably using randomPadStream).

Note that if you override the initial message/response handler, you must overwrite the dual option in the other parties' handler.

The default PipeConfig uses randomized initial padding length, no server keypair (anonymous), no expected client key (anonymous), and no padding for messages (using constantPadStream 0).

Possible reason of certificate and chain failure

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

An exception which is thrown when the Noise pipe cannot be properly negotiated due to key failure or some other error.

Exception throw by clients when an invalid X509 certificate is offered. This may also be thrown by the server when it cannot decode the X509 certificate.