número de secuencia TLS

Para obtener la respuesta exacta , consulte el estándar .

Para un breve resumen: el número de secuencia es implícito y no se transmite. Tanto el remitente como el receptor realizan un seguimiento de la cantidad de registros que enviaron y recibieron, por lo que no necesitan que se repita en el registro mismo (y si estaba allí, tendrían que verificarlo, porque el punto de la secuencia el número es para detectar duplicados, registros eliminados y registros fuera de orden).

Sin embargo, los registros TLS 1.1 y 1.2 tienen IV explícito , para los modos de cifrado de bloque que los requieren (en SSL 3.0 y TLS 1.0, el IV de un registro era una copia del último bloque cifrado de el registro anterior, que permitió ataques de texto sin formato elegido , popularizado en el caso de TLS con el nombre "BEAST" ). Para las suites de cifrado que requieren el modo de cifrado CBC, la IV debe generarse de forma aleatoria y, desde el punto de vista de Wirehark, esta IV aparecerá como "aleatoria". Sin embargo, TLS 1.2 también admite los modos de cifrado AEAD , que son modos avanzados de cifrado por bloques que no solo combinan el cifrado y el MAC (mientras que las suites de cifrado basadas en CBC necesitan un HMAC adicional para la integridad), pero también son menos exigentes con su IV.

Considere en particular GCM conjuntos de cifrado, especificados en RFC 5288 . GCM necesita un IV de 12 bytes, que no tiene que ser aleatorio; la única restricción es que no se utilizará ningún valor IV para más de un registro, para una clave simétrica dada. Cuando se utiliza GCM en TLS, los primeros 4 bytes de la IV se computan como parte de la derivación de la clave de handshake , y todos los registros en una conexión dada usan los mismos valores para estos cuatro bytes; los 8 bytes restantes se transmiten con el registro en sí, y depende del remitente garantizar que no se reutilice ningún valor de 8 bytes dentro de una conexión específica. Como RFC 5288 lo pone:

Each value of the nonce_explicit MUST be distinct for each distinct
invocation of the GCM encrypt function for any fixed key.  Failure to
meet this uniqueness requirement can significantly degrade security.
The nonce_explicit MAY be the 64-bit sequence number.

Vea en particular esta última oración: usar un contador está bien, y el número de secuencia de registro es tal contador. Esto es lo que observa: la implementación TLS específica que está estudiando parece utilizar una copia del número de secuencia como (parte de) IV para cada registro. Esto está permitido, y está bien (repito: esto está bien para los conjuntos de cifrado GCM ; para los conjuntos de cifrado CBC, esto sería débil).

tenga en cuenta los detalles: es no obligatorio utilizar el número de secuencia para este campo; en realidad no es obligatorio usar un contador en absoluto. El extremo receptor de un registro TLS no debe asumir que el campo nonce_explicit será igual al número de secuencia; en su lugar, debe utilizar el valor del campo como se recibió. Además, tanto el remitente como el receptor deben seguir el seguimiento del número de secuencia, ya que el número de secuencia es parte de los "datos autenticados" en el cálculo de AEAD. Es conveniente e inteligente utilizar el número de secuencia como nonce_explicit , y RFC 5288, previendo la pregunta, declara explícitamente que está bien.

(El estándar TLS hubiera sido un poco menos complejo si hubieran especificado que el IV para GCM era el número de secuencia, sin necesidad de enviarlo por cable; pero RFC 5246 intenta ser genérico para acomodar a otros futuros modos AEAD que pueden tener otros requisitos en el IV.)

Para estudiar estos detalles de manera eficiente , una buena estrategia es implementar su propia biblioteca SSL / TLS, no para uso de producción, sino para el valor pedagógico. Cuando el código de su cliente (servidor respectivamente) logre hablar con una implementación de servidor existente (cliente respectivamente), habrá aprendido mucho. Incluso afirmaré, por experiencia, que no hay un método mejor para aprender TLS.

Sí, la visibilidad de los números de secuencia depende del conjunto de cifrado: en un cifrado AEAD, el número de secuencia se incluye en los datos adicionales (RFC5246, 6.2.3.3):

additional_data = seq_num + TLSCompressed.type +
                            TLSCompressed.version + 
                            TLSCompressed.length;

Los datos adicionales se autentican , pero no están cifrados . Así puedes ver su contenido utilizando Wireshark.

En los otros cifrados admitidos por TLS 1.2, a saber, cifrado de flujo y modo de cifrado de bloque CBC, el número de secuencia está implícitamente en el MAC (RFC5246, 6.2.3.1):

MAC = HMAC(MAC_write_key, seq_num +
                          TLSCompressed.type +
                          TLSCompressed.version +
                          TLSCompressed.length +
                          TLSCompressed.fragment);

Por lo tanto, no es visible allí.