v0.18.10

Release 0.18.10

What's New

• Close terminating xgress instances if no start is received with a configurable timeout
  • Timeout is set in the router config under listener/dialer options: sessionStartTimeout
    Default value: 3m
• Don't add a second shutdown timer if one is already set
• Allow list/updating router forwarding tables if --debug-ops is passed
  • new command ziti ps route <optional target> <session> <src-address> <dest-address>
  • new command ziti ps dump-routes <optional target>
• If an xgress session fails in retransmit, sends fault notification to controller so
  controller can fix path or remove session, depending on session state

v0.18.9

Release 0.18.9

What's New

• Fix PATCH OS Posture Checks clearing data
• Fix ziti-tunnel panic when removing services. edge#517
• ziti-tunnel tproxy now supports --lanIf option to automatically add rules to accept incoming
  connections for service connections. edge#519
• Fix orphaned ottca enrollments after `DELETE /cas/'
• Add build info output when starting router/controller
• Remove histograms from xgress dataflow path as they were causing bottlenecks

v0.18.8

Release 0.18.8

What's New

• Websocket binding in Edge Router to support connections from BrowZer-based apps that use
  the ziti-sdk-js. Edge Routers support various configurations including a single tls binding, a
  single ws binding, or having both tls and ws bindings simultaneously. If both binding types
  are used, they must be specified with different ports.
• Edge Router list for current identity
• Fix terminator PATCH, don't update/clear peer data unless requested
• Fix concurrency related crash in router
• Fix resource leak in fabric: forwarder tables weren't always updated after unroute

Websocket Binding

#   Example Edge Router config snippet (note new `ws` address type):

listeners:
  - binding: edge
    address: ws:0.0.0.0:3021
    options:
      advertise: curt-edge-ws-router:3021
  - binding: edge
    address: tls:0.0.0.0:3022
    options:
      advertise: curt-edge-ws-router:3022

• Fix router memory leak: purge session from forwardTable during unroutTimeout

Edge Router List For Current Identity

A new endpoint has been added which will display the list of Edge Routers an authenticated session
has access to via any policy. The records will indicate whether the router is online, its hostname,
and its supported protocols. This endpoint will not return Edge Routers that have not completed
enrollment. Edge Routers that are offline will not have hostname and supported protocol information.

Endpoint: GET /current-identity/edge-routers

Example Output:

{
    "data": [
        {
            "createdAt": "2021-01-27T20:13:18.599Z",
            "id": "LolSlAQMq",
            "tags": {},
            "updatedAt": "2021-01-27T20:13:19.762Z",
            "hostname": "",
            "isOnline": false,
            "name": "er1",
            "supportedProtocols": {}
        },
        {
            "createdAt": "2021-01-27T20:13:19.308Z",
            "id": "oVzRl6kCq",
            "tags": {},
            "updatedAt": "2021-01-27T20:13:19.901Z",
            "hostname": "127.0.0.1:5002",
            "isOnline": true,
            "name": "er2",
            "supportedProtocols": {
                "tls": "tls://127.0.0.1:5002",
                "wss": "wss://127.0.0.1:5002"
            }
        }
    ],
    "meta": {
        "filterableFields": [
            "id",
            "createdAt",
            "updatedAt",
            "name",
        ],
        "pagination": {
            "limit": 10,
            "offset": 0,
            "totalCount": 2
        }
    }
}

v0.18.7

Release 0.18.7

What's New

• Update ziti-tunnel service polling
  • Now uses new api (when available) to skip refreshing services if no services have been changed
  • Polling rate is passed through to sdk, so actual poll rate is now controlled
• Don't panic on router startup, just show error message and exit
• Fix resource leak: go-routine on terminators using the edge_transport binding
• Fix resource leak: retransmission timers for xgress instances not being shutdown when xgress
  closed
• Control channel metrics now available
• Fix potential deadlock on xgress close
• When closing due to fault notification, wait for data coming from remote to stop, not data from
  both local and remote, since local writes may never stop, due to retransmission attempts
• Add new config option to router xgressCloseCheckInterval, which dictates for how long data flow
  from the remote should have stopped before closing xgress after receiving fault
• limit none for Edge API Rest requests is now properly limited to 500 elements on list endpoints
• The HTTP header server is now populated on all responses with ziti-controller/vX.Y.Z

Control Channel Metrics

Note: This feature is only available if both controller and router are on 0.18.7 or higher.

The control channels between the controller and routers now generate metrics, including:

• ctrl.<router id>.latency
• ctrl.<router id>.tx.bytesrate
• ctrl.<router id>.tx.msgrate
• ctrl.<router id>.tx.msgsize
• ctrl.<router id>.rx.bytesrate
• ctrl.<router id>.rx.msgrate
• ctrl.<router id>.rx.msgsize

There is a new controller config file setting:

• ctrlChanLatencyIntervalSeconds which controls how often the latency probe is sent. Default
  value: 10

v0.18.6

Release 0.18.6

What's New

• Fix ziti install terraform-provider-edgecontroller

v0.18.5

Release 0.18.5

What's New

• Update go-openapi libraries
• xgress_edge refactor, should fix 'failed to dipsatch to fabric' errors
• Update ziti use command to work with main branch
• MFA Support
• Fix deadlock on session close in router when connection is at capacity
• Fix issue where end of session didn't get sent in some scenarios

MFA Support

Endpoint MFA is available that is based on RFC 4226 (HOTP: An HMAC-Based One-Time Password
Algorithm) and RFC 6238 (TOTP: Time-Based One-Time Password Algorithm). These standards are
compatible with standard "Authenticator" apps such as Google Authenticator and Authy. MFA is
suggested to be used in situations where human operators are involved and additional security is
desired.

Restricting Service Access

Services can now have a Posture Check of type MFA that can be created and associated with a Service
Policy. Service Policies that are associated with an MFA Posture Check will restrict access to
services if a client has not enrolled in MFA and passed an MFA check on each login.

MFA Posture Checks support only the basic Posture Check fields:

• name - a name for the posture check
• typeId - should be "MFA"
• tags - any tags desired for this object
• roleAttributes - role attributes used to select this object from Service Policies

Example:

POST /posture-checks
{
    "name": "Any MFA",
    "typeId": "MFA",
    "roleAttributes": ["mfa"]
}

Admin MFA Management

Admins of the Ziti Edge API can remove MFA from any user. However, they cannot enroll on behalf of
the client. The client will have to initiate MFA enrollment via their client.

Endpoints:

• DELETE /identities/<id>/mfa - remove MFA from an identity
• GET /identities - has a new field isMfaEnabled that is true/false based on the identity's MFA
  enrollment
• GET /identities/<id>/posture-data - now includes a sessionPostureData field which is a map of
  sessionId -> session posture data (including MFA status)

Example Posture Data:

{
  "mac": ["03092ac3bc69", "2b6df1dc52d9"],
  "domain": "mycorp.com",
  "os": {
    ...
  },
  processes: [
    ...
  ],
  sessionPostureData: {
     "xV1442s": {
        "mfa": {
          "passedMfa": true
        }
     }
  }
}

Client MFA Enrollment

Clients must individually enroll in MFA as the enrollment process includes exchanging a symmetric
key. During MFA enrollment the related MFA endpoints will return different data and HTTP status
codes based upon the state of MFA enrollment (enrollment not started, enrollment started, enrolled).

The general MFA enrollment flow is:

1. Authenticate as the identity via POST /authenticate
2. Start MFA enrollment via POST /current-identity/mfa
3. Retrieve the MFA provisioning URL or QR code
   • GET /current-identity/mfa
   • GET /current-identity/mfa/qr-code
4. Use the provisioning URL or QR code with an authentication app such as Google Authenticator,
   Authy, etc.
5. Use a current code from the authenticator to POST /current-identity/mfa/verify with the code in
   the code field {"code": "someCode"}

MFA Endpoints Overview:

This section is an overview for the endpoints. Each endpoint may return errors depending on in input
and MFA status.

• GET /current-identity/mfa - returns the current state of MFA enrollment or 404 Not Found
• POST /current-identity/mfa - initiates MFA enrollment or 409 Conflict
• DELETE /current-identity/mfa - remove MFA enrollment, requires a valid TOTP or recovery code
• GET /current-identity/mfa/recovery-codes - returns the current recovery codes, requires a valid
  TOTP Code
• POST /current-identity/mfa/recovery-codes - regenerates recovery codes, requires a valid TOTP
  code
• POST /current-identity/mfa/verify - allows MFA enrollment to be completed, requires a valid TOTP
  code
• GET /current-identity/mfa/qr-code - returns a QR code for use with QR code scanner, MFA
  enrollment must be started
• POST /authenticate/mfa - allows MFA authentication checks to be completed, requires a valid TOTP
  or recovery code

MFA Enrollment Not Started:

• GET /current-identity/mfa - returns HTTP status 404
• POST /current-identity/mfa - start MFA enrollment, 200 Ok
• DELETE /current-identity/mfa - returns 404 Not Found
• GET /current-identity/mfa/recovery-codes - returns 404 Not Found
• POST /current-identity/mfa - returns 404 Not Found
• POST /current-identity/mfa/verify - returns 404 Not Found
• GET /current-identity/mfa/qr-code - returns 404 Not Found

MFA Enrollment Started:

• GET /current-identity/mfa - returns the current MFA enrollment and recovery codes
• POST /current-identity/mfa - returns 409 Conflict
• DELETE /current-identity/mfa - aborts the current enrollment, a blank code may be supplied
• GET /current-identity/mfa/recovery-codes - returns 404 Not Found
• POST /current-identity/mfa - returns HTTP status 409 Conflict
• POST /current-identity/mfa/verify - validates the supplied code
• GET /current-identity/mfa/qr-code - returns a QR code for use with QR code scanner in PNG format

MFA Completed:

• GET /current-identity/mfa - returns the current MFA enrollment, but not recovery codes
• POST /current-identity/mfa - returns 409 Conflict
• DELETE /current-identity/mfa - removes MFA, a valid TOTP or recovery code must be supplied
• GET /current-identity/mfa/recovery-codes - shows the current recovery codes, a valid TOTP code
  must be supplied
• POST /current-identity/mfa - returns HTTP status 409 Conflict
• POST /current-identity/mfa/verify - returns HTTP status 409 Conflict
• GET /current-identity/mfa/qr-code - returns 404 Not Found

Client MFA Recovery Codes

Client MFA recovery codes are generated during enrollment and can be regenerated at any time with a
valid TOTP code. Twenty codes are generated and are one time use only. Generating new codes replaces
all existing recovery codes.

To view:

GET /current-identity/mfa/recovery-codes
{
  "code": "123456"
}

To Generate new codes:

POST /current-identity/mfa/recovery-codes
{
  "code": "123456"
}

Authentication

During API Session authentication a new authQuery field is returned. This field will indicate if
there are any outstanding authentication Posture Queries that need to be fulfilled before
authentication is considered complete.

When MFA authentication is required a field will now appear as an
authQuery with the following format:

{
  ...
  "token": "c68a187a-f4af-490c-a9dd-a09076511419",
  "authQueries": [
    ...,
    {
      "typeId": "MFA",
      "provider": "ZITI",
      "httpMethod": "POST",
      "httpUrl": "./authenticate/mfa",
      "minLength": 4,
      "maxLength": 6,
      "format": "alphaNumeric"
    },
    ...
  ]       
}

v0.18.4

Release 0.18.4

What's New

• New ziti CLI command ziti ps set-log-level, allows you to set the application wide log level at
  runtime
• Allow invalid event types in controller config event subscriptions. Instead of failing to start,
  the controller will emit a warning. This allows us to use uniform configs across controllers which
  may not all support the same event types.
• Edge routers now have configurable timeouts when looking up API sessions and sessions

Edge Router: Configurable Session Lookup Times

An Edge SDK client will create and api session and session with the controller first, then attempt
to use those sessions at an edge router. The controller will push session information to routers as
quickly as it can, but clients may still connect to the edge router before the client can. We
previously would wait up to 5 seconds for session to arrive before declaring a session invalid, but
would not wait for api-sessions.

We can now wait for both api-sessions and sessions. Both timeouts are configurable. They are
configured in the router config file under listeners options.

• lookupApiSessionTimeout
  • How long to wait before timing out when looking up api-sessions after client connect. Default
    5 seconds.
• lookupSessionTimeout
  • How long to wait before timing out when looking up sessions after client dial/bind. Default 5
    seconds.

Example router config file stanza:

listeners:
  - binding: edge
    address: tls:0.0.0.0:6342
    options: 
      advertise: 127.0.0.1:6432
      lookupApiSessionTimeout: 5s
      lookupSessionTimeout: 5s

v0.18.3

Release 0.18.3

What's New

• Ziti executables that use JSON logging now emit timestamps that include fractional seconds.
  Timestamps remain in the RFC3339 format.
• Authentication mechanisms now allow appId and appVersion in sdkInfo
• Ziti executables that use JSON logging now emit timestamps that include fractional seconds.
  Timestamps remain in the RFC3339 format.
• Improved query performance by caching antlr lexers and parsers. Testing showed 2x-10x performance
  improvement
• Improve service list time by using indexes get related posture data
• Improved service polling
• Improved service policy enforcement - instead of polling this is now event based, which should
  result in slower cpu utlization on the controller
• Fixed a bug in service policy PATCH which would trigger when the policy type wasn't sent
• Support agent utilitiles (ziti ps) in ziti-tunnel
• Cleanup ack handler goroutines when links shut down
• Remove the following fabric metrics timers, as they degraded performance while being of low value
  • xgress.ack.handle_time
  • xgress.payload.handle_time
  • xgress.ack_write_time
  • xgress.payload_buffer_time
  • xgress.payload_relay_time
• The check-data-integrity operation may now only run a single instance at a time
  • To start the check, ziti edge db start-check-integrity
  • To check the status of a run ziti edge db check-integrity-status
• The build date in version info spelling has been fixed from builDate to buildDate
• A new metric has been added for timing service list requests services.list
• A bug was fixed in the tunneler which may have lead to leaked connections
• Ziti Edge API configurable HTTP Timeouts
• Add ziti log-format or ziti lf for short, for formating JSON log output as something more
  human readable
• fabric#151 Add two timeout settings to the
  controller to configure how long route and dial should wait before timeout
  • terminationTimeoutSeconds - how long the router has to dial the service
  • routeTimeoutSeconds - how long a router has to respond to a route create/update message
• fabric#158 Add a session creation timeout to the
  router. This controls how long the router will wait for fabric sessions to be created. This
  includes creating the router and dialing the end service, so the timeout should be at least as
  long as the controller terminationTimeoutSecondsand routeTimeoutSeconds added together
  • getSessionTimeout is specified in the router config under listeners: options:

Improved Service Polling

There's a new REST endpoint /current-api-session/service-updates, which will return the last time
services were changed. If there have been no service updates since the api session was established,
the api session create date/time will be returned. This endpoint can be polled to see if services
need to be refreshed. This will save network and cpu utilization on the client and controller.

Ziti Edge API configurable HTTP Timeouts

The controller configuration file now supports a httpTimeouts section under
edge.api. The section and all of its fields are optional and default to the values of previous
versions.

For production environments these values should be tuned for the networks intended userbase. The
quality and latency of the underlay between the networks endpoints/routers and controller should be
taken into account.

edge:
  ...
  api:
    ...
    httpTimeouts:
      # (optional, default 5s) readTimeoutMs is the maximum duration for reading the entire request, including the body.
      readTimeoutMs: 5000
      # (optional, default 0) readHeaderTimeoutMs is the amount of time allowed to read request headers.
      # The connection's read deadline is reset after reading the headers. If readHeaderTimeoutMs is zero, the value of
      # readTimeoutMs is used. If both are zero, there is no timeout.
      readHeaderTimeoutMs: 0
      # (optional, default 10000) writeTimeoutMs is the maximum duration before timing out writes of the response.
      writeTimeoutMs: 100000
      # (optional, default 5000) idleTimeoutMs is the maximum amount of time to wait for the next request when keep-alives are enabled
      idleTimeoutMs: 5000

v0.17.8

Release 0.17.8

• Ziti Edge API configurable HTTP Timeouts
• Add ziti log-format or ziti lf for short, for formating JSON log output as something more
  human readable
• fabric#151 Add two timeout settings to the
  controller to configure how long route and dial should wait before timeout
  • terminationTimeoutSeconds - how long the router has to dial the service
  • routeTimeoutSeconds - how long a router has to respond to a route create/update message
• fabric#158 Add a session creation timeout to the
  router. This controls how long the router will wait for fabric sessions to be created. This
  includes creating the router and dialing the end service, so the timeout should be at least as
  long as the controller terminationTimeoutSecondsand routeTimeoutSeconds added together
  • getSessionTimeout is specified in the router config under listeners: options:

Ziti Edge API configurable HTTP Timeouts

The controller configuration file now supports a httpTimeouts section under
edge.api. The section and all of its fields are optional and default to the values of previous
versions.

For production environments these values should be tuned for the networks intended userbase. The
quality and latency of the underlay between the networks endpoints/routers and controller should be
taken into account.

edge:
  ...
  api:
    ...
    httpTimeouts:
      # (optional, default 5s) readTimeoutMs is the maximum duration for reading the entire request, including the body.
      readTimeoutMs: 5000
      # (optional, default 0) readHeaderTimeoutMs is the amount of time allowed to read request headers.
      # The connection's read deadline is reset after reading the headers. If readHeaderTimeoutMs is zero, the value of
      # readTimeoutMs is used. If both are zero, there is no timeout.
      readHeaderTimeoutMs: 0
      # (optional, default 10000) writeTimeoutMs is the maximum duration before timing out writes of the response.
      writeTimeoutMs: 100000
      # (optional, default 5000) idleTimeoutMs is the maximum amount of time to wait for the next request when keep-alives are enabled
      idleTimeoutMs: 5000

v0.17.7

Release 0.17.7

This release has no fucntional changes only build process changes.