TLS 1.3 vs TLS 1.2 for Security+: What SY0-701 Tests

Security+ objective 3.2 lists TLS as one of the secure protocols you need to know, and the exam doesn't stop at "TLS encrypts traffic." It expects you to explain why TLS 1.3 replaced TLS 1.2. That means knowing three specific things: the handshake got shorter, forward secrecy stopped being optional, and a downgrade-attack loophole got closed at the protocol level. This lives in Domain 3 (Security Architecture), which carries 18% of the SY0-701 exam.

Most study guides say "TLS 1.3 is newer and more secure" and leave it there. That's not enough for a scenario question. So let's go through what actually changed between the two versions, why CompTIA cares, and how each change shows up as an exam scenario. Want to test what you already know? Try the free SY0-701 practice exam first — no signup needed.

Independent study resource. Not affiliated with or endorsed by CompTIA. Exam codes, objectives, and weightings are set by CompTIA — always confirm current details on official exam pages before booking.

Where Objective 3.2 Sits in the SY0-701 Exam

SY0-701 spreads its content across five domains. Domain 3, Security Architecture, is worth 18% — behind only Security Operations (28%) and Threats/Vulnerabilities (22%).

Domain	Weight	Key Topics
1. General Security Concepts	12%	Controls, cryptography basics, authentication types
2. Threats, Vulnerabilities & Mitigations	22%	Malware, social engineering, attack vectors, cryptographic attacks
3. Security Architecture	18%	Network security, cloud, infrastructure, secure protocols
4. Security Operations	28%	Incident response, digital forensics, identity
5. Security Program Management	20%	Governance, risk, compliance, data privacy

Domain weights are per CompTIA's official SY0-701 exam page. The exam runs up to 90 questions in 90 minutes with a passing score of 750 on a 100–900 scale.

Objective 3.2 ("Compare and contrast networking appliances and secure protocols") groups TLS with SSH, SFTP, S/MIME, and a handful of others. TLS gets the most exam attention of the bunch, partly because it's the protocol behind HTTPS and partly because the 1.2-to-1.3 jump gives CompTIA a clean "old way vs. new way" comparison to test.

TLS 1.3 vs TLS 1.2: The Handshake — Two Round Trips vs. One

Here's the plumbing difference that everything else builds on. A TLS 1.2 handshake takes two round trips between client and server before either side sends encrypted application data — negotiate the cipher suite, exchange key material, verify certificates, then finally start encrypting. TLS 1.3 (RFC 8446, published August 2018) collapses that to one round trip. The client guesses which key-exchange group the server will pick and sends its key share up front. The server replies with everything needed to finish. That cuts a real, measurable chunk of connection setup time — something that matters at the scale of a CDN or a mobile network with high latency.

TLS 1.3 also added an optional 0-RTT mode for resumed connections, where a returning client can send encrypted application data in its very first message. That's a genuine speed win, but it comes with a catch the exam likes to test. 0-RTT data can be replayed by an attacker who captures it, because there's no live handshake to prevent a resend. That's why 0-RTT should never carry a request that changes state — a password reset or a funds transfer — unless the application itself has its own replay protection.

On a real load balancer or CDN config, you'll see this show up as a toggle: "Enable TLS 1.3 0-RTT" sitting right next to a warning about replay risk. That's the exact tradeoff objective 3.2 wants you to reason through, not just recite.

Forward Secrecy Stopped Being Optional

TLS 1.2 let a server negotiate RSA key exchange, where the client encrypts a shared secret using the server's long-term public key. That works, but it has a permanent weakness. If an attacker ever gets the server's private key — through a breach, a misconfiguration, or years later through better cracking hardware — they can decrypt every session ever recorded with that key. No forward secrecy.

TLS 1.3 removes static RSA and static Diffie-Hellman key exchange entirely. Every single TLS 1.3 connection uses ephemeral (elliptic-curve) Diffie-Hellman, which generates a fresh, temporary key pair for that one session and discards it afterward. Steal the server's certificate private key today, and you still can't touch traffic captured last year. This is forward secrecy, and in TLS 1.3 it's not a configuration choice — it's the only option on the table.

This connects directly to a related objective: if you've studied SY0-701's cryptographic attacks (objective 2.4), you already know downgrade attacks like POODLE and FREAK worked by tricking a connection into using weaker, non-forward-secret key exchange. Mandatory forward secrecy in TLS 1.3 closes off that entire attack category by design, not by patch.

Cipher Suites: From Dozens Down to Five

TLS 1.2 cipher suite lists were long, and that length was the problem. A typical TLS 1.2 server config supported RC4, DES, 3DES, and CBC-mode AES paired with SHA-1 or MD5 for integrity, alongside a handful of secure combinations. Every insecure entry left on that list was one misconfiguration away from being negotiated by an attacker running a downgrade attack.

TLS 1.3 throws out that entire model. It ships with exactly five cipher suites, and all five are AEAD (Authenticated Encryption with Associated Data) — meaning encryption and integrity checking happen together instead of as separate, independently-breakable steps:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Notice what's missing: no RC4, no DES or 3DES, no CBC-mode ciphers, no MD5 or SHA-1 anywhere in that list. TLS 1.3 didn't deprecate those algorithms through a best-practices recommendation — it made them structurally impossible to negotiate. Want to practice spotting which cipher suites belong to which TLS version? Run through a scenario set on the free SY0-701 practice exam.

Closing the Downgrade Loophole

