Improve clarity of TLS version requirements in V9.1.3

[sujalavnelavai]

I’ve been reviewing the V9 Communication Security section and noticed that requirement 9.1.3 still uses wording like “latest recommended versions” and lists both TLS 1.2 and TLS 1.3 as examples. This phrasing feels a bit outdated and can be interpreted in different ways depending on the assessor or the organisation.

Right now, the requirement doesn’t clearly state:

that TLS 1.3 should be the preferred protocol

when TLS 1.2 is still acceptable

that older versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1) must be disabled

that TLS 1.2 should only be used with AEAD cipher suites

that TLS 1.3 cipher suites are fixed and don’t require manual selection

To make the requirement more actionable and aligned with current guidance (including the OWASP TLS Cheat Sheet), I’d like to propose updated wording.

Proposed update for 9.1.3
Verify that TLS 1.3 is enabled and preferred for all client communications. TLS 1.2 is permitted only when TLS 1.3 is not supported, and must be configured with AEAD cipher suites and secure renegotiation. Older protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1) must be disabled.

This keeps the requirement simple but much clearer, and it reflects the current state of TLS without being overly prescriptive.

Happy to adjust the wording based on feedback.

[narfbg]

Looks like you're referring to 9.1.3 in ASVS version 4, not the latest version 5. See https://github.com/OWASP/ASVS/blob/master/5.0/en/0x21-V12-Secure-Communication.md#v121-general-tls-security-guidance

[randomstuff]

Looks like you're referring to 9.1.3 in ASVS version 4, not the latest version 5.

Yes.

That being said, I agree that TLS 1.2 should be explicitly stated as "for legacy/compatibility only".

The way the document is organized wrt cryptographic standards (which tend to change quite a bit) is that the requirements do not prescribe the exact mechanisms but they are detailed in the appendix (C).

In my opinion, what is missing is a section in appendix C about TLS standards:

• TLS 1.3 → allowed
• TLS 1.2 → legacy
• TLS 1.0 and below → disallowed
• ditto for DTLS (used in WebRTC for example)

If this is incorporated, the wording of 12.1.1 could be updated.

[randomstuff]

See #979

[narfbg]

Agreed. I've personally seen household name service providers put things like "all communication is encrypted using TLS 1.2" in their presentation slides, and it's because subtly ambiguous wording like the current 12.1.1 allows for contrived interpretations. Would love to have it more explicit.

[sujalavnelavai]

Thanks for pointing that out — that helps.
I’ll switch over to ASVS v5 and review the TLS guidance in Appendix C, since that seems to be the right place to define which protocol versions are allowed, legacy, or disallowed.

After I go through Appendix C and Issue #979, I can put together some updated wording that:

makes TLS 1.3 the preferred option

treats TLS 1.2 as legacy/compatibility only

clearly disallows SSLv2, SSLv3, TLS 1.0, and TLS 1.1

stays aligned with the OWASP ASVS

I’ll share a draft here before opening a PR.

[sujalavnelavai]

Hi everyone, I’d like to work on a PR for ASVS v5 to update the TLS wording and align it with Appendix C.
Before I start drafting the changes, could you confirm that this is the direction you’d prefer?

[elarlang]

Hi there

Before I start drafting the changes, could you confirm that this is the direction you’d prefer?

We use "agreement on the issue first, then PR" logic, so before going to PR, there must be a clear agreement here on what and why we are going to change. I would like to see that at least @randomstuff agrees with the proposals as a starter.

If we are PR-ready, then it makes sense to confirm with @tghosth what the latest procedure is for updates into bleeding edge.

It is also a bit tricky place - requirements point to Appendix C, which methods/versions are allowed. If we change Appendix C, then it feels like it is a non-breaking change - in reality, if a requirement is pointing to a list of allowed/disallowed versions, then it may cause a breaking change at the end.

[randomstuff]

I would tend to avoid explicitly mentioning the TLS versions in the requirements but only include them as part of the appendix. Allow/deny-list of cryptographic mechanisms are in the appendix and it makes sense to include the TLS versions here as well.

Why is this currently done like this and would it be a good idea to do the same for TLS versions?

• These things tend to change once in a while (when weakness are found in existing mechanisms, when new mechanisms are adopted).
• Changing the appendix is not considered a breaking change.
• A user of the ASVS can fork the ASVS and just patch the crypto appendix in order to define the list of acceptable cryptographic mechanisms (including TLS versions) for its project/organization.

So I think a requirements which says "only use non-deprecated versions of TLS" is OK and the definition of "non-deprecated" would better be relegated to the appendix.

---

Now, if we compare to your initial wording:

Verify that TLS 1.3 is enabled and preferred for all client communications. TLS 1.2 is permitted only when TLS 1.3 is not supported, and must be configured with AEAD cipher suites and secure renegotiation. Older protocol versions (SSLv2, SSLv3, TLS 1.0, TLS 1.1) must be disabled.

If we do what I am proposing, the only thing missing (when compared to your proposition) would be requirement about "secure renegotiation". In my proposition, I am not certain what should be done about this part:

