Summary

  • RFC 8446, published in August 2018, makes supported_versions the place where TLS 1.3's actual version is negotiated. The legacy_version fields can still show 0x0303, the number for TLS 1.2, so old software will let the handshake pass.
  • A TLS 1.3-capable server that negotiates TLS 1.2 must end ServerHello.random with 44 4F 57 4E 47 52 44 01; for TLS 1.1 or below it must use the same first seven bytes followed by 00. A TLS 1.3 client seeing either marker in an older-version ServerHello must abort.
  • RFC 7507 had earlier addressed a different failure: a client's retry at a lower version can carry TLS_FALLBACK_SCSV, prompting a capable server to reject an inappropriate fallback. IANA records that value and alert.

An old number at the front door

A packet observer who reads only ServerHello.legacy_version in a TLS 1.3 exchange can report the wrong protocol. RFC 8446 sets that field to 0x0303, the old TLS 1.2 value. The actual selection moves to supported_versions. The field's name is a warning to the analyst: it describes inherited wire layout, not the decision the endpoints made. A monitoring system that equates the label with the active protocol can turn a compatibility device into a false account of security.

Why keep an old label at all? The TLS handshake had to pass through boxes that had learned its older shape. Some watched for familiar fields and failed when they saw a new pattern. RFC 8446's Appendix D.4 describes a compatibility mode that makes the TLS 1.3 exchange resemble TLS 1.2: the client supplies a non-empty session ID, and dummy ChangeCipherSpec messages can keep a middlebox on its expected path. The cryptographic protocol remains TLS 1.3 when the endpoints select it. The costume is for equipment in the middle.

That equipment acquired practical veto power without becoming a party to the security decision. A box that drops unfamiliar traffic can force endpoints to change how a new protocol presents itself. The IETF accommodated the deployed equipment's expectations in the wire image. It did not give that equipment authority to choose the protected connection's version. The version lives in the handshake extension read by the endpoints. This distinction between visible packaging and operating state is the center of the episode.

Eight bytes at the other end

The same standard anticipated a harsher trick: an on-path actor could try to make the endpoints settle for an older version. TLS 1.3 added a signal in the final eight bytes of a capable server's ServerHello.random. When such a server negotiates TLS 1.2, it must put 44 4F 57 4E 47 52 44 01 there. If it negotiates TLS 1.1 or below, it must use 44 4F 57 4E 47 52 44 00. The first seven bytes spell DOWNGRD in ASCII. The last byte tells the client which lower-version band the server chose.

A TLS 1.3 client that receives a ServerHello claiming TLS 1.2 or below must inspect those eight bytes. A match with either pattern requires it to abort with illegal_parameter. The client has learned that the server was capable of a newer protocol even though the visible negotiation fell back. Simply accepting the lower version would let an attacker exploit the room between what the endpoints can do and what the network allowed them to agree on.

The alarm has a defined reach. RFC 8446 describes it as limited additional protection beyond the Finished exchange. Its protection relies on signed random values when ephemeral cipher suites are used; it does not protect a static-RSA exchange in the same way. The RFC also observes that many TLS 1.2 implementations in the field would not follow the new rule. An eight-byte marker can only be enforced where a capable server emits it and a capable client checks it.

A different warning came from a client retry

The 2015 RFC 7507 tackled another path to an older protocol. Some clients responded to a failed handshake by retrying at a lower version for compatibility. An attacker who could provoke failure could encourage that step. TLS_FALLBACK_SCSV lets the client mark such a retry; if the server supports a version higher than the one in the retry, it returns inappropriate_fallback. IANA's TLS parameter registry records the signaling value and alert.

The 2018 marker is placed by the capable server in its random value; the 2015 signal comes from the client that is deliberately retrying lower. They expose different state at different points in the negotiation. Mixing them up would hide the part of the transaction each endpoint can actually attest. In both cases, an apparently successful older connection is not sufficient evidence that older was the best version available.

The wire costume has an owner

Appendix D.4 is a record of compromise under pressure from existing infrastructure. New security machinery had to imitate an older handshake just enough to get past boxes whose expectations had hardened into traffic policy. The sentinel in ServerHello.random drew a separate line: a compatibility costume must not quietly become consent to a forced downgrade. The endpoints could keep the version decision and make a lower choice observable to the client.

The official texts and registry establish these rules; a dated packet capture with client and server implementation records would establish whether a particular connection used the compatibility mode and emitted a sentinel. The historical claim is concrete without a deployment tally: in 2018, TLS 1.3 protected a new version by putting its real choice in an extension, while leaving old-looking fields on the wire and a warning at the end of a capable server's random value.