Technology

WARP is a proxy that helps you connect to the internet while simultaneously optimizing and securing (i.e. encrypting) your connection, giving you access to you appliance, no matter where you are.

In addition to the secure WebSocket encryption outlined above, the Portal also contains a second layer of security: PGP encryption.

Once the initial mTLS handshake has been completed, the Shuttle then creates its own PGP keys, which are then used for communication and verification with the ADCs. However, before data can be transferred from the client to the Shuttle, it must first pass through an intermediary key. This Certificate Chain enables the receiver to verify that the sender and all Certificate Authorities are trustworthy.

Every user needs not only their own private key, but also a copy of the organisation key to read the data that’s coming in from the Shuttle. This means new users will need to be invited by the organisation to register, and actively given a copy of the organisation key (as well as activating their own private user key). In this way it is the organisation who is the owner of everything - not the user.

And with the potential for multiple levels of encryption using different keys, it would be almost impossible to decrypt what is imprinted on the public key without also being in possession of a private key. In this way, if someone were to compromise or intercept the messages being transmitted by the Shuttle, break the TLS encryption and obtain the encrypted PGP data, they would still need the Shuttle’s private key to be able to read it.

In this way, data communications are sent via the Shuttle which acts as an intermediary or sidecar agent. but the Shuttle is unable to read these messages. Its only role is to act as a vector to forward this information when, and only when, the private and public keys match.

Multiple shuttles within the same namespace can operate simultaneously in an N+ Active HA configuration. Shuttles form an encrypted peer-to-peer mesh, sharing a common encryption key via key exchange coordinated through the Portal. ADC credentials are migrated from local shuttle storage to the Portal, encrypted with the mesh shared key so that only shuttles in the mesh can decrypt them. The mesh self-heals if a shuttle goes offline, the Portal detects the stale heartbeat, notifies remaining members, and automatically resolves any subnet conflicts caused by the departed member. New shuttles joining an existing mesh receive the shared key from a healthy peer and begin operating without manual intervention.

As discussed above, the Shuttle is a key component in ADC portal communication. In addition, the gateway service is used on the Loadbalancer.org Enterprise appliance and API calls are used with the Loadbalancer.org Endurance appliance and 3rd party appliances.

Shuttle Service : Acts as an intermediary sidecar agent for ADCs to communicate with the Portal. Shuttles can be provisioned as a standalone Linux instance running the Shuttle service or as a Loadbalancer.org appliance running its Shuttle service.

Gateway Service :Used on Loadbalancer.org Enterprise appliances to gather appliance details and pass them to the ADC Portal via a Shuttle. It also enables backups and other remote tasks to be run.

Vendor Specific API Calls : Used to gather details for Loadbalancer.org Endurance appliances and appliances from 3rd party vendors and pass them to the ADC Portal via a Shuttle. API calls are also used to control backups and other remote tasks.

If ADCs are located in remote subnets, the standalone Shuttle can be used (which enables subnets to be configured) - for more information, see Network Topology. Alternatively, one or more Shuttles can be configured in each remote subnet.

The following diagram illustrates how multiple ADCs from various vendors connect to the ADC Portal via a Standalone Linux instance running the Shuttle service.