Working with Ciphers

Introduction

The goal of this article is to inform you what cipher suites a Greymatter v1.8 proxy supports by default, and what to do if your proxy needs to support other cipher suites.

A cipher suite is a squad of cryptographic algorithms used in the TLS protocol. The algorithms within a suite, all having different roles along the way, come together to secure a connection between two devices. There are hundreds of different cipher suites that contain different combinations of these algorithms, some more secure than others. We are not going to dive into each algorithm and their specific roles, but i will provide a quick example to highlight why they are so relevant.

This is useful when trying to form a TLS/SSL connection between a Greymatter proxy and an older externally-hosted service.

The Relevance of Cipher Suites

Let’s say you have a Greymatter mesh deployed in some environment. You also have some service paired with a proxy integrated in that mesh. Imagine your service depends on some externally-hosted TLS-enabled HTTP server, so you configure your proxy to route to the server.

When your proxy (the client) tries to form a TLS connection with the HTTP server, it will provide the server with a list of the cipher suites it supports. The server would then choose a mutually supported cipher suite (supported by both client and server) that it deems the most secure. After that mutual cipher suite is chosen, the TLS connection gets established using the algorithms within that suite.

But wait, what happens if the client and the server don’t have any mutually supported cipher suites? Well, you’ll be barraged by some ill-defined SSL handshake errors. It makes sense though, when a client and server can’t agree on a mutual cipher suite, the handshake fails and the connection is dropped. To make sure this doesn’t happen to you, I’m going to provide you with a list of cipher suites that a Greymatter 1.8 proxy supports by default, and how to expand upon that list if need be.

Greymatter’s Default Cipher Suites

By default, a Greymatter 1.8 proxy will support these Cipher Suites:

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384

Overwrite the Default Cipher Suites

If you are trying to make requests to a server from a GM 1.8 proxy but the server doesn’t support one of the 4 cipher suites listed above, then you will need to statically define at least one cipher suite that the server supports. Keep in mind, once you statically define a cipher suite(s) it will overwrite the defaults. That means if you want to keep the defaults, be sure to include them in your definition. You can specify the proxy’s permitted cipher suites on any of its (M)TLS listeners or (M)TLS upstreams.

Here is what it looks like in GSL:

gsl.#MTLSUpstream & {
	ssl_config: {
		cipher_filter: "COLAN:DELIMITED:LIST:OF:CIPHERS"
	}
}

gsl.#TLSUpstream & {
	ssl_config: {
		cipher_filter: "COLAN:DELIMITED:LIST:OF:CIPHERS"
	}
}

gsl.#MTLSListener & {
	ssl_config: {
		cipher_filter: "COLAN:DELIMITED:LIST:OF:CIPHERS"
	}
}

gsl.#TLSListener & {
	ssl_config: {
		cipher_filter: "COLAN:DELIMITED:LIST:OF:CIPHERS"
	}
}

The "COLAN:DELIMITED:LIST:OF:CIPHERS" would be where you put your list of permissible cipher suites, all in one string, each one separated by a :.

Practical Example

Remember our scenario in The Relevance of Cipher Suites section? Let’s assume the TLS-enabled HTTP server is hosted at https://randomdomain.com and we want to connect our proxy to it. The problem is, the server doesn’t supported any of the 4 cipher suites that our proxy does (the client). Due to this mismatch, the TLS/SSL connection is being dropped and we are seeing TLS/SSL handshake errors. To combat this we can:

1. Find out what cipher suites the server supports

2. Configure our proxy to contain at least 1 matching cipher suite

Let’s assume that we already did step 1 and we know the server supports these 3 cipher suites:

• AES128-SHA

• AES256-SHA

• AES128-GCM-SHA256

To accomplish step 2, within your service GSL config file we would have an egress block that would look something like this:

egress: {
   "random-service": {
      gsl.#HTTPListener
      gsl.#MTLSListener
      port: 10909
      routes: {
         "/": {
            prefix_rewrite: "/"
            upstreams: {
               "randomdomain": {
                  gsl.#Upstream
                  gsl.#MTLSUpstream & {
					 ssl_config: {
						cipher_filter: "AES128-SHA:AES256-SHA:AES128-GCM-SHA256"
					 }
                  }
                  instances: [
                     {
                        "host": "randomdomain.com"
                        "port": 443
                     }
                  ]
               }
            }
         }
      }
   }
}

You can see that between lines 12-16 we manually define the 3 cipher suites that we know are supported by the server. They are defined within the proxy’s upstream to the randomdomain.com server to ensure our proxy presents the proper cypher suites when attempting to form a MTLS connection with the upstream server. With this configuration, during the TLS/SSL handshake the server will see that it shares 3 common cipher suites with our client. It will then pick the most secure one and our connection will be established. Problem solved.

Useful Commands

Here are some useful commands to run from a GM1.8 proxy container when debugging similar connection errors:

curl localhost:8002/clusters

curl localhost:8002/config_dump

curl localhost:8002/stats | grep ssl

curl localhost:8002/stats | grep ssl.ciphers

curl -X POST localhost:8002/logging?level=debug

Example output of curling for the ssl ciphers on a greymatter proxy:

sh-4.4$ curl localhost:8002/stats | grep ssl.ciphers

cluster.audits.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 6
cluster.catalog.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 17
cluster.controlensemble.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 2
cluster.dashboard.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 16
cluster.greymatter-datastore.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 3
cluster.prometheus.ssl.ciphers.ECDHE-RSA-AES128-GCM-SHA256: 3
listener.0.0.0.0_10808.ssl.ciphers.TLS_AES_128_GCM_SHA256: 21
listener.0.0.0.0_10908.ssl.ciphers.TLS_AES_128_GCM_SHA256: 4