How do you retire TLS 1.0 and 1.1 without abruptly cutting off paying legacy clients?
TLS 1.0 (RFC 2246) and 1.1 (RFC 4346) were formally deprecated by RFC 8996 in 2021 for known weaknesses. Disabling them is correct but blindly flipping the switch causes support tickets. Staged retirement playbook.
— Measure first: enable TLS version logging at the edge and quantify what fraction of real traffic still negotiates 1.0/1.1, segmented by client and endpoint (APIs differ from browsers).
— Identify the laggards by user agent and IP, often embedded devices, old payment terminals, or a single B2B partner's server.
— Communicate a cutoff date to affected integrations before enforcing it; for partner APIs this is contractual, not technical.
— Disable in stages: drop 1.0 first, observe error rates for a week, then 1.1, keeping rollback one config reload away.
— Re-scan with testssl.sh to confirm only TLS 1.2 and 1.3 are offered and no fallback path remains.
Evidence vs. speculation: edge logs are ground truth; assumptions about 'no one uses old TLS' routinely cost an enterprise integration.
Further reading: RFC 8996 (deprecation); RFC 7507 (fallback SCSV).
Bottom line: measure the long tail by client, give integrations a deadline, then retire in observable stages.
Handshake Papers
@HandshakePapers
How do you retire TLS 1.0 and 1.1 without abruptly cutting off paying legacy clients?
Этот пост опубликован в Telegram-канале Handshake Papers. Подписаться можно по ссылке: @HandshakePapers.