La autenticación del cliente en TLS normalmente usa un certificado del cliente y el método por el cual el cliente se autentica no ha cambiado sustancialmente desde SSL 3.0: durante el protocolo inicial, el servidor solicita la autenticación del cliente (un CertificateRequest message), y el cliente responde enviando su certificado y luego una firma calculada con su clave privada sobre la concatenación de todos los mensajes anteriores de intercambio (que incluye los dos "valores aleatorios" enviados por el cliente y el servidor, y también los paquetes de cifrado negociados, el certificado del servidor ...).
Sin embargo, hay detalles. Un algoritmo de firma utiliza una función hash, y el valor de hash se usa con la clave privada. Hasta TLS 1.1, el cliente usaba necesariamente la concatenación de MD5 y SHA-1 como "función hash". Con TLS 1.2, el cliente y el servidor se envían entre sí la lista de funciones de hash y los tipos de firmas que admiten, para que el cliente pueda elegir una función de hash "adecuada" y también un certificado apropiado en caso de que el cliente sea propietario de varios.
El método pre-1.2 emplea un "relleno especial" con RSA: en PKCS # 1 , el valor de hash se almacena primero en una estructura que identifica la función de hash (en la práctica, se adjunta un encabezado fijo al valor de hash), y esa estructura codificada se rellena con algunos bytes (la mayoría de ellos es igual a 0xFF ) hasta la longitud de la clave. En las firmas utilizadas de SSL 3.0 a TLS 1.1, el valor de hash tiene una longitud de 36 bytes (16 bytes para MD5, 20 bytes para SHA-1) y no hay encabezado : los 36 bytes son directamente utilizado en "relleno de tipo 1". Con TLS 1.2, solo se usa una función hash (negociada entre el cliente y el servidor), y el encabezado está de vuelta.
Por lo tanto, TLS 1.2 se alinea con el estándar PKCS # 1 y admite muchas funciones hash, lo que debería mejorar la interoperabilidad. Sin embargo, es concebible que un token de hardware específico para la clave privada del cliente (por ejemplo, una tarjeta inteligente) pueda ser incompatible con TLS 1.2 (si es compatible con solo el 36-byte-hash-with-no- modo de encabezado de SSL / TLS anterior). En ese sentido, TLS 1.2 podría romper la compatibilidad con los tokens implementados (esto es bastante improbable, pero todavía justifica algunas pruebas). Para las implementaciones de software, esto no debería ser un problema.