3
$\begingroup$

I have a service and I want to authenticate my clients using SSL client certificates. Now I want the key exchange process to be as simple as possible, kind of like SSH: You generate a keypair and upload the public key to the server (which you already trust).

Now I want to verify the certs I get from the clients… not by their trust chain, but solely based on the certificates I have stored on the server.

Should I compare the whole certificate or only the SHA256-Hash?

$\endgroup$
1
  • $\begingroup$ You say that you upload only the public key to the server and later want to verify the client certificate. That would mean that during validation you will need to extract the public key from the client certificate and compare only that part because the client certificate will have more information (public key, name, signature, etc.). BTW: if this is for client verification in TLS, it would be interesting to know if there are standard libraries that allow this server-side behavior (use public keys instead of certificates, kind of client certificate pinning). $\endgroup$
    – astraujums
    Aug 26, 2019 at 13:54

1 Answer 1

1
$\begingroup$

Your problem boils down to the following:

  • Client shows $v$ (his certificate).
  • Server wants to know whether $v$ is the same one as previously. He may store $v$ itself, but $v$ is somewhat bulky, so the server would like to store $h(v)$ only, for a hash function $h$.

So can an attacker show up with a value $v'$, distinct from $v$, such that $h(v') = h(v)$ ? If the attacker can, he wins. If he cannot, then storing $h(v)$ is sufficient.

If the hash function is second preimage resistant, then, by definition, the attacker cannot. SHA-256 is believed to be second preimage resistant.


I must also insist that the certificate is only the public part; the server must still extract the public key from the certificate sent by the client, and use it to verify the signature sent by the client as part of the ClientKeyExchange handshake message. Normally, the SSL implementation takes care of that point.

An edge case happens with DSA public keys. A DSA public key contains some parameters (modulus $p$, subgroup order $q$, generator $g$) and the actual user-specific public value ($y$). It is allowed, as per X.509, to omit the parameters from the certificate, keeping only $y$, if the certificate is signed by a CA which also uses DSA with the same parameters. This is parameter's inheritance. This is not compatible with your idea, because the client's public key cannot then be extracted from the user's public key alone; you still need X.509 path validation. But, in practice, this won't happen: nobody really uses DSA certificates, let alone DSA with parameter inheritance.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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