How do you set a minimum TLS version on a Python ssl.SSLContext, and what does that not guarantee?

## The API An `ssl.SSLContext` exposes `minimum_version` and `maximum_version`, both taking members of the `ssl.TLSVersion` enum: `MINIMUM_SUPPORTED`, `SSLv3`, `TLSv1`, `TLSv1_1`, `TLSv1_2`, `TLSv1_3`, `MAXIMUM_SUPPORTED`. Raising the floor is one assignment: ```python import ssl ctx = ssl.create_default_context() ctx.minimum_version = ssl.TLSVersion.TLSv1_3 ``` They are settable only on a general-purpose context - one created with `ssl.PROTOCOL_TLS_CLIENT` or `ssl.PROTOCOL_TLS_SERVER`, which includes everything `ssl.create_default_context()` returns. On a context pinned to one specific protocol there is nothing to bound and the assignment raises. This pair replaced an older idiom: setting bits such as `ssl.OP_NO_TLSv1_1` in `ssl.SSLContext.options`. Those flags still exist but are deprecated in favour of the version range, and there is a real reason to prefer the range beyond tidiness - an option-flag list enumerates the versions you knew about when you wrote it, so a future protocol version is permitted by omission, whereas `minimum_version` expresses the intent ("nothing older than this") and keeps expressing it. ## What the floor is worth, and what it is not A minimum version is a statement about *protocol mechanics*: it refuses handshakes that would use a version with known weaknesses. Three things it does not do, and all three are asked as follow-ups. **It is not authentication.** A TLS 1.3 connection to an attacker is still a connection to an attacker. Version policy and certificate verification are orthogonal, and the version is the far less important of the two - a verified TLS 1.2 connection is enormously safer than an unverified TLS 1.3 one. **It is not the only floor in play.** The linked OpenSSL build has its own default security level, and many platforms ship a system-wide crypto policy that raises the floor beneath the interpreter. A context that permits TLS 1.0 may still fail to negotiate it, because the library below refused before Python was consulted. The converse also holds: reading a permissive `minimum_version` off a context does not prove old protocols are reachable. Where support genuinely matters, `ssl.HAS_TLSv1_3` reports whether the build offers 1.3 at all, and `ssl.OPENSSL_VERSION` tells you which library you are actually on. **It is not observable from the setting.** What you configured is a bound; what happened is a negotiation. `ssl.SSLSocket.version()` on a connected socket returns the version actually agreed, and that is the value worth logging on a service you operate. ## Raising to TLS 1.3 is a compatibility decision Since 3.10, `ssl.create_default_context()` sets `minimum_version` to `ssl.TLSVersion.TLSv1_2`, so TLS 1.0 and 1.1 are already gone by default - the assignment people actually write is the one that moves the floor to 1.3. That is a policy decision with an operational cost, not a free hardening: any endpoint that has not been upgraded stops working, and it stops working as a handshake failure at connection time rather than as a warning. On a client that talks to a known, controlled set of internal endpoints, raising to 1.3 is reasonable and easy to verify. On a client that talks to arbitrary third parties, it will eventually hit a peer that cannot do 1.3, and the failure will be someone else's server on a Sunday. Decide per client, not globally, and roll it out by first logging `ssl.SSLSocket.version()` from real traffic to see what your peers actually negotiate. ## maximum_version is almost always the wrong knob `maximum_version` exists for interoperability testing and for reproducing a peer's behaviour. Setting it in production code is a mistake in waiting: it caps you below whatever comes next, and the usual motive - "a middlebox chokes on 1.3" - is a request to make your traffic worse in order to keep a broken device happy. If you find one set in a codebase, the question to ask is what it was working around and whether that thing still exists. ## Putting it together A defensible client setup is small: build the context with `ssl.create_default_context()`, leave verification alone because it is already right, raise `minimum_version` only when you own both ends and have checked they can do it, and log the negotiated version so the policy is measured rather than assumed. The floor is worth setting; it is not what makes the connection safe.