¿Alguien puede explicar por qué existe una diferencia entre el relleno reclamado en PKCS7 enlace Página 22? Lo que es
01
02 02
03 03 03 ...
y relleno utilizado en TLS 1.2 enlace Página 24 o enlace 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 del relleno?
El relleno no es diferente, en realidad es 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 investiga a través de los RFC, encontrará que TLS 1.1, TLS 1.0, 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 misma longitud del relleno se da en texto plano como un campo en el paquete. Como esto daría lugar a que la longitud del relleno sea distinta de la del relleno mismo, se produce una situación en la que un relleno de 03 03 03 tiene un registro de longitud de 03 , dando un valor completo de 03 03 03 03 . Dicho esto, SSL 2.0 no usa relleno de estilo PKCS7, sino que utiliza relleno aleatorio, por ejemplo. %código%. Al llevar el mismo método de relleno a SSL 3.0 (y posteriormente 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 de seguridad o detrimento en tener un byte extra 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 implementar los nuevos protocolos sobre las pilas más antiguas.
Lea otras preguntas en las etiquetas tls