Cipher Policy Without a Cryptography Degree

Cipher configuration is where a lot of administrators freeze. The screen offers a long list of intimidating names — strings of algorithms and key sizes separated by dashes and underscores — and the honest fear is that picking wrong will either break connections or quietly leave something insecure. So the list gets left at whatever the software shipped with, which may be excellent or may be a decade of accumulated backward-compatibility cruft, and nobody knows which.

Here is the reassuring truth: you do not need to understand the cryptography to set a sound cipher policy. The algorithms are designed and vetted by specialists; your job is not to invent or evaluate them but to choose sensibly from vetted options and disable the retired ones. That reduces to a handful of decisions, and this article walks through each: what a cipher suite actually is, the protocol-version floor that matters more than any individual cipher, how to think in cipher families instead of memorizing names, what a safe default looks like, how to test what an endpoint really negotiates, and when a real-world constraint justifies deviating.

This article is deliberately evergreen. It names no specific version numbers or cipher strings, because those shift over time and any list printed here would eventually mislead you. Instead it teaches the decision framework and the testing method — the parts that stay true — and points you to the authoritative sources for the current specifics. This is part of our Encryption in Transit series; it assumes the mechanics from how TLS protects transfers and how SSH protects transfers, though a quick reader will keep up.

What a Cipher Suite Actually Is

Every one of those intimidating strings is just a bundle of choices — one algorithm for each job in a secure connection, packaged together so both sides can agree on the whole set at once. Break one apart and the pieces map directly onto the handshake you already understand:

• Key exchange — how the two sides build their shared secret. This is where forward secrecy lives: ephemeral key exchange discards its inputs after each session, so recorded traffic cannot be decrypted later even if a long-term key is stolen. This is the single most valuable property to prefer.
• Authentication — how the server proves its identity, tied to its certificate or host key.
• Bulk encryption — the fast symmetric cipher that encrypts the actual file data once the handshake is done.
• Integrity — how each record is stamped so tampering is detected. Modern suites fold encryption and integrity into a single authenticated mode, which is both faster and harder to misuse.

When two machines connect, they compare their supported suites and pick the best one they share. So your "cipher policy" is really two lists: which suites (and protocol versions) you offer, and — just as important — which you refuse. A weak option left enabled is not neutral; it is a door an attacker can try to push everyone through, using the downgrade tricks described later. Configuring policy is curating those lists.

Decision One: Set the Protocol-Version Floor

Before any individual cipher, make the decision that matters most: the protocol version floor — the oldest version of TLS or SSH your endpoint will agree to speak. This one setting eliminates more risk than any amount of fiddling with individual suite names, because old protocol versions carry structural weaknesses that no choice of cipher within them can repair.

Both TLS and SSH have evolved through numbered versions. The older ones have known, published flaws; the current ones are sound. Your policy in evergreen terms:

• Disable the legacy versions. The early SSL-branded versions of TLS, and the first SSH protocol generation, are obsolete and should be refused outright. There is broad, settled consensus on this — these are not judgment calls.
• Set your floor at the current strong versions. Offer only the modern protocol versions still considered strong, and prefer the newest your clients can support. Newer versions dropped weak options and simplified the handshake precisely to remove foot-guns.
• Let "strong" be defined by maintained sources, not memory. Because the boundary moves, take the current line from your platform's hardening guidance and recognized configuration references rather than a number you memorized. The habit of setting a floor is permanent; the exact floor is a lookup.

Getting the floor right also quietly fixes downgrade exposure: an attacker who cannot force the connection down to a weak protocol version has lost their most reliable lever. We will return to closing downgrade paths after the cipher families.

Decision Two: Think in Cipher Families

You do not need to evaluate individual suites — you need to sort them into three buckets and act on the buckets. Forget the exact names; learn the categories, because the categories are stable even as membership changes.

Two properties reliably separate the buckets, and both stay meaningful over time:

