TLS, and What Each Version Fixed

What SSL 3.0 had already fixed. RFC 6176 lists what was wrong with SSL 2.0: message authentication used MD5; the handshake was not protected, which "permits a man-in-the-middle to trick the client into picking a weaker cipher suite"; one key served for both integrity and encryption; and a forged TCP FIN could end a session unnoticed. SSL 3.0 answered the last three: its Finished message checks every handshake message, it derives separate MAC and encryption keys, and its close_notify alert lets each side tell a real end from a truncation.

What each version fixed

TLS 1.1 also answered the padding-oracle attack the record-layer chapter described, by sending bad_record_mac rather than decryption_failed for a padding error, so that the two failures look the same. TLS 1.2 removed MD5 and SHA-1 from the PRF: "All cipher suites in this document use P_SHA256", as the handshake chapter's run did.

TLS 1.3: a new handshake

Figure 80.1 TLS 1.2 needs two round trips before the client can send data; TLS 1.3 needs one, and hides the certificate.

RFC 9846 lists the major differences from TLS 1.2. In an answer they come to seven.

• One round trip. The client sends a key share in its very first message, guessing which group the server will accept, so the server can reply with its own share, its certificate and its Finished in one flight. If the guess is wrong the server sends a HelloRetryRequest, which costs a round trip.
• Forward secrecy always. "Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy."
• Authenticated encryption only. The legacy algorithms were pruned, and "Those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms". Compression is gone, and with it the CRIME attack.
• An encrypted handshake. "All handshake messages after the ServerHello are now encrypted", the server's certificate included.
• A new key schedule, built on HKDF, which the second run reproduces.
• Version negotiation in an extension. The version travels in a supported_versions list, and the ChangeCipherSpec protocol is removed "except when needed for middlebox compatibility".
• Shorter cipher suites. A TLS 1.3 suite names only the AEAD cipher and the hash, TLS_AES_256_GCM_SHA384 for example; the key exchange and the signature are negotiated separately.

Zero round trips, at a price. A client returning to a server it knows can send 0-RTT "early data" in its first message. RFC 9846 warns that the security of 0-RTT data is weaker: it is not forward secret, and "There are no guarantees of non-replay between connections". A client may therefore send as early data only what it deems "safe to be replayed": fetching a page, say, never a payment.

The run: munotes.in, and the mark that stops a downgrade

The first listing reads two real handshakes with munotes.in, captured on 30 September 2026: one by a client offering TLS 1.3, and one by a client offering only TLS 1.2. It reports what the server chose, looks at the last bytes of the server's random value, and checks the server's ECDSA signature itself, on the NIST P-256 curve, with the public key from munotes.in's certificate.

# TLS 1.3 ServerHello, its first 96 of 1,210 bytes
02 00 04 b6 03 03 50 2c 7c e9 08 9b bb d2 ad 6c
46 ae ba ba eb 1a 58 21 d0 e7 8c fc 3e 96 a1 b8
79 8e 3c d4 15 52 20 46 e3 1c b7 1d f6 2d 32 bf
8c 77 8d 3d 23 4c 37 95 19 1a e7 18 91 80 27 0e
3e 31 eb 42 d3 f5 2f 13 02 00 04 6e 00 2b 00 02
03 04 00 33 04 64 11 ec 04 60 95 23 7f f8 f7 3f
# TLS 1.2 ClientHello, its first 38 bytes
01 00 00 c7 03 03 bc 8d 5c 0f 58 10 2b c7 2e 45
4f 7e 44 af 60 68 c8 d8 c6 3b a6 a3 78 35 f0 fc
b5 99 b9 df 47 62
# TLS 1.2 ServerHello
02 00 00 41 03 03 b7 e7 ec d1 a2 ca 5b 71 a2 f6
61 c0 f7 f0 16 3d c1 c5 a2 fd 19 d9 0e 6e 44 4f
57 4e 47 52 44 01 00 c0 2c 00 00 19 ff 01 00 01
00 00 00 00 00 00 0b 00 04 03 00 01 02 00 23 00
00 00 17 00 00
# TLS 1.2 ServerKeyExchange
0c 00 00 6e 03 00 1d 20 7b 33 36 05 81 a9 e8 05
be 23 c0 54 5a 0a 74 a1 11 ba 36 0a 39 ea 0e 9e
7d 41 55 65 79 45 1e 27 04 03 00 46 30 44 02 20
58 36 10 85 f0 3a d8 79 3a d0 f8 5a 2e 99 c9 91
73 b1 51 4e cd 64 1a 1f c1 54 00 db 7a 90 09 49
02 20 3c 1b c3 42 df d6 8e 88 cb 49 2f de 28 38
ca 0f e3 11 3b 66 7a a1 7a 5e 89 e4 16 d2 f3 f8
bc c9
# public key in the certificate munotes.in sent
04 b6 50 14 d1 56 d0 7c 49 38 1d 3a d7 e6 12 16
b9 4a 62 43 6d 06 1e 13 55 ba a1 3e 64 35 43 f5
42 d2 ac e7 f8 2a 0f 2a 4a 7d 20 b4 b4 0f 46 4e
5f 54 17 ff d6 55 2e b3 c8 a8 10 a3 00 57 6f 93
b7

