Deadline: October 31, 2027. Connections using deprecated cipher suites will stop working after this date.
The basics
What is changing and why?
Sentry is removing five TLS cipher suites that use RSA key exchange. RSA key exchange lacks forward secrecy: if the server's private key is ever exposed, previously recorded traffic can be decrypted. Sentry will require forward-secret cipher suites going forward.
After October 31, 2027, Sentry will only accept connections using forward-secret cipher suites. This is the same direction the broader industry has been moving for years.
Which cipher suites are being removed?
Cipher suite name | OpenSSL name | Hex ID |
TLS_RSA_WITH_3DES_EDE_CBC_SHA | DES-CBC3-SHA | 0x0a |
TLS_RSA_WITH_AES_128_CBC_SHA | AES128-SHA | 0x2f |
TLS_RSA_WITH_AES_128_GCM_SHA256 | AES128-GCM-SHA256 | 0x9c |
TLS_RSA_WITH_AES_256_CBC_SHA | AES256-SHA | 0x35 |
TLS_RSA_WITH_AES_256_GCM_SHA384 | AES256-GCM-SHA384 | 0x9d |
When does this take effect?
Support for these cipher suites ends on October 31, 2027. Connections using them will fail after this date.
Am I affected?
Do I need to do anything?
If you're running a recent version of the Sentry SDK or any modern HTTP client, you’ll be using stronger cipher by default and won’t be impacted.
You may need to act if you're running any of the following:
Legacy infrastructure with restricted TLS configurations
Heavily locked-down network environments that pin specific cipher suites
Older HTTP clients, IoT devices, or custom TLS stacks that haven't been updated in several years
Self-hosted tooling that explicitly allowlists these RSA key exchange cipher suites suite
How do I check if I'm using one of these cipher suites?
This is very dependent on your deployment. If you have client-level access, you can test the cipher your client negotiates with Sentry using OpenSSL from the command line below. Please note this only tests your deployment’s OpenSSL capabilities. If you’re using a pinned language-specific runtime or a unique IoT device implementation you should verify it separately.
<aside>
openssl s_client -connect [sentry.io:443](<http://sentry.io:443/>) -tls1_3 </dev/null 2>/dev/null \ | grep -E "Protocol\s*:|Cipher\s*:"
</aside>
If the output matches any of the cipher names in the table above, you'll need to update your configuration.
What to do if you're affected
What should I upgrade to?
If you're configuring this at the OS or library level, enabling TLS 1.3 is the simplest long-term fix.
Any TLS 1.2 cipher suite using ECDHE or DHE key exchange will work, as will any TLS 1.3 cipher suite. Common modern alternatives include:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256Any TLS 1.3 cipher (all TLS 1.3 suites provide forward secrecy by default)
What happens if I don't update by the deadline?
Sentry will refuse connections that attempt to negotiate one of the deprecated cipher suites. SDK data ingestion, API calls, and any other Sentry connectivity from affected systems will stop working until the TLS configuration is updated.
Why are RSA key exchange cipher suites being removed if AES-256 is still considered strong?
The AES encryption itself is fine, the problem is the key exchange step that precedes it. RSA key exchange encrypts the session key with the server's long-term RSA private key. If that private key is ever compromised (now or in the future), an attacker who recorded past traffic can decrypt all of it retroactively.
Modern cipher suites use ephemeral key exchange (ECDHE/DHE), which generates a fresh key per session that is never stored. Even if the server's private key leaks later, past sessions remain unreadable. This property is called forward secrecy.
Where can I see what is supported?
Sentry's supported SSL Protocols and cipher can be found here: https://docs.sentry.io/security-legal-pii/security/ssl