Resumen

  • RFC 8446, publicada en agosto de 2018, negocia la versión real de TLS 1.3 mediante supported_versions. Los campos legacy_version conservan 0x0303, número de TLS 1.2; leerlos como resultado final falsea el registro de la conexión.
  • Si un servidor capaz de TLS 1.3 pacta TLS 1.2, debe terminar ServerHello.random con 44 4F 57 4E 47 52 44 01. Si pacta TLS 1.1 o menos, acaba en 00. Un cliente TLS 1.3 que ve cualquiera de esas marcas en una respuesta de versión anterior debe abortar.
  • La RFC 7507, de 2015, trató otro retroceso: el cliente que reintenta con una versión menor puede indicar ese hecho con TLS_FALLBACK_SCSV, y un servidor capaz de más contesta inappropriate_fallback. IANA registra ambos valores.

El número viejo en la entrada

Un observador que lea únicamente ServerHello.legacy_version en una conexión TLS 1.3 podría clasificarla como TLS 1.2. RFC 8446 mantiene allí 0x0303 y lleva la decisión a supported_versions. El adjetivo «legacy» señala el cometido del campo: conservar la forma heredada de un mensaje, no informar qué protección ejecutan los extremos. Un sistema de vigilancia que confunda esa etiqueta con la versión real puede producir un inventario de seguridad equivocado.

El motivo estaba en el camino entre esos extremos. Algunos equipos intermedios habían aprendido la forma anterior de la negociación y fallaban ante valores nuevos. El apéndice D.4 de RFC 8446 describe un modo de compatibilidad: el cliente puede enviar un identificador de sesión no vacío y aparecen mensajes ChangeCipherSpec ficticios para ofrecer una silueta familiar. Cuando los extremos seleccionan TLS 1.3 en la extensión, ejecutan TLS 1.3. La ropa antigua se muestra a las máquinas del trayecto.

Esas máquinas adquirieron un veto práctico sin tener el papel de decidir el cifrado. Si un equipo descarta lo que no entiende, obliga al protocolo nuevo a cambiar de apariencia. El estándar aceptó esa presión sobre la imagen del intercambio, pero dejó la decisión de versión en una extensión leída por los participantes. Qué ve el intermediario y qué pactan los extremos dejaron de ser la misma pregunta.

Una advertencia al final del valor aleatorio

El disfraz de compatibilidad convivía con un riesgo distinto: un actor en el trayecto podía intentar llevar la conexión a una versión más vieja. RFC 8446 ordena que un servidor TLS 1.3 capaz de negociar TLS 1.2 escriba en los últimos ocho bytes de ServerHello.random la secuencia 44 4F 57 4E 47 52 44 01. Si negocia TLS 1.1 o menos, el último byte es 00. Los siete primeros forman DOWNGRD en ASCII. El último indica la franja de versiones a la que se ha bajado.

El cliente TLS 1.3 que recibe un ServerHello de TLS 1.2 o inferior debe examinar esas dos secuencias. Si encuentra una, interrumpe la negociación con illegal_parameter. El servidor ha indicado que podía hablar una versión superior aunque el resultado visible sea la antigua. Conseguir que la conexión vieja funcione no contesta por qué dos extremos con capacidad nueva acabaron usando menos.

La norma especifica el alcance de la señal. La llama protección adicional limitada respecto al intercambio Finished. Con suites de claves efímeras, la firma en el protocolo anterior cubre los valores aleatorios; con RSA estático no ofrece el mismo resguardo. El propio RFC advierte que muchas implementaciones TLS 1.2 ya instaladas no seguirán la regla nueva. Los ocho bytes sirven donde un servidor capaz los emite y un cliente capaz los comprueba.

El aviso de 2015 salía del otro lado

La RFC 7507 abordó en 2015 el reintento del cliente. Tras un fallo, algunos clientes probaban una versión inferior por compatibilidad. Un atacante que provocara fallos podía empujar la conexión hacia atrás. TLS_FALLBACK_SCSV marca el nuevo intento; si el servidor admite una versión superior a la ofrecida en ese reintento, responde inappropriate_fallback. El registro de IANA conserva la señal y la alerta.

La marca de 2015 la aporta el cliente que vuelve a llamar con menos capacidades. La de 2018 nace en el valor aleatorio de un servidor capaz de TLS 1.3. No son dos nombres para un mismo dato: cada una deja constancia de lo que sabía una parte en un momento diferente. La pregunta valiosa es quién sabía que había una versión mejor cuando la negociación retrocedió.

El disfraz tenía dueño

El apéndice D.4 retrata una concesión exigida por equipos ya desplegados. TLS 1.3 tuvo que parecerse lo suficiente al pasado para no ser expulsado de la red. La marca en ServerHello.random marcó el límite de esa cesión: un aspecto familiar no concedía a un intermediario permiso para forzar una versión inferior en silencio. Los extremos conservaron la autoridad para elegir y para denunciar un resultado más bajo cuando el servidor conocía una opción mejor.

Las normas y el registro establecen el mecanismo. Para comprobar si una conexión concreta usó el modo de compatibilidad y la marca harían falta una captura fechada y registros de implementación de cliente y servidor. La historia de 2018 ya es precisa: TLS 1.3 puso su elección verdadera en una extensión, dejó un número viejo en la puerta y obligó al servidor capaz que retrocedía a encender un aviso en los últimos bytes de su valor aleatorio.