What the run establishes, in order.

munotes.in speaks TLS 1.3, with a post-quantum key exchange. The ServerHello's version field says 0x0303, TLS 1.2, and the real version, 0x0304, is in the supported_versions extension: RFC 9846 keeps the old field fixed because servers "incorrectly implemented version negotiation". The key share is group 4588, X25519MLKEM768, which RFC 10024 (August 2026) defines as ML-KEM-768, the post-quantum method of FIPS 203, combined with X25519, "to provide security as long as at least one of the component algorithms remains secure". Its 1,120 bytes are 1,088 of ML-KEM and 32 of X25519.

Asked for TLS 1.2, the server agrees but leaves a mark. The last eight bytes of its random value spell DOWNGRD followed by the byte 01, which RFC 9846 requires of any TLS 1.3 server that negotiates TLS 1.2. This client offered only TLS 1.2, so it carries on. A client that had offered TLS 1.3 and still received TLS 1.2 would know its offer was removed on the way, and "MUST abort the handshake with an "illegal_parameter" alert".

The mark cannot be rubbed out. In a TLS 1.2 handshake with an ephemeral key exchange, the server signs both random values together with its key share. munotes.in's signature verifies, and with the last eight bytes changed it fails, so an attacker who erased the mark would be caught by the signature check. RFC 9846 states the limit: the mark "does not provide downgrade protection when static RSA is used", because RSA key exchange carries no such signature, one more reason RFC 10015 now forbids it.

The run: TLS 1.3's key schedule

RFC 8448 publishes every secret of a real TLS 1.3 handshake, so that anyone can check an implementation against it. The second listing takes that handshake's client private key and server key share, computes the X25519 shared secret, and derives each secret in the order RFC 9846 gives, comparing each with the value RFC 8448 prints.

# ClientHello, RFC 8448 s.3
010000c00303cb34ecb1e78163ba1c38c6dacb196a6dffa21a8d9912
ec18a2ef6283024dece7000006130113031302010000910000000b00
09000006736572766572ff01000100000a00140012001d0017001800
190100010101020103010400230000003300260024001d002099381d
e560e4bd43d23d8e435a7dbafeb3c06e51c13cae4d5413691e529aaf
2c002b0003020304000d0020001e0403050306030203080408050806
04010501060102010402050206020202002d00020101001c00024001
# ServerHello, RFC 8448 s.3
020000560303a6af06a4121860dc5e6e60249cd34c95930c8ac5cb14
34dac155772ed3e2692800130100002e00330024001d0020c9828876
112095fe66762bdbf7c672e156d6cc253b833df1dd69b1b04e751f0f
002b00020304

RFC 8448 s.3 REPRODUCED (196-byte ClientHello, 90-byte ServerHello)
  shared       X25519 of the client key and the server share         True
  early        HKDF-Extract(0, 0): no pre-shared key                 True
  handshake    HKDF-Extract(Derive-Secret(early, "derived"), shared) True
  c hs traffic Derive-Secret(handshake, "c hs traffic", hellos)      True
  s hs traffic Derive-Secret(handshake, "s hs traffic", hellos)      True
  main         HKDF-Extract(Derive-Secret(handshake, "derived"), 0)  True
  server key   HKDF-Expand-Label(s hs traffic, "key", 16)            True
  server iv    HKDF-Expand-Label(s hs traffic, "iv", 12)             True

