1

I was reviewing some information about SSL certificates and came across an explanation I believe to be incorrect.

The explanation is of how signatures and hashing algorithms work in the context of connection using SSL.

This is a small section cut from the material:

"When a secure connection is initially requested by a client, and I've told you in previous chapters that the server sends a whole bunch of information to that client about itself along with its own public certificate. The information that is sent includes information about which HASH functions are supported, which encryption technologies are supported, etc.

And so if both the client and the server support SHA-2 for example, they'll choose SHA-2."

From my understanding, there is no negotiation of a certificate's signature. It is true that the client and server will trade information about protocol version, encryption ciphers, etc, to decide on what to use.

But the server's certificate is signed by the CA during issuance, and that signature is fixed and uses whatever algorithm the user (or CA) choose during the issuance process. If you were to go get a certificate today, you would probably have a SHA-256 signature.

If the client does not support SHA-256 there is no "negotiation" about other hashing algorithms is there? Wouldnt the connection just fail?

  • 1
    please include the source of the quote – schroeder Oct 22 '15 at 21:35
  • Where in the quote does it say that the signature is negotiated? – schroeder Oct 22 '15 at 21:37
  • From what you posted, I'm not seeing anything incorrect. I'm not saying you are wrong, I just do see where it's saying that negotiation is about the certificate. I think it's saying they will negotiate what will be used for the rest of the conversation. Perhaps there's more text that you have excluded that says something else? – JimmyJames Oct 22 '15 at 21:38
  • @schroeder the last sentence of the quote: "And so if both the client and the server support SHA-2 for example, they'll choose SHA-2." There is no "choosing" SHA-2. The certificate's signature is SHA-2, or SHA-1, etc. The client either supports it, or it dosent. Right? The source is from Lynda.com's course "Understanding Secure Sockets Layer", which is behind a paywall. – Vincent L Oct 22 '15 at 22:23
  • Ah- I see your disconnect. There's the crypto used to create the certificate, then the crypto negotiated between the client and server. Sometimes, they use the same crypto, but for those different things. – schroeder Oct 22 '15 at 23:23
0

The hash for the signature of a given cert is fixed, but a server is permitted to have more than one cert, and so is a client. TLS1.2 adds a hello extension that allows the client to specify which signature algorithms it can handle, as pairs of hash+PKC like SHA256+RSA or SHA384+ECDSA; the server should choose and send a suitable cert if it has one. If it doesn't have a cert the client can handle, too bad -- unless the client and server both agree to an "anonymous" ciphersuite which doesn't require any cert, which is insecure against active attack and therefore usually prohibited.

Similarly if the server requests a client certificate aka client authentication, which is rare, in 1.2 it specifies acceptable signature algorithms and the client should choose accordingly. For all versions the client (also) needs to consider the list of acceptable CAs specified by the server, unless the server has chosen to leave that list empty, which is even more rare.

Also, the server doesn't directly send information about what it "supports". ServerHello chooses exactly one ciphersuite, and one compression algorithm, from the lists offered by ClientHello. If using ECC, the subsequent Cert and possibly ServerKeyExchnage select one curve and pointformat from among those offered. There is no information on any other suites, compressions, or curves and points that the server supports and might use in response to a different ClientHello. The server also chooses one protocol version in the range offered by the client; if the server chooses below the client maximum it is a safe bet the server doesn't support higher, but if it agrees the client maximum it could well support higher. Contrast with SSH where both sides send full lists and compute the intersection; but SSH normally doesn't use certs at all, only bare publickeys.

1

There indeed is no negotiation, but the quote is still mostly correct.

The certificate is simply static. If you have the certificate file and openssl installed, you can see exactly what it contains with this command line:

openssl x509 -in <crtfile> -noout -text

The same information is also available within Web browsers, but you have to be a bit careful; using openssl is better. What the Web browser shows you isn't as raw as what openssl shows you, and the Web browser will add some additional information that is derived from the certicate. In particular, you may see both an SHA1 and an SHA256 fingerprint - don't get confused, those are not in the cert itself.

When you look at the signature within the certificate, you will usually only see one signature, and that will obviously be the one that is being used - if the client doesn't support that signature algorithm, there is nothing they can agree on, and that's the end of it. If the client does support it, then it can immediately start using that certificate.

It is also conceivable that a certificate contains several signatures using different algorithms (although I don't think the certificate format actually supports that; this idea would be only theoretical), but even then, the same would still hold true.

So, the "negotiation" basically consists of the server sending the certificate with the signature algorithm and telling the client "here it is, take it or leave it".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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