• Forward secrecy is the dividing line. Prefer ephemeral key exchange everywhere. A suite without it means a future key theft can retroactively unlock today's recorded traffic — an unnecessary risk when forward-secret options are universally available.
• Authenticated encryption is the modern baseline. Prefer suites that combine encryption and integrity in one vetted mode. Older constructions that bolt integrity on separately have produced a long history of subtle, exploitable bugs.

Ordering matters as much as membership. Most servers let you express a preference order, and a good policy puts the modern family at the top so that when a capable client connects, the strongest mutually supported option wins automatically. The compatibility-tier options then sit lower down as a fallback that only older clients ever reach. Think of it as a menu that lists your best dish first: everyone who can eat it does, and the plainer options exist only for the guests who need them. On some platforms the server's preference is even honored over the client's, which is worth turning on so that you decide the fallback ladder rather than the client.

The same family thinking applies to SSH, which has its own negotiated lists for key exchange, ciphers, and integrity codes: prefer the modern families, keep sound compatibility options only where a client needs them, and disable the legacy ones. The tool differs; the sorting is identical. And because SSH endpoints are often left at their software defaults for years, they are exactly the place where a forgotten legacy algorithm quietly lingers — worth a look the next time you touch an SFTP server.

Decision Three: Start From a Safe Default, Then Narrow

You are almost never building a cipher list from an empty box, and you should not try to. The sane workflow:

1. Adopt a reputable baseline. Start from a well-regarded hardening profile — your platform vendor's guidance or a recognized configuration reference. These are maintained by people who track the field, which is exactly the work you are trying not to do yourself.
2. Choose a strictness level honestly. Good baselines come in tiers — a stricter "modern" profile for endpoints whose clients you control, and a more permissive "intermediate" profile where you must serve a broad, older client base. Pick the strictest tier your real clients tolerate, not the strictest tier that exists.
3. Narrow deliberately. Remove anything the baseline leaves enabled that you can prove no client needs. Every option you remove is one fewer thing to worry about — but remove based on evidence from your logs, not guesswork, so you do not lock out a partner you forgot about.
4. Write down the "why." Record which profile you started from and every deliberate deviation. Two years on, that note is the difference between confident maintenance and fear of touching a working config.

This is also where good server software earns its keep: it should ship with sane, current defaults and expose protocol versions and cipher policy as clear settings rather than requiring hand-edited strings. A server such as Sysax Multi Server presents its FTPS, SFTP, and HTTPS encryption options in configuration rather than raw suite lists, which makes "disable the retired versions, prefer modern families" a set of choices you can actually see and audit. The FTPS-specific angle — floors, downgrade paths, and reuse pitfalls together — is covered hands-on in hardening FTPS.

Close Every Downgrade Path

A cipher policy has a loophole that catches people: it does not matter how strong your preferred options are if an attacker can force the connection onto a weak one you left enabled. A downgrade attack is exactly that — a man-in-the-middle interferes with the negotiation so both sides settle on the weakest mutually supported option, then attacks that. The defense is not clever; it is subtraction.

• The weak option you disabled cannot be negotiated. This is the whole reason "refuse" lists matter as much as "offer" lists. If it is not enabled, it cannot be downgraded to.
• Raise the version floor. Removing old protocol versions removes the era where downgrade tricks were easiest.
• Watch the FTPS two-channel trap. FTPS can be configured to protect the login but not the file data. That is a downgrade you configured yourself — see how TLS wraps FTP and require data-channel protection.
• Close the cleartext fallback. A server still accepting a plaintext protocol alongside its encrypted one is the ultimate downgrade — all the way to zero. Finding and closing those is our cleartext discovery article.

Test What the Endpoint Actually Negotiates

Configuration says what you intended; a client that connects and inspects the result tells you what actually happens. Never trust the config file alone — verify from the outside, the way a real client experiences the endpoint. This procedure is protocol- and tool-neutral on purpose; drop your platform's specific commands into each step:

ENDPOINT CIPHER-POLICY TEST  (run against an endpoint you administer)

