Enable TLS on Memcached

The fix/etc/memcached.conf

# Requires a binary built with --enable-tls
-Z
-o ssl_chain_cert=/etc/memcached/certs/server.pem
-o ssl_key=/etc/memcached/certs/server.key

What is unencrypted without it

Everything. The memcached protocol — ASCII and binary alike — is plaintext on the wire, so anything with visibility of the path sees:

• the keys, which are frequently descriptive enough to matter on their own (session:, user:1234:profile, password_reset:)
• the values, which is whatever you cached — session objects, rendered fragments, query results, personal data
• the credentials, if you enabled authentication without TLS

That last one is the sharpest edge. Turning on -Y auth over a plaintext connection puts a reusable password on the network on every connect.

When it is worth it

Honest scoping, because this is rated medium rather than high deliberately:

If memcached is bound to loopback — the recommended arrangement, and the Debian default — the traffic never touches a network. TLS adds handshake cost and operational burden for no gain. Skip it.

If clients are on other hosts, TLS is the control that makes that safe, and it moves up in importance the more sensitive the cached data is. A cache holding session tokens on a shared or cloud network is the case that justifies it.

The severity reflects the common deployment, where the exposure is already closed by the binding. It is not a comment on how well TLS works.

The build problem again

TLS arrived in 1.5.13 and requires ./configure --enable-tls with OpenSSL 1.1.0 or later. As with SASL, distribution packages have historically shipped without it — Ubuntu carried a bug specifically about TLS not being enabled in its memcached package for versions that supported it.

So check the binary before designing around this:

memcached -h | grep -i ssl

No output means this build cannot do TLS regardless of flags. Options at that point: use a build that has it, put the traffic on a private network you control, or terminate encryption outside memcached with a stunnel or a service mesh sidecar and keep memcached on loopback behind it. The last is often the least work and needs no rebuild.

Certificate and key handling

ssl_chain_cert wants the certificate with its chain; ssl_key is the private key. Memcached drops privileges to the memcache user, and unlike a web server it does not read the key as root before dropping — so the key must be readable by the runtime user, and therefore protected by ownership rather than by being root-only:

sudo install -d -m 750 -o memcache -g memcache /etc/memcached/certs
sudo chown memcache:memcache /etc/memcached/certs/server.key
sudo chmod 400 /etc/memcached/certs/server.key

This differs from nginx and HAProxy, where the key stays root-owned because a privileged parent reads it at startup. Do not carry that habit across — here it produces a daemon that cannot read its own key.

ssl_verify_mode controls client-certificate verification, for mutual TLS where the clients are yours and you want the cache to refuse anything else.

Verify it worked

Confirm the daemon believes TLS is on:

printf 'stats settings\r\n' | nc 127.0.0.1 11211 | grep -i ssl

Look for ssl_chain_cert pointing at your certificate and a sane ssl_min_version.

Then prove it on the wire, which is the claim that matters:

openssl s_client -connect YOUR_SERVER:11211 -brief </dev/null

Expect a completed handshake and a protocol version. A connection that returns nothing useful means the listener is still plaintext.

Confirm plaintext is genuinely refused rather than merely discouraged — a TLS listener that also answers unencrypted has not closed anything:

printf 'stats\r\n' | nc YOUR_SERVER 11211

Expect no usable reply.

Before you apply this

Enabling TLS breaks every client that is not configured for it, at restart, with no reload path and an empty cache afterwards.

Memcached supports mixing TLS and non-TLS listeners, which is what makes a staged rollout possible — the -l flag takes a notls prefix so you can keep a plaintext loopback listener for local monitoring while remote clients move to TLS:

-l notls:127.0.0.1:11211
-l 10.0.1.20:11212

Migrate in that order: add the TLS listener, move clients to it one at a time, then remove the plaintext one.

Certificate expiry becomes an outage source that did not exist before. Whatever renews the certificate must also restart memcached, and that restart empties the cache — so an unattended 3am renewal becomes an unattended 3am cold cache. Know that before automating it:

openssl x509 -enddate -noout -in /etc/memcached/certs/server.pem

Client libraries vary in TLS support and in whether they verify the certificate at all. Confirm yours does, or you have encryption without authentication of the server.

Related

• Require authentication — the credentials this protects in transit.
• Bind Memcached to localhost — if this applies, you may not need TLS at all.