0
$\begingroup$

For a little background, I am trying resolve an issue with an ISAM (reverse proxy) appliance not being able to connect to a server due to it failing to complete a TLS connection.

A server that is connecting just fine is using ECDHE-RSA-AES256-GCM-SHA384, with peer signing digest of SHA512. This is on a tomcat server.

The on that's having trouble is using ECDHE-RSA-AES256-SHA384, with a peer signing digest of SHA1. This is on Microsoft IIS.

Based on my research, Windows doesn't support ECDHE-RSA-AES256-GCM-SHA384 as a cipher suite (which is fine), but what I don't understand is what the peer signing digest is and why, even with SHA1 hashes disabled on windows, is SHA1 being used.

This may not solve my server issue, but I would like to understand what the peer signing digest is.

$\endgroup$
1
$\begingroup$

Peer Signing Digest is the hash algorithm used by the peer (i.e. the server from the perspective of the client) when signing things during TLS handshake. You will find these places by looking for the term digitally-signed in the TLS RFC. See for example the details of the ServerKeyExchange message in wireshark:

https://imgur.com/a/uEQf3

.. even with SHA1 hashes disabled on windows

SHA1 is not disabled on Windows in general. It is disabled only for use within the issuers signature of a certificate.

$\endgroup$
  • 1
    $\begingroup$ Note this is a new feature in TLSv1.2. For earlier versions, this field does not exist in the protocol and s_client output does not include it. (But ciphersuites using GCM or other AEAD, or SHA2 hashes, require 1.2.) $\endgroup$ – dave_thompson_085 Feb 24 '18 at 3:42

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.