El relleno en TLS es casi el mismo que el relleno PKCS # 7, pero con algunas diferencias sutiles.
Al usar el cifrado CBC, en TLS, las cosas van de la siguiente manera:
-
El MAC se calcula sobre el texto sin formato y se adjunta al texto sin formato. En el caso de TLS_RSA_WITH_AES_128_CBC_SHA, eso es HMAC / SHA-1, por lo que 20 bytes adicionales.
-
Lo que se cifrará es la concatenación del texto plano, el MAC y el relleno. La longitud total debe ser un múltiplo del tamaño del cifrado del bloque, es decir, 16 en el caso de AES. El relleno consiste en agregar n +1 bytes, de manera que 0 ≤ n ≤ 255. Por lo tanto, hay al menos 1 byte adicional, como máximo 256, todos tienen el mismo valor , y ese valor es uno menos que la longitud de relleno.
(En el verdadero relleno PKCS # 7, habría n +1 bytes que todos tienen el valor n +1, no n . )
-
Tras el descifrado, DEBEN verificarse los contenidos de los bytes de relleno, así como el MAC. Hacerlo de manera segura es difícil de hacer pero si está escribiendo una herramienta de inspección, entonces usted es el atacante y, por lo tanto, puede permitirse hacer las cosas de manera más insegura.
En la versión anterior de SSL 3.0, solo el último byte de relleno tenía que tener el valor n , los otros bytes eran aleatorios (y esto es una debilidad en el protocolo). A la inversa, en SSL 3.0, no se permitió que la longitud total del relleno excediera la longitud del cifrado del bloque, mientras que en TLS puede ser más larga (hasta 256 bytes), siempre que la longitud total del mensaje rellenado sea un múltiplo de la longitud del bloque.
Para una herramienta de inspección, el método de implementación más simple sería descifrar con el relleno "ninguno", y luego inspeccionar y eliminar el relleno y el MAC con el código explícito que usted mismo escribe. No hay un método de relleno "estándar" implementado en Java que coincida con la variante utilizada en TLS.
Si está interesado en descifrar el protocolo de enlace de SSL / TLS, puede ser una buena idea escribir primero su propia biblioteca de SSL / TLS, no para uso de producción (estas cosas son muy difíciles de entender con respecto a ataques de canal lateral ), pero más para ganar experiencia en los detalles finos del protocolo. Cuando su propia biblioteca logra completar un apretón de manos, sabe que los obtuvo todos correctamente. Además, los elementos del código serán reutilizables para su herramienta de inspección. Por lo tanto, escribir su propia biblioteca es una buena inversión pedagógica (siempre que recuerde la condición: ¡no para uso de producción!).
Es posible que desee leer esta respuesta como introducción al protocolo.