Pregunta:
¿Alguien puede explicar por qué hay una diferencia entre el relleno reclamado en PKCS7 https://www.rfc-editor.org/rfc/rfc2315 Página 22 – que es
01
02 02
03 03 03 …
y relleno utilizado en TLS 1.2 https://www.rfc-editor.org/rfc/rfc5246 Página 24 o http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf Página 1 – que es
00
01 01
02 02 02
03 03 03 03 …
¿Por qué los chicos de TLS no usaron la versión PKCS7 de relleno?
Respuesta:
El relleno no es diferente, en realidad es un relleno PKCS7. La diferencia es que los datos terminan con un campo de 1 byte que expresa la longitud del relleno. Como tal, lo que estás viendo es:
MAC Padding PadLen
xx xx xx .. xx | 05 05 05 05 05 | 05
Esto no es exclusivo de TLS 1.2; si examina las RFC, encontrará que TLS 1.1, TLS 1.0 y SSL 3.0 también comparten esta peculiaridad. La razón parece ser la compatibilidad heredada.
La especificación SSL 2.0 no es muy clara sobre cómo (o qué) se debe aplicar el relleno, pero la longitud del relleno en sí se da en texto plano como un campo en el paquete. Dado que esto daría como resultado que la longitud del relleno sea distinta del relleno en sí, se obtiene una situación en la que un relleno de 03 03 03 tiene un registro de longitud de 03 , lo que da un valor total de 03 03 03 03 . Dicho esto, SSL 2.0 no usa relleno de estilo PKCS7, sino que utiliza relleno aleatorio, por ejemplo, A3 89 03 03 . Al llevar el mismo método de relleno a SSL 3.0 (y más tarde a TLS), probablemente se vio que era más fácil adaptar el código existente.
Entonces, la respuesta es: no hay ningún beneficio o detrimento de seguridad en tener el byte adicional en TLS 1.2, siempre que todos los bytes del relleno estén correctamente verificados. La razón por la que está ahí es por el soporte heredado y la facilidad de implementación de los nuevos protocolos sobre las pilas más antiguas.