Locked-Down Networks Certificate Revocation

Locked-Down Networks Certificate Revocation

It is common in high-security networks to restrict Internet access to solely those services required. Imagine you have an industrial control system, it publishes statistics to a single public cloud service. You want to configure your firewall to block everything that is not that API endpoint. However, doing so breaks the TLS encryption since it needs to periodically check revocation.

There are two primary methods of checking certificate revocation: Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL). Both of these are encoded in your certificate chain.

Let’s examine the Agilicus api (api.agilicus.com):

OCSP: http://r3.o.lencr.org. This is the ‘Leaf’ certificate, the last one in the chain. Let’s Encrypt has more information here. Now, let’s take a look at the DNS resolution:

$ dig +noall +answer @8.8.8.8 r3.o.lencr.org
r3.o.lencr.org.		120	IN	CNAME	o.lencr.edgesuite.net.
o.lencr.edgesuite.net.	857	IN	CNAME	a1887.dscq.akamai.net.
a1887.dscq.akamai.net.	20	IN	A	72.136.197.57
a1887.dscq.akamai.net.	20	IN	A	72.136.197.65

And this is where the problem arises. There is a CDN, the IP list is large and constantly changing. We cannot allow outbound connections by IP to achieve our objective.

To work around this, Agilicus implements a transparent proxy with a fixed IP, the same IP our API uses:

$ dig +noall +answer @8.8.8.8 api.agilicus.com
api.agilicus.com.	3600	IN	A	35.203.36.11

We can test this:

$ curl  --resolve r3.o.lencr.org:80:35.203.36.11 -v -H "Host: r3.o.lencr.org" http://r3.o.lencr.org//MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgMUzps0GUA4tjrONIqrju8GDw%3D%3D

Here we are simulating a Let’s Encrypt OCSP lookup of a specific certificate to r3.0.lencr.org. We are overriding the IP address of the DNS resolution to 35.203.36.11. Thus if we allow this IP in the firewall, the Agilicus API, and Let’s Encrypt OCSP will both function.

Depending on your host architecture you might also have intermediate Certificate Revocation or Windows CTDL updates. These function in a similar fashion, overriding crl.verisign.com and ctldl.windowsupdate.com.

Additional IP for Agilicus Specifically

In addition to the OCSP and CRL which are part of the SSL ecosystem, Agilicus requires 2 outbound IP connectivity points:

1. API. To find the IP address, run ‘nslookup api.agilicus.com’ (35.203.36.11)
2. Auth. To find the IP address, run ‘nslookup auth.YOURDOMAIN’ (this will be the same IP address for https://admin.YOURDOMAIN as you sign-in to the Administrative API). 34.95.12.47. This will be the same IP you have set your CNAME wildcard to.

Implementation

The implementation is simple:

1. Add alias in either /etc/hosts or your local DNS for r3.0.lencr.org, crl.verisign.com, ctldl.windowsupdate.com pointing to api.agilicus.com
2. Allow api.agilicus.com IP in your firewall on port 443 (for all API access) and port 80 (for OCSP and CRL access)
3. Allow the IP of your Agilicus Authentication service (auth.YOURDOMAIN) port 443

At this stage your air-gapped system will be able to function in the limited way you intend, but securely with proper TLS encryption.

---