LinkedIn
Twitter
Introduction
A component of a common security pattern used by many of our customers includes deploying OPDK into an offline environment. This usually entails removing internet access from the nodes containing OPDK components, and installing a load balancer at the network perimeter. The load balancer is then used to manage request traffic between external and internal endpoints. Northbound request traffic is received with one way TLS that is configured and terminated at the load balancer. The load balancer forwards the request by creating a second one way TLS session to the Edge Routers. This security pattern is robust but poses a few challenges. Let’s discuss the challenge posed to validating signed certificates.
Challenge
We will maintain a high level discussion regarding several aspects pertaining to how TLS works in order to remain focused on working with signed certificates with offline on-premises Edge. The configuration of TLS is accomplished with the use of signed certificates that represent credentials. These signed certificates are then used to establish encrypted connections between two endpoints prior to transmitting data.
Endpoints that are presented with these signed certificates need to validate that the certificates are authentic and should be honored as a legitimate request from the signer of the certificate. This validation is accomplished with the use of a truststore. The truststore is protected and trusted offline storage that contains the material required to validate the signed certificates. The truststore must be updated prior receiving any signed certificates at an endpoint.
Nodes that are online can replace the use of a truststore with a trusted third party certifying authority, such as CA or Verisign. The certifying authority validates signed certificates as if they were in the truststore. This approach creates a distribution mechanism that can scale with the internet. Please take note that this is step 3 in Fig-1.
Nodes that are offline create a challenge because an offline node would be unable to consult with a certifying authority and validate the authenticity of a given certificate. Endpoints that are presented with a signed certificate will seek to validate that certificate with a certifying authority online. Please note that when we take On-premises Edge offline we break the ability of Edge Routers to validate a signed certificate online as reflected in step 3 of Fig-2.
Fig-2: One Way TLS with Broken Certificate Validation
Solution
The security provided by following this component of your security model can be realized if nodes that are offline fall back to using truststores. This means that offline nodes would not validate signed certificates with certifying authorities online as previously indicated but instead would use truststores for this purpose. The truststore is protected and trusted storage for the root and interim certificates issued by certifying authorities. These root and interim certificates are used by offline nodes to validate certificates that have been signed by those authorities.
Managing the Solution
Edge enables the use of TLS in the offline security scenario by centrally managing truststores. Edge typically uses several Routers. Managing truststores for several offline Routers could introduce a maintenance burden. However, Edge makes this maintenance burden easier by providing you with a central location from where truststores can be managed for all Routers. Truststore updates are distributed to all the Routers in a planet without an explicit maintenance effort, thereby reducing the maintenance burden imposed by the offline use of TLS. Please note how step 3 of Fig-3 now validates using the truststore centrally managed by Edge.
Fig-3: One Way TLS with Certificate Validation using a Truststore
For more on using TLS with Edge, see https://docs.apigee.com/api-platform/system-administration/ssl.
Thank you to @Saurabh Chhatwal for his valuable contribution to this article.