Your auditor asks a simple question on a Tuesday morning. She wants evidence that investor records, loan files, and ACH instructions are encrypted in transit, and she wants more than a screenshot of a padlock. That's where TLS 1.3 security stops being an IT detail and becomes a control you can document, test, and defend to a board.
TLS 1.2 and TLS 1.3 Compared at a Glance
On Monday, your Controller signs in to the investor portal from the church office. She sees the same padlock whether the server negotiated TLS 1.2 or TLS 1.3, so the version is invisible to her and easy for everyone to overlook.
Transport Layer Security, or TLS, is the protocol that encrypts traffic between a browser or app and a server. The two sides negotiate a version for each connection, so a server that supports 1.3 may still serve 1.2 to an older client.
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Full handshake round trips | 2 | 1 |
| Static RSA key exchange | Allowed | Removed |
| Forward secrecy | Only with ephemeral cipher suites | Always provided |
| Cipher suite choices | Dozens of combinations, including CBC mode and SHA-1 options | Five suites, all authenticated encryption |
| Certificate visible during handshake | Yes | No, encrypted after ServerHello |
| Downgrade protection | Partial, depends on implementation | Built in through handshake sentinel values |
| 0-RTT early data | Not available | Optional, and replayable without application defenses |
TLS 1.3 was published as RFC 8446 on August 10, 2018, and the RFC 8446 publication record marks a redesign that removed weaker options rather than adding new ones. Static RSA and static Diffie-Hellman key exchanges are gone, symmetric encryption is restricted to authenticated encryption, and handshake messages after the ServerHello are encrypted.
That last point matters for privacy. A passive observer no longer reads the server certificate in clear text, which limits metadata exposure compared with earlier versions.
Your First Action
Pull the protocol versions your portal, APIs, and file transfers negotiate today. A configuration file that says 1.3 is enabled doesn't tell you what a church treasurer's older browser received, and the table only matters once you know what your own endpoints do.
How a TLS 1.3 Connection Gets Established
Think of mixing paint. Both sides publicly agree on a starting color, each privately adds a secret pigment, then they exchange the mixtures. Anyone watching sees the mixtures but can't separate out the secret pigments, yet both sides end with the same final color.
Five Steps You Can Follow
- ClientHello: The client lists the cipher suites it supports and sends its first key share, its public mixture, so the server doesn't have to ask for it later.
- ServerHello: The server picks the parameters and sends its own key share. From this point onward, handshake traffic is encrypted.
- Certificate and proof: The server sends its certificate and a signature proving it holds the matching private key. Both travel encrypted, so passive observers can't read them.
- Key derivation: Both sides derive separate session keys with HKDF, a standard extract and expand method that produces different secrets for different stages and directions.
- Finished: The client confirms the handshake and application data begins to flow.
TLS 1.2 traditionally needed two round trips before data could move, while TLS 1.3 normally needs one round trip, a change Cloudflare's introduction to TLS 1.3 describes as improving latency without removing authentication or encryption. For a church treasurer on a slow rural connection, that's a shorter wait before the dashboard loads.
An encrypted handshake protects more data, but it also means a monitoring tool that once read certificate details in clear text now needs a different method.
One caution belongs here. TLS 1.3 also defines 0-RTT resumption, where a returning client sends some data with its first message. It's faster, but that early data carries a replay risk and doesn't provide full forward secrecy, so it needs its own policy rather than a blanket approval.
Forward Secrecy, Simpler Ciphers and Downgrade Protection
Three changes do most of the work in TLS 1.3. Each one sounds technical, but each maps to a risk a CFO already understands.
Forward Secrecy
Think of a hotel key card programmed fresh for each stay and destroyed at checkout. Stealing the hotel's master key later doesn't reopen past stays.
TLS 1.3 works the same way. It always negotiates ephemeral keys, fresh keys created for one session and then discarded. The TLS 1.3 specification text removes RSA key transport and static Diffie-Hellman, and derives traffic secrets with HKDF from that ephemeral exchange.
Here's the CEF example. If your certificate private key is compromised in 2027, investor portal sessions recorded in 2025 should remain protected because their session keys weren't encrypted under that long term key. TLS 1.2 with static RSA couldn't make that promise.
Simpler Ciphers
TLS 1.3 defines a short list of cipher suites, all using authenticated encryption, and removes CBC mode, SHA-1, and static RSA. Your configuration review covers a short list instead of a long menu where one weak choice can hide. That's a practical benefit during an audit, because there's far less to misconfigure, as discussed in our overview of security in layers.
Downgrade Protection
An attacker between a user and your server might try to force the connection back to an older, weaker version. TLS 1.3 counters this with a marker carried in the server's handshake random value. A compliant client that sees the marker knows the server supports 1.3, so a forced fallback to 1.2 gets detected instead of accepted without notice.
These protections have a clear boundary. They cover data in transit and past recorded sessions, but they don't stop credential theft, malware on a staff laptop, or a flaw in how your portal checks permissions. Enforce TLS 1.3 where supported, keep TLS 1.2 only for documented compatibility, and protect certificate keys under defined rotation procedures.
Known Limits Including the 0-RTT Replay Risk
Faster isn't always safer. 0-RTT lets a returning browser send data in its first message, but that early data can be copied and sent again, much like a signed check that's photocopied and cashed twice.
TLS 1.3 doesn't stop replay of early data by itself, so your application has to. NIST guidance on TLS risk and compliance identifies replay as the central 0-RTT risk, while ordinary data sent after a completed handshake doesn't have this property.
Policy by Operation
| Operation | 0-RTT acceptable? | Reason |
|---|---|---|
| Dashboard refresh (read-only) | Yes, after review | Repeated reads do not change balances |
| Investor statement PDF download | Yes, after review | Repeating the request returns the same file |
| ACH creation | No | A replayed request can create a second debit |
| Payment posting | No | A replay can post the same payment twice |
| Investor note change (rate, renewal, redemption) | No | A replay can alter a note twice |
| Loan disbursement or approval | No | A replay can release funds or repeat an approval |
| Login or password change | No | Replayed submissions can trigger lockouts or repeated changes |
Practical rule: Require a completed handshake before any state changing request, and log every rejected early data attempt.
Where you do allow 0-RTT, require request identifiers, server side deduplication, narrow replay windows, and audit logging. Idempotent means repeating the request produces the same result as sending it once, and that's the test every candidate operation must pass.
Limits That Remain
- Transit only: TLS protects data moving across a network, not a compromised endpoint or a stolen password.
- Authorization still matters: If the application lets a signed in user view another investor's records, encryption faithfully delivers the wrong records.
- Legacy clients persist: Older devices and partner systems may stay on TLS 1.2 for years, so you need named exceptions, not silent fallback.
- Less passive visibility: The encrypted handshake reduces what conventional monitoring can see.
Confirm the 0-RTT setting on each state changing endpoint before any migration work begins. That's a one page finding you can close this quarter.
Recommended Settings for Financial and Regulated Environments
Auditors don't ask whether you meant well. They ask what your written standard says, who owns it, and whether your servers match it. The table below is a starting point you can adapt and record with a named owner and an annual review date.
| Setting | Recommended value | Documented boundary |
|---|---|---|
| Minimum protocol version | TLS 1.3 preferred, TLS 1.2 as the floor | TLS 1.1 and older disabled |
| TLS 1.3 cipher suites | AES-GCM and ChaCha20-Poly1305 suites | CCM variants only where a named device requires them |
| TLS 1.2 fallback suites | ECDHE key exchange with AES-GCM or ChaCha20-Poly1305 | No CBC mode, static RSA or SHA-1 |
| Certificate key type | ECDSA P-256 or RSA 2048-bit at minimum | Smaller keys not permitted |
| Certificate lifetime | Short terms with automated renewal, within the maximum allowed for publicly trusted certificates | Automated renewal wherever the platform supports it |
| Private key storage | Hardware security module or cloud key management service | Keys never exported to shared drives or email |
| HSTS header | max-age of at least one year | includeSubDomains and preload only after subdomain inventory |
| Session ticket lifetime | Hours, not days, with ticket keys rotated at least daily | Value written into the security standard |
How a Reviewer Reads This Table
Version floor first. Name the clients that still need TLS 1.2, give each exception an owner and an expiry date, and disable everything older. An exception without an expiry date becomes a permanent weakness.
Cipher suites next. For 1.3, you're choosing among authenticated encryption suites. For 1.2 fallback, ECDHE gives you ephemeral key exchange, and you should exclude CBC mode, static RSA, and SHA-1 explicitly so a future change doesn't reintroduce them.
Certificates and keys. A hardware security module, or HSM, is a dedicated device or cloud service that holds private keys so they never sit as files on a server. Log every access. Short certificate lifetimes with automated renewal reduce the chance an expired certificate stops a payment file on a Monday morning.
HSTS tells browsers to use HTTPS only, so a user who types a plain address gets upgraded automatically. Don't add preload until you've inventoried subdomains, because preload is hard to undo.
You'll notice 0-RTT isn't in this table. Its policy is set by operation, not by server, so it belongs in your application standard rather than your TLS baseline.
Testing Tools and Monitoring After Migration
A passing grade from one scanner is a point in time snapshot. It isn't evidence that every endpoint, including the batch file server nobody remembers, is configured correctly.
| Tool | What it checks | Best used for |
|---|---|---|
| Qualys SSL Labs Server Test | Protocol versions, cipher order, certificate chain, letter grade | External review of public endpoints |
| testssl.sh | Protocols, cipher suites, certificate details, known vulnerabilities | Scripted audits of hosts you control |
| OpenSSL s_client | Whether a specific server completes a TLS 1.3 handshake | Spot checks during change windows |
| Nmap ssl-enum-ciphers script | Cipher suites offered on each open TLS port | Internal inventory sweeps |
| Browser developer tools | Negotiated version and cipher for a live session | Confirming what staff and users actually receive |
A Manual Spot Check
- Force TLS 1.3: Run an OpenSSL s_client handshake against each public hostname.
- Read the result: Confirm the negotiated version and cipher suite in the output.
- Check from outside: Repeat from outside your network so you see what investors receive.
If a check returns TLS 1.2 only, confirm the server software and its TLS library support 1.3, then look for a configuration line capping the maximum version at 1.2. Rerun after the service restarts, and put any endpoint still failing into your exceptions register.
Monitoring needs the same discipline. NIST's TLS visibility introduction explains that the encrypted handshake means some older network observation techniques no longer work, and that key access for inspection must be governed carefully. Give any decryption capability a named owner, a documented purpose, and preserved audit records.
Set alerts for connections falling back to older versions, rescan after every certificate renewal and configuration change, and keep the reports as audit evidence. Our guidance on ongoing security monitoring covers how to turn those reports into a one page summary for your board audit committee, showing endpoints in scope and open exceptions.
Post-Quantum Readiness as a Planning Question
A loan file may need to remain confidential for years. If an attacker records its encrypted traffic today, future advances in quantum computing could put some current key exchange methods at risk. Harvest now, decrypt later describes that threat. For a church extension fund, readiness means knowing which information needs long-term protection and documenting who will review the controls.
Build cryptographic agility into that review: the ability to replace cryptographic algorithms without rebuilding systems. The NCSC recommends hybrid configurations that combine classical and post-quantum methods. Its post-quantum updates to TLS guidance discusses hybrid key exchange for TLS 1.3. Earlier TLS versions do not have the same standardized support for this approach, so confirm protocol and library compatibility before setting a migration policy.
The guidance sets 2031 as a high-priority milestone for organizations to migrate systems that protect information requiring long-term confidentiality. Treat that date as a planning point, not proof that a particular endpoint is ready. Record the systems in scope, the owner responsible for each review, and the evidence supporting decisions.
Testing hybrid configurations can reveal practical obstacles. Larger handshake messages may expose limits in libraries, older clients, or proxies; disaster recovery environments also need compatible configurations. Start by identifying TLS termination points, APIs, batch integrations, vendor connections, and archives containing long-retention data. A passing scan shows what an endpoint supports now, not whether the migration is safe or adequately documented. Keep test results and exceptions with the review record.
Plan Your TLS 1.3 Migration and Audit Evidence
Finance and IT can run this together. Finance owns the risk decisions and evidence, IT owns the configuration, and each endpoint gets one named owner from each side.
Migration Checklist
- Inventory every endpoint: Include portals, APIs, batch file transfers, vendor connections, and mobile apps.
- Record current state: Note the versions and cipher suites each endpoint negotiates today.
- Enable TLS 1.3: Set TLS 1.2 as the floor and open an exceptions register with each client, owner, and expiry date.
- Disable 0-RTT on state changing endpoints: Confirm the setting individually, not just globally.
- Test before cutover: Check older partner systems, batch jobs, and disaster recovery sites in staging.
- Update monitoring: Revise log retention and inspection procedures for the encrypted handshake.
- Schedule a post-quantum review: Tie it to the 2031 milestone discussed above.
Evidence to Retain
Keep the written security standard, scan reports before and after the change, change tickets with approvals, the exceptions register, and sample monitoring alerts. Add board minutes showing review, because they demonstrate oversight, not just activity. Our summary of audit trail requirements explains how those records fit together for an examiner.
Ask every platform vendor, including CEFCore, which of these controls it documents and where you can review the evidence. TLS 1.3 is one control among several, but it's one your auditor can verify in minutes when the paperwork matches the servers.
CEFCore centralizes loans, investor notes, general ledger, and ACH operations for church extension funds, with encrypted connections and documented controls your audit committee can review. If you're preparing evidence for your next examination, visit CEFCore to see how a purpose built platform supports that work.