ONE BIT OF THE CLIENTHELLO CHANGED
  server handshake key  94712fcdb8f02c7e447fa656c5c1d2a4
  the same as before:   False

What the run establishes, in order.

HKDF replaces the PRF. TLS 1.2 expanded one master secret with its PRF, as the handshake chapter ran. TLS 1.3 builds a chain: an early secret, then a handshake secret that mixes in the key exchange's result, then the main secret, which RFC 8446 and RFC 8448 call the master secret. Each step is HKDF-Extract, and each key is HKDF-Expand-Label with a label of its own ("c hs traffic", "s hs traffic", "key", "iv"), so the client's keys and the server's, and the handshake's and the data's, are always different.

The hellos are hashed into the keys. The handshake secrets are derived from a hash of the ClientHello and the ServerHello. With one bit of the ClientHello changed, the server's handshake key is completely different, so an attacker who edits either hello leaves the two sides holding keys that do not match, and the handshake fails.

What is forbidden now

• SSL 2.0. RFC 6176 (March 2011) requires that TLS clients and servers "never negotiate the use of SSL version 2.0".
• SSL 3.0. RFC 7568 (June 2015): "SSLv3 MUST NOT be used", because it "is not sufficiently secure"; its CBC padding "trivially permits the recovery of plaintext", the POODLE attack.
• TLS 1.0 and TLS 1.1. RFC 8996 (March 2021): "TLS 1.0 MUST NOT be used" and "TLS 1.1 MUST NOT be used". Among its reasons: "The integrity of the handshake depends on SHA-1 hash", and neither version supports AEAD ciphers. RFC 9846 (Appendix E.5) repeats it for all four old versions: "they MUST NOT be negotiated for any reason".
• RSA key exchange, even in TLS 1.2. RFC 10015 (July 2026): "Clients MUST NOT offer and servers MUST NOT select RSA cipher suites in (D)TLS 1.2 connections". Finite-field Diffie-Hellman in TLS 1.2 is forbidden in the same words.

New names for old secrets. RFC 9846 (Appendix D) renames TLS 1.2's master secret the main secret and the pre-master secret the preliminary secret, keeping the label inside the PRF unchanged "for compatibility". An answer written from the syllabus's textbook uses master secret, and that is correct for the exam; knowing the new names shows the answer is current.

Distinctions that carry marks

What beginners get wrong here

Treating SSL and TLS as rival protocols. TLS is SSL continued under a new name by the IETF. Every version of SSL is now prohibited; people who say "SSL certificate" mean a certificate used with TLS.

Giving TLS 1.0 or 1.2 as the latest version. TLS 1.0 and 1.1 have been deprecated since 2021. The current version is TLS 1.3, specified since July 2026 by RFC 9846.

Reading a TLS 1.3 cipher suite as naming the key exchange. TLS_AES_256_GCM_SHA384 says nothing about how the keys were agreed; that is the key share group, X25519MLKEM768 for munotes.in.

Calling 0-RTT a free speed-up. Early data can be replayed by an attacker and is not forward secret.

Saying TLS always encrypts the certificate. Only TLS 1.3 does; TLS 1.2 sends it in the clear.

Thinking the downgrade mark is secret. It is a fixed, public value. It works because the server signs its random value, so the mark cannot be removed unnoticed.

Quick revision