1. CONFIRM THE VERSION FLOOR
   - Attempt a connection forcing an OLD protocol version.
     Expected: REFUSED. If it connects, your floor is not set.
   - Attempt with a current strong version.
     Expected: SUCCEEDS.

2. ENUMERATE WHAT IS OFFERED
   - Use a TLS/SSH scanning tool, or connect while requesting a
     verbose report of the negotiated version and cipher.
   - Record every protocol version and cipher family the endpoint
     will accept -- not just the one it prefers.

3. CHECK FOR RETIRED / WEAK OPTIONS
   - Cross off anything in the "retired/weak" family from the results.
     Expected: none present. Any hit is a fix item.

4. CONFIRM FORWARD SECRECY
   - Verify the preferred negotiated suite uses ephemeral key exchange.
     Expected: yes.

5. CHECK ALL CHANNELS (FTPS especially)
   - Confirm the DATA channel is protected, not just the control channel.
     (Capture a test transfer if unsure -- see the cleartext-discovery method.)

6. VERIFY IDENTITY PLUMBING
   - Certificate chain complete and name matching? (TLS)
   - Host key the published fingerprint? (SSH)

7. RECORD AND SCHEDULE
   - Save the result as your baseline. Re-run after any change,
     and on a schedule -- "strong" drifts as the field advances.

Steps 1 through 3 are the core: prove the floor holds, list everything offered, and confirm nothing from the retired bucket survived. This external check is the same instinct as verifying a server certificate the way a client would, and it belongs in your hardening-verification routine — see hardening transfer servers for where it fits the larger loop.

When to Deviate — and How to Do It Responsibly

Real environments have real constraints, and rigid maximalism sometimes breaks the business. The honest position is not "strictest always" but "strong by default, deviate with your eyes open and a paper trail." Legitimate reasons to relax a setting:

• A partner or client that cannot meet your preferred floor. An older but still-supported system may only speak a compatibility-tier option. Enabling that one option for that one relationship can be the pragmatic call — while you push them to upgrade.
• Embedded devices and appliances. Industrial and legacy equipment often lags badly on protocol support and cannot be patched on your timeline.
• A defined transition window. During a migration you may temporarily accept a weaker option so nothing goes dark mid-cutover.

What separates a responsible deviation from quiet decay is the discipline around it:

1. Deviate narrowly. Enable the weaker option for the specific endpoint or client that needs it, never globally. One partner's constraint should not lower the bar for everyone.
2. Contain it. Pair the exception with compensating controls — network isolation, IP allowlisting, tighter monitoring — so the weaker cipher lives behind other defenses.
3. Document it. Write down what you weakened, for whom, why, and what would let you undo it. Undocumented exceptions are how a "temporary" compatibility option outlives everyone who understood it.
4. Set an expiry. Attach a review date. The point of a deviation is to be revisited, not to become permanent by neglect.

This mirrors the judgment in when plain FTP is acceptable: security maturity is not refusing every exception, it is granting them deliberately, containing them, and remembering they exist.

The Version to Tell a Colleague

You can set a sound cipher policy without understanding the cryptography, because the job is curation, not invention. Make three decisions and one habit. First, set the protocol-version floor — refuse the retired versions, offer only current strong ones — which is the highest-leverage and most durable choice you will make. Second, think in families rather than names: prefer forward-secret key exchange and authenticated encryption, keep compatibility options only where a real client needs them, and disable the weak family entirely. Third, start from a reputable, maintained baseline and narrow it with evidence from your logs. The habit that ties it together: test the endpoint from the outside to see what it truly negotiates, and re-test on a schedule, because "strong" is a moving line. Deviate when the business genuinely requires it — narrowly, contained, documented, with an expiry.

From here, man-in-the-middle attacks and trust failures shows what your cipher policy is ultimately defending against, and the certificate management and SSH key management series cover the identity side of the same endpoints.

Frequently Asked Questions