Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

From wikipedia link (cannot post due to stackexchange constraints). "http://www.yassl.com/yaSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html" and and also from the RFC http://tools.ietf.org/html/rfc5246 , I don't see any major differences in client authentication between TLS 1.2 and earlier version. However, at the same time, there is no specific statement that says that they are similar. I need to do a check to understand this before starting to work with TLS 1.2. I am wondering if due to the other changes (e.g. changes like this

-There was substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept.

-Addition of support for authenticated encryption with additional data modes."

it may be implied that TLS 1.2 has notable differences. Inputs are welcome.

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

Client authentication in TLS normally uses a client certificate and the method by which the client is authenticated has not substantially changed since SSL 3.0: during the initial handshake, the server asks for client authentication (a CertificateRequest message), and the client responds by sending his certificate and then a signature computed with his private key over the concatenation of all the previous handshake messages (which includes the two "random values" sent by the client and the server, and also the negotiated cipher suites, the server's certificate...).

There are details, though. A signature algorithm uses a hash function, and the hash value is then used with the private key. Up to TLS 1.1, the client necessarily used the concatenation of MD5 and SHA-1 as "hash function". With TLS 1.2, client and server send to each other the list of hash functions and signature types they support, so that the client may choose an "appropriate" hash function, and also an appropriate certificate in case the client owns several of them.

The pre-1.2 method employs a "special padding" with RSA: in PKCS#1, the hash value is first stored in a structure which identifies the hash function (in practice, a fixed header is attached to the hash value), and that encoded structure is then padded with some bytes (most of them equal to 0xFF) up to the key length. In the signatures used from SSL 3.0 to TLS 1.1, the hash value has length 36 bytes (16 bytes for MD5, 20 bytes for SHA-1), and there is no header: the 36 bytes are directly used in "type 1 padding". With TLS 1.2, only one hash function is used (negotiated between client and server), and the header is back.

Thus, TLS 1.2 aligns itself with the PKCS#1 standard and supports many hash function, which should improve interoperability. Yet, it is conceivable that a specific hardware token for the client private key (e.g. a smart card) could be incompatible with TLS 1.2 (if it supported only the 36-byte-hash-with-no-header mode of older SSL/TLS). In that sense, TLS 1.2 might break compatibility with deployed tokens (this is rather improbable, but still warrants some tests). For software implementations, this should not be an issue.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.