• TLS is the IETF's SSL: RFC 2246 (January 1999), version {3, 1} because it is a minor change to SSL 3.0.
• SSL 3.0 to TLS 1.0: version, HMAC, the PRF, master secret, alerts (no_certificate out, 12 in), cipher suites (Fortezza out), certificate types, certificate_verify and finished (12 bytes from the PRF), padding (up to 255 bytes).
• 1.1 (2006): explicit IV. 1.2 (2008): SHA-256 PRF, named hash in signatures, AEAD. 1.3 (2018, re-published as RFC 9846 in July 2026): one round trip, forward secrecy always, AEAD only, encrypted handshake, HKDF.
• Forbidden: SSL 2.0 (RFC 6176), SSL 3.0 (RFC 7568), TLS 1.0 and 1.1 (RFC 8996), RSA and finite-field DH key exchange in TLS 1.2 (RFC 10015).
• Downgrade mark: DOWNGRD with 01 (fell to 1.2) or 00 (fell to 1.1 or below), protected by the server's signature.
• munotes.in, 30 September 2026: TLS 1.3, TLS_AES_256_GCM_SHA384, key exchange X25519MLKEM768.
• TLS 1.2's master and pre-master secrets are called the main and preliminary secrets since RFC 9846.

Test yourself

1. What is TLS? State how TLS 1.0 differs from SSL 3.0. TLS is the IETF's standard version of SSL, first specified in RFC 2246 in 1999. TLS 1.0 differs from SSL 3.0 in the version number (3.1 against 3.0); the MAC, which is HMAC and also covers the version; the pseudorandom function, which expands secrets using P_MD5 and P_SHA-1 together and also computes the master secret; the alert codes, where no_certificate was removed and twelve were added; the cipher suites, where Fortezza was dropped; the client certificate types, which fell from seven to four; the certificate_verify message, which hashes only the handshake messages; the finished message, which is 12 bytes computed with the PRF; and the padding, which may be up to 255 bytes to hide message lengths.

2. Why does TLS 1.0 carry the version number 3.1? Because TLS 1.0 is a minor modification of SSL 3.0, whose version is 3.0. RFC 2246 calls the value 3.1 historical. TLS 1.1 and 1.2 continued the scheme as 3.2 and 3.3.

3. What did TLS 1.1 and TLS 1.2 each change? TLS 1.1 (RFC 4346, 2006) replaced the implicit CBC initialisation vector with an explicit one to protect against CBC attacks, and reported padding errors with bad_record_mac instead of decryption_failed. TLS 1.2 (RFC 5246, 2008) replaced the MD5 and SHA-1 combination in the PRF with a PRF chosen by the cipher suite, P_SHA256 in all its own suites, replaced the combination in signatures with a single named hash, and added authenticated encryption modes such as AES-GCM.

4. List the major differences between TLS 1.2 and TLS 1.3. TLS 1.3 completes the handshake in one round trip instead of two, and allows zero-round-trip early data on resumption; it removes static RSA and Diffie-Hellman, so every key exchange is forward secret; it keeps only AEAD ciphers and removes compression; it encrypts every handshake message after the ServerHello, including the certificate; it replaces the PRF with an HKDF key schedule; it moves version negotiation into the supported_versions extension and drops ChangeCipherSpec; and its cipher suites name only the AEAD cipher and hash.

5. Why can a TLS 1.3 handshake finish in one round trip? Because the client sends its Diffie-Hellman key share in the ClientHello, guessing the group the server will choose. The server can then compute the shared secret at once and send its own share, its encrypted certificate, CertificateVerify and Finished in a single reply. In TLS 1.2 the key exchange needed a second round trip after the hellos.

6. How does TLS 1.3 protect against an attacker forcing an older version? First, the hellos are hashed into the handshake keys, so any change to them makes the keys disagree and the handshake fail. Second, a TLS 1.3 server that negotiates TLS 1.2 must end its random value with the bytes DOWNGRD 01, or DOWNGRD 00 for an older version, and a client that offered TLS 1.3 must abort if it sees them. Because in TLS 1.2 the server signs its random value, the mark cannot be erased without the signature failing, as munotes.in's own handshake shows.

7. Which versions of SSL and TLS may no longer be used, and on whose authority? SSL 2.0 is prohibited by RFC 6176 (2011), SSL 3.0 by RFC 7568 (2015), and TLS 1.0 and 1.1 by RFC 8996 (2021); RFC 9846 (2026) repeats that none of the four may be negotiated for any reason. TLS 1.2 remains in use, but RFC 10015 (2026) forbids RSA and finite-field Diffie-Hellman key exchange within it.