Ziti networks use robust modern cryptography and security mechanisms. Each component within a Ziti network uses security technology that fits its role and use-cases.
Here are the different types of connections:
control- connections between a controller and a router that manage network state. Secured via mTLS 1.2+
link- connections between routers to form a mesh network. Secured via mTLS 1.2+
edge- multiplexed connections between an SDK and an Edge Router that carries
serviceconnections. Secured via mTLS 1.2+
controller APIs- connections between a controller and an SDK (or other software) via HTTPS and/or secure websockets. Secured via TLS, mTLS 1.2+
service- connections carried by an
edgeconnection and establish communication between a client and host. Application data is end-to-end encrypted via libsodium public private key cryptography.
Below is a diagram showing the
controller API connections. The
exist within an
edge connection and are pictured in more detail in the second diagram.
Connections between SDKs and Edge Routers are called
edge connections are multiplexed and carry
service connections. Each connection is for a specific service and secured with end-to-end encryption in
order to transport application/service data securely between the two intended parties only.
Control and Link Connection Details
Routers work in concert with a controller to establish a mesh network of
link connections between routers. Routers coordinate
with a controller over a
control connection. These connections are initialized and maintained while the network is in
link connections are always authenticated using mTLS. The certificates that enable mTLS
control connections are exchanged during router enrollment. The
control connection between controllers and
Edge Routers is used to continuously update routers with the proper certificate information for all other routers in
Controller API Connection Details
Controller APIs provide ways for clients (SDKs or otherwise) to interact with a network. The Edge Management API is used for configuration and maintenance. The Edge Client API is used to allow clients to authenticate, discover services, request service Sessions, discover Edge Routers, and to perform basic self-maintenance.
Access to the APIs requires authentication which results in an API Session
being returned to the client. An API Session is required to make
Edge Connection Details
edge connections are made between SDKs and Edge Routers. They require the following:
- a valid API Session represented by a token
- a valid x509 certificate associated with the supplied API Session
- a target Edge Router
An API Session is obtained during authentication with either the Edge Client or Management APIs. It is represented as a token. The x509 certificate used to establish the mTLS connection may either be the certificate used during authentication (if used) or an API Session Certificate.
edge connections once establish allow the use of Session tokens to establish
service connections. When a Session is created, a list of valid Edge Router
is included in the response.
Service Connection Details
service connections represent an SDK that has connected to a service (dial) or is hosting a service (bind). To
service connection of either type the following is required:
edgeconnection to an Edge Router that has the correct policies in place to support the target service and intent (dial/bind)
- a Session for the target service and intent (dial/bind)
Sessions are issued by the controller's Edge Client API. A valid Sessions token must be included with dial and bind requests. Edge Routers validate Session tokens continuously. If valid, the Edge Router will facilitate the connecting the client to a service or registering the client as a host.
Should a Session become invalid at any point, any existing
service connection that
was established using the invalidated session will be terminated. Attempts to re-establish connection with the
invalidated Session will be refused.