Difficulty: Beginner
Estimated Time: 15-30 mins

If you’re deploying Conjur in production, you need to set up Transport Layer Security so that requests made to the server are encrypted in transit.

Note: if you use Conjur Enterprise, we handle this for you using an audited implementation that is similar to the technique described here.

First: A Brief Primer On Transport Layer Security (TLS)

This gets at the heart of the issue we’re trying to address with this tutorial.

Suppose you install Conjur and make it available at http://conjur.local. Then you configure clients to fetch secrets from that address. When they authenticate using the API, they provide their identity by sending their API key to the Conjur server. The Conjur server validates that the identity is authentic, then checks that the provided ID is authorized to retrieve the secret. Assuming this check passes, the Conjur server returns the secret value to the client.

However, this flow would be vulnerable in two ways. Suppose I were to impersonate the Conjur server and listen with my own illegitimate server on http://conjur.local. Then when your client goes to fetch a secret, I can take the API key you send and impersonate you to the real Conjur server. Now I control your identity and can learn your secrets without you finding out. This is called a man in the middle attack.

Note: you can use access logs or Conjur Enterprise’s audit records to discover unexplained accesses after the fact, but to maintain proactive security there is no substitute for TLS.

Even if I’m not able to impersonate the Conjur server, I could still learn secrets by joining your network and listening for traffic coming and going from the Conjur server. This is called passive surveillance.

TLS defeats passive and active attacks

Transport Layer Security allows your client to verify that it’s talking to the real Conjur server, and it uses standard secure technology to encrypt your secrets in transit. This means:

Your Conjur server URL will begin with https: instead of http:, just like a secure website Because the client can verify it’s talking to the real server, the “man in the middle” will be exposed and the client won’t leak any secret information Since the traffic to and from Conjur is scrambled using secure encryption, passive listeners on your network can’t learn anything about the contents of your secrets For these reasons, it is crucial to set up TLS correctly when you deploy Conjur.

Protect Your Secrets

Do not leave this to chance: even a small flaw can totally compromise your secrets. Setting up Conjur and TLS without the appropriate expertise is like packing your own parachute and jumping out of a plane.

That doesn’t mean you should close the tab and walk away. It means you should get in touch with us and your own security team so we can ensure that you can deploy Conjur successfully.


Enabling TLS for Conjur using Nginx Proxy

Step 1 of 7

Using NGINX To Proxy Traffic With TLS To Conjur

NGINX is a high performance free open source web server. This tutorial will show you how to use Docker to install Conjur and NGINX and configure them to use TLS.

Please note that the steps and scripts below are optimized for this course. For orignal procedure, please refer to Tutorial - NGINX Proxy at www.conjur.org**

To start out our experience on a high note, let’s get the full Conjur+TLS stack up and running so we can inspect it.

The tutorial script will install Conjur and NGINX, configure them to work together, and connect a client to Conjur via the NGINX proxy. This is a full end-to-end working installation to allow you to see how the pieces fit.

./start.sh https://[[HOST_SUBDOMAIN]]-8443-[[KATACODA_HOST]].environments.katacoda.com/

Take a look at the logs for the Conjur or NGINX servers:

docker-compose logs conjur
docker-compose logs proxy

Run some commands in the Conjur client:

docker-compose exec client bash
conjur authn whoami
conjur list

What’s happening here?

When you read the Conjur access logs, you’ll note that the Conjur server is listening on port 80 (insecure http) inside its container. However, that port is not exposed except on the local Docker network, so requests from the Internet and LAN are unable to reach it.

Meanwhile, the NGINX container is exposing its port 443 (https) to the outside network and proxying the traffic through to Conjur.