• Skip it?
• Add a new requirement?

The prevalence of this is issue must be very low. Unless you are running a very old broken implementation or you have explicitly enable some dangerous setting, you should be fine.

[sujalavnelavai]

Thank you both for the detailed feedback — this direction makes sense.

I agree that the requirement itself should avoid hard‑coding TLS versions and instead reference “non‑deprecated TLS versions,” with the actual allow/deny list defined in Appendix C. That keeps the requirement stable while allowing the appendix to evolve without causing breaking changes.

Regarding secure renegotiation, I see two options:

Skip it if the prevalence of insecure renegotiation is now extremely low in modern implementations

Add a small, separate requirement in Appendix C noting that TLS 1.2 configurations must support secure renegotiation

I’m happy to follow whichever approach the maintainers prefer.
Once we have agreement, I can help draft the updated wording.

[cmlh]

Putting the argument that the purpose of a "... Verification Standard" is to audit technical control[s], if our intent is to avoid verifying a specific TLS minor release then 5.0 Requirement 12.1.1 should be struck out due to 5.0 Requirement 12.1.2.

I'd defer to @ivanr for published "real life" examples of when TLS 1.2 is the only option as TLS 1.3 is not supported by "legacy" web browsers or "legacy" forks of OpenSSL 1.1.1 within 5.0 Appendix C.

[sujalavnelavai]

Thank you all for the detailed insights. I’ll follow the discussion and help where needed.

[cmlh]

Can @sujalavnelavai please append any updates to GitHub Issue #979 when preparing the PR? Specifically:

• More recent TLS 1.3 uptake studies since the SANS and F5 bodies of work published during 2021, such as https://www.sans.org/blog/legacy-handshake-understanding-tls-prevalence-operational-risks for example?
• Any new visibility controls that have to be implemented (and therefore verified) when implementing TLS 1.3?
• A brief mention of how TLS 1.3 futureproofs Quantum cryptography and therefore reduces technical debt of legacy cryptosystems?
• A table referencing how other standards have mandated TLS 1.3?

[randomstuff]

Any new visibility controls that have to be implemented (and therefore verified) when implementing TLS 1.3?

I don't believe that "visibility" in encrypted flows should be a requirement in ASVS. In practice, this is implemented in dubious ways and adds several risks. I understand that it is a trade off people are willing to make (or may be mandated to make) but I don't believe it should be in ASVS requirement.

---

A brief mention of how TLS 1.3 futureproofs Quantum cryptography and therefore reduces technical debt of legacy cryptosystems?

It is really just than nobody is willing to retrofit PQC support in a deprecated version of TLS.

[tghosth]

Thanks all, and thanks @sujalavnelavai for raising this.

What we decided in #2992

We looked at this same wording in #2992 last year. @randomstuff suggested saying "approved" instead of "latest recommended" and listing approved TLS versions in the appendix. We changed 12.1.2 and left 12.1.1 alone (#3032). My reasoning was that "approved" works in V11 because the appendix lists approved ciphers there, while V12 had nothing in the appendix to point at, so we relied on the TLS Cheat Sheet.

@randomstuff, your proposal here answers that objection — you're offering to add the missing appendix content. That's fair. I'd still rather do it as its own piece of work, since it affects how V12 refers to the appendix generally.

The narrower question: must TLS 1.3 be supported?

This is separate from whether TLS 1.2 should still be allowed. That one belongs in #979, and the answer there hasn't changed — no major standards body has deprecated TLS 1.2, so we shouldn't either.

Current text:

12.1.1 (L1) Verify that only the latest recommended versions of the TLS protocol are enabled, such as TLS 1.2 and TLS 1.3. The latest version of the TLS protocol must be the preferred option.

An application supporting only TLS 1.2 passes both halves. TLS 1.2 is one of the versions listed, and it's the latest version it has switched on. The requirement says which versions you may enable, never that you have to enable any. That's what @narfbg is describing when they see vendors advertise TLS 1.2 support as a security feature.

It also sits oddly with the cheat sheet we chose to rely on in #2992, which already says:

Web applications must default to TLS 1.3 and may support TLS 1.2 for compatibility.

Suggested wording

12.1.1 (L1) Verify that only the latest recommended versions of the TLS protocol are enabled (TLS 1.2 and TLS 1.3), and that TLS 1.3 is enabled and preferred.

This requires TLS 1.3 to be on, still allows TLS 1.2, and makes clear TLS 1.0 and 1.1 are not allowed — without needing anything new in the appendix. It also brings us in line with the cheat sheet. NIST SP 800-52r2 has required US federal agencies to support TLS 1.3 since January 2024, so we wouldn't be ahead of anyone here either.

Tracking this as a breaking change

Applications supporting only TLS 1.2 pass today and would start failing, so this needs to be tracked as a breaking change. It doesn't add, remove or renumber any requirement though, so I'd expect a minor version rather than a major one.

Next step

What I'd like is agreement in this issue on the approach: scoping this to whether TLS 1.3 must be supported, keeping the TLS 1.2 question in #979, and handling the appendix work separately. @randomstuff and @elarlang, does that work for you?