TLS 1.2 had no reliable way to detect if an attacker had quietly forced a "negotiate down to something weaker" handshake. That's exactly how POODLE, FREAK, and Logjam worked — tricking a client and server into agreeing on an older, breakable protocol version or cipher, even when both actually supported something stronger.

TLS 1.3 fixes this at the protocol level. When a TLS 1.3-capable server has to respond to a client that only offers TLS 1.2 or earlier, it embeds a specific sentinel value in the last eight bytes of the ServerHello.random field. A TLS 1.3-aware client checks for that value; if it's present but the negotiated version doesn't match what it expects, the client knows a downgrade was forced and aborts the connection. It's a built-in tripwire, not a policy telling admins to "just disable old versions" and hope everyone complies.

What This Looks Like in a Real Config Review

A junior security analyst doing a routine web server audit checks a few things that map directly to everything above:

• Protocol versions enabled: TLS 1.0 and 1.1 should be off entirely — both were formally deprecated by RFC 8996 (IETF, March 2021) and are unsupported by major browsers. TLS 1.2 with a restricted, modern cipher list is the acceptable floor; TLS 1.3 should be enabled wherever the stack supports it.
• Cipher suite order: on a TLS 1.2 server, confirm forward-secret suites (ECDHE-based) are prioritized over static RSA key exchange, and that RC4/3DES/export-grade ciphers are removed entirely, not just deprioritized.
• 0-RTT usage: if TLS 1.3 0-RTT is enabled, confirm it's not exposed on any endpoint that changes account state.
• Certificate signature algorithm: SHA-1 signed certificates should be gone — this ties back to the collision-attack weakness of SHA-1 covered under objective 2.4.

None of that requires specialized tooling — most of it shows up in a basic nmap --script ssl-enum-ciphers scan or a browser's own certificate inspector. That's exactly the kind of hands-on judgment objective 3.2 is testing, not protocol trivia for its own sake.

How This Shows Up in Exam Scenarios

CompTIA rarely asks "what year was TLS 1.3 released." Instead, expect something like: an admin is troubleshooting why a modern browser fails to connect to a legacy internal server — check whether the server only supports TLS 1.0/1.1. Or: a security audit flags a server using RSA key exchange with no forward secrecy. That's a TLS 1.2 configuration issue — the fix is either enabling ECDHE suites or moving to TLS 1.3 entirely. Or: a pentest report mentions the target "downgraded silently to a weaker cipher" — that's the exact scenario TLS 1.3's downgrade-detection sentinel was built to prevent.

Quick gut check: if a question describes a server that still negotiates RSA key exchange by default, could you name the missing property (forward secrecy) without the term being spelled out for you? If that's shaky, go back to the "Forward Secrecy" section above — it's the single concept objective 3.2 leans on hardest for TLS scenario questions.

FAQ

Is TLS 1.3 backward compatible with TLS 1.2?

They can coexist on the same server — a TLS 1.3-capable server can still serve TLS 1.2 clients — but the two protocol versions aren't compatible with each other at the wire level. A TLS 1.3 handshake looks structurally different from a TLS 1.2 one, which is exactly why the downgrade-detection sentinel value exists: to catch cases where a TLS 1.3-capable connection gets forced down to 1.2 unnecessarily.

Does the Security+ exam expect me to know the exact cipher suite names?

Not word-for-word, but you should recognize the pattern: TLS 1.3 suites are shorter and AEAD-only (like TLS_AES_128_GCM_SHA256), while TLS 1.2 suites are longer and specify a separate key-exchange method (like ECDHE-RSA-AES256-GCM-SHA384). Recognizing which format belongs to which version is more likely to appear than memorizing every suite name.

What's the minimum TLS version Security+ considers acceptable?

NIST SP 800-52 Rev. 2 sets TLS 1.2, configured with FIPS-validated cipher suites, as the floor for federal systems, with TLS 1.3 support required since January 1, 2024. Security+ generally follows this baseline: TLS 1.0 and 1.1 are treated as deprecated and unacceptable, TLS 1.2 with a modern cipher list is the minimum, and TLS 1.3 is the preferred target.

Why does 0-RTT resumption matter for the exam?

It's a common trick question setup: a feature that improves performance (0-RTT) but introduces a specific, nameable security tradeoff (replay risk). CompTIA likes testing whether you understand that speed and security aren't automatically the same thing — recognizing when a performance feature needs an extra safeguard is exactly what objective 3.2 is probing for.

How does this connect to the downgrade attacks in objective 2.4?

Directly. POODLE, FREAK, and Logjam — the downgrade attacks covered in objective 2.4 — all exploited the same gap. TLS 1.2 and earlier had no built-in way to detect a forced version or cipher downgrade. TLS 1.3's ServerHello.random sentinel value is the direct architectural fix for that entire class of attack.

Practice What You Just Learned

Reading through the TLS 1.3 vs TLS 1.2 differences is step one. Recognizing which behavior a Security+ scenario question is describing, under time pressure, is the actual skill objective 3.2 tests. Run through the free SY0-701 practice exam — all five domains, with a full explanation for every question including why the wrong answers are wrong. No account required, and nothing you enter leaves your browser.

Already have your own SY0-701 question bank? Upload your VCE or PDF to our free simulator and run through it instantly. Or keep reading more certification study guides covering Security+, CySA+, AWS, and Azure paths.

Related reading

• SY0-701 Cryptographic Attacks Explained (Objective 2.4)
• CySA+ vs Security+: Which CompTIA Cert to Take First?