Luminate Connectors are small components deployed in customers' datacenters that reach out to the Luminate cloud via HTTPS in order to provide access to corporate resources.

For more detailed explanation on the system architecture, please refer to this article.

The basic architecture of a typical Luminate deployment is depicted in the following diagram:


The Luminate Connector, deployed in the corporate datacenter (physical or virtual) reaches out to the Luminate Cloud service via the datacenter firewall, requiring an HTTPS (port 443) connectivity to the Luminate Cloud.

Some corporate networks do not allow direct outbound internet connectivity, requiring all connections to pass through Secure Web Gateways, functioning as HTTPS proxies instead. Prominent solutions that are deployed in such configuration can be those from Symantec (formerly, BlueCoat) or ForcePoint (formerly Websense).

In such a case the communication architecture will look like the following:


The connectivity between the Luminate Connector and the Corporate Web Security Gateway is configured by defining HTTPS proxy settings for the Connector, including (in some cases) user/password authentication towards the gateway. The gateway, in turn, terminates the HTTPS/TLS encryption, inspects the traffic and opens a new HTTPS/TLS connection to the Luminate Cloud Service.

In order to allow communications in such a scenario, two explicit steps need to be made:

  1. Luminate Cloud Service needs to accept connections from Luminate Connectors involved in such an architecture without the pinning of their certificates. Please contact Luminate Support for directions on this step.
  2. Luminate Connectors should get configuration for the HTTPS proxy. Required configuration steps for such a deployment are described in this article.
  3. Luminate Connector should be able to verify the certificate of the Corporate Web Security Gateway. Required configuration steps for such a deployment are described in this article.

It is important to state, that such a deployment of Luminate connectors is not recommended, as it introduces very significant degradation to the built-in secure architecture of the Luminate platform, while not introducing any benefits that are expected from "regular" use of Secure Web Gateways.

Instead, we recommend to exempt the machines running Luminate Connectors from the policy requiring internet-bound connectivity to pass through the Secure Web Gateway and allow direct outbound communications over port 443 to the Luminate Cloud Service.

The common benefits of using Secure Web Gateways are:

  • Blocking unauthorized internet-bound communications (proxy requires user/password authentication)
  • Inspecting the outbound traffic and allowing traffic only to legitimate destinations (blocking either malicious sites or sites not recognized as explicitly approved for use), or allowing only legitimate operations (for example, browsing the internet, but not uploading files)
  • Inspecting the data that is being sent out and enforcing various Data Loss Prevention / Data Security policies

None of these benefits can apply to the traffic between Luminate Connectors and Luminate Cloud Service due to the following reasons:

  • The Connectors traffic is always authorized and, in order to function properly, the Connectors need to be allowed to authenticate to the proxy/gateway
  • Secure Web Gateway won't be able inspect the traffic, as Luminate Connectors use a dedicated protocol to transmit user communications, multiplexing a number of requests and responses into a single stream (in a binary format)

A detailed description of communications between the Luminate Connectors and the Luminate Cloud Service can be found in this article.

In addition to being unable to introduce its benefits, using Secure Web Gateways to terminate and inspect the traffic between Luminate Connectors and Luminate Cloud Service has the following negative impact on the security measures described in this article:

  • The Connector cannot verify the identity on the Luminate Cloud Service, as it does not validate (or perform any kind of pinning). The "peer" that the Connector can verify for its outbound TLS communications is, actually, the organization's Secure Web Gateway, which, in turn, connects to the Luminate Cloud Service, but, as it doesn't perform any pinning for its certificates, is under risk of being spoofed. 
  • The Luminate Cloud Service cannot verify the identity of the Connector. As explained in the article about Luminate Connectors, each Connector gets a unique ephemeral certificate that is being inspected by the Cloud Service. When the entity opening a TLS session towards the Luminate Cloud Service is the Secure Web Gateway, it is not possible to establish and verify the identity of the Luminate Connector.

Important: Above degradations in the Luminate Security Architecture can be exploited in various ways by malicious parties. Luminate Security does not recommend using SSL/TLS-Terminating Internet Proxy/Secure Web Gateway solution of any kind with the Connector->Cloud traffic. Our firm recommendation is to exempt this traffic from an inspection and allow direct internet communications between Luminate Connectors and Luminate Cloud Service. In addition to preventing potential security issues, direct communication will also ensure optimal performance.