nanomsg next generation NNG  
Home GitHub Documentation

This documentation is for version v1.0.0 of nng, but the latest released version is v1.7.3. see the documentation for v1.7.3 for the most up-to-date information.
nng_tls(7)

SYNOPSIS

#include <nng/transport/tls/tls.h>

int nng_tls_register(void);

DESCRIPTION

The tls transport provides communication support between nng sockets across a TCP/IP network using TLS v1.2 on top of TCP. Both IPv4 and IPv6 are supported when the underlying platform also supports it.

The protocol details are documented in TLS Mapping for Scalability Protocols.

Registration

Depending upon how the library was built, it may be necessary to register the transport by calling nng_tls_register().

Availability

The tls transport depends on the use of an external library. As of this writing, mbedTLS version 2.0 or later is required.

Applications may need to add this library (or libraries) to their link line, particularly when using a statically built nng library.
The mbedTLS library uses different licensing terms than nng itself; as of this writing it is offered under either Apache License 2.0 or GNU GPL terms. You are responsible for understanding and adhering to the license terms of any libraries you make use of.

URI Format

This transport uses URIs using the scheme tls+tcp://, followed by an IP address or hostname, followed by a colon and finally a TCP port number. For example, to contact port 4433 on the localhost either of the following URIs could be used: tls+tcp://127.0.0.1:4433 or tls+tcp://localhost:4433.

A URI may be restricted to IPv6 using the scheme tls+tcp6://, and may be restricted to IPv4 using the scheme tls+tcp4://.

Specifying tls+tcp6:// may not prevent IPv4 hosts from being used with IPv4-in-IPv6 addresses, particularly when using a wildcard hostname with listeners. The details of varies across operating systems.
Both tls+tcp6:// and tls+tcp4:// are nng extensions, and will not be understood by other implementations such as mangos.
We recommend using either numeric IP addresses, or names that are specific to either IPv4 or IPv6 to prevent confusion and surprises.

When specifying IPv6 addresses, the address must be enclosed in square brackets ([]) to avoid confusion with the final colon separating the port.

For example, the same port 4433 on the IPv6 loopback address ('::1') would be specified as tls+tcp://[::1]:4433.

When using symbolic names, the name is resolved when the name is first used. nng won’t become aware of changes in the name resolution until restart, usually. (This is a bug and will likely be fixed in the future.)
Certificate validation generally works when using names rather than IP addresses. This transport automatically uses the name supplied in the URL when validating the certificate supplied by the server.

The special value of 0 (INADDR_ANY) can be used for a listener to indicate that it should listen on all interfaces on the host. A short-hand for this form is to either omit the address, or specify the asterisk (*) character. For example, the following three URIs are all equivalent, and could be used to listen to port 9999 on the host:

  1. tls+tcp://0.0.0.0:9999

  2. tls+tcp://*:9999

  3. tls+tcp://:9999

The entire URI must be less than NNG_MAXADDRLEN bytes long.

Socket Address

When using an nng_sockaddr structure, the actual structure is either of type nng_sockaddr_in (for IPv4) or nng_sockaddr_in6 (for IPv6).

Transport Options

The following transport options are available. Note that setting these must be done before the transport is started.

NNG_OPT_TCP_KEEPALIVE

This option is used to configure TCP keep-alives. The value is of type bool, and defaults to false.

NNG_OPT_TCP_NODELAY

This option is used to configure Nagle’s algorithm. When enabled (false), the underlying TCP stream will attempt to buffer and coalesce messages before sending them on, waiting a short interval to improve buffering and reduce the overhead caused by sending too-small messages. This comes at a cost to latency, and is not recommended with modern high speed networks. The value is of type bool and defaults to true.

NNG_OPT_TLS_CONFIG

This option is used on an endpoint to access the underlying TLS configuration object. The value is of type nng_tls_config *.

Use this option when advanced TLS configuration is required.
NNG_OPT_TLS_CA_FILE

This is a write-only option used to load certificates associated associated private key from a file. See nng_tls_config_ca_file() for more information.

NNG_OPT_TLS_CERT_KEY_FILE

This is a write-only option used to load the local certificate and associated private key from a file. The private key used must be unencrypted. (Use the NNG_OPT_TLS_CONFIG option to access the underlying TLS configuration if more advanced configuration is needed.) See nng_tls_config_own_cert() for more information.

NNG_OPT_TLS_AUTH_MODE

This is a write-only option used to configure the authentication mode used. It can take an integer with value NNG_TLS_AUTH_MODE_NONE, NNG_TLS_AUTH_MODE_REQUIRED, or NNG_TLS_AUTH_MODE_OPTIONAL. See nng_tls_config_auth_mode() for more details.

NNG_OPT_TLS_VERIFIED

This is a read-only option which returns a Boolean value (integer 0 or 1). It will true (1) if the remote peer has been properly verified using TLS authentication, or false (0) otherwise. This option may return incorrect results if peer authentication is disabled with NNG_TLS_AUTH_MODE_NONE.

NNG Reference Manual vv1.0.0 © 2019 Staysail Systems, Inc, © 2018 Capitar IT Group BV
This document is supplied under the MIT License.
nanomsg™ and nng™ are trademarks of Garrett D'Amore.