1

I'm using HAProxy 1.7.5 and openssl 1.1.0f (from Debian 9.5 stabel) to serve TLS connections. Now there are clients offering SHA-384 and SHA-512 based signature algorithms in the client hello message. So HAProxy uses RSA+SHA512 in the DH key agreement. Unfortunately due to a software bug the clients crash when choosing any signature algorithm using a hash algorithm beyond SHA-256.

This cannot easily be fixed on the client side as we are talking about hardware devices. So I need a server-side workaround to disable SHA-384 and SHA-512 based signature algorithms in Haproxy. Up to now we could do so because we were using IIS which in turn uses SCHANNEL (the Windows TLS implementation). With this solution it is possible to deactive signature algorithms.

Is there a way to deactivate specific TLS signature algorithms in HAProxy?

Essentially this is a repost of this question - hoping that is has been answered meanwhile: HAProxy configure TLS 1.2 signature algorithms extension

C.Scharfenberg
  • 63
  • 7
  • haproxy uses openssl not schannel. See [here](https://raymii.org/s/snippets/haproxy_set_specific_ssl_ciphers.html) how to configure the ciphers in haproxy. And simply don't use the SHA384 and SHA512 ciphers in your configuration. – Steffen Ullrich Jan 17 '19 at 14:44
  • The signature algorithm is specified in the signature_algorithms extension of the client hello message. It is independant from the cipher suite. So I cannot influence the signature algorithm by chosing cipher suites. Please refer to: https://crypto.stackexchange.com/questions/31479/certificate-signature-algorithm-differs-from-signature-algorithm-negotiated-for and https://tools.ietf.org/html/rfc5246#page-45, paragraph 7.4.1.4.1. – C.Scharfenberg Jan 17 '19 at 15:04
  • Where exactly is haproxy using these algorithms outside of ciphers where the client cannot deal with? PRF should use SHA-256 only. And signature algorithm in the certificate can not be negotiated anyway since the certificate is already fixed at time of TLS handshake. – Steffen Ullrich Jan 17 '19 at 15:19
  • "The verification of the certificate and the signatures in the TLS handshake use the hash / signature pair negotiated in the signature_algorithms extension" (https://crypto.stackexchange.com/questions/31479/certificate-signature-algorithm-differs-from-signature-algorithm-negotiated-for) – C.Scharfenberg Jan 17 '19 at 15:29
  • "If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key)." (https://tools.ietf.org/html/rfc5246#section-7.4.2) – C.Scharfenberg Jan 17 '19 at 15:29
  • The client cannot make the server choose the signature algorithm of the certificate. The certificate is already there and it has a fixed signature hash algorithm. All what could happen is that no matching existing certificate with the supported algorithm can be found. It does not matter if the client claims to support also SHA-512 if the certificate is only signed with SHA-256. – Steffen Ullrich Jan 17 '19 at 15:39
  • So maybe I'm wrong with my explanation. But from my experience with IIS/Channel I know that the client does not crash any more if SHA-384 and SHA-512 based signature algorithms are deactivated on the server side. – C.Scharfenberg Jan 17 '19 at 15:45
  • The signature algorithm of the certificate itself is sha256RSA. Interestingly this is not included in the signature_algorthms offered by the client. – C.Scharfenberg Jan 17 '19 at 15:48
  • If the client does not support the signature and hash algorithm of the certificate then you are out of luck with the current certificate and need to create one which is supported by the client. Strange client though since this is likely the most commonly used algorithm for certificates currently. – Steffen Ullrich Jan 17 '19 at 16:00
  • We're using exactly this certificate for that specific type of client for years now - with IIS and SHA-384/SHA-512 signature algorithms disabled. – C.Scharfenberg Jan 17 '19 at 16:05
  • Either your claim that sha256RSA is not included in `signature_algorithms` is wrong or the client is supporting even even if not including in `signature_algorithms`. Still - the only place which should matter in your case regarding disabling SHA-384 etc is IMHO the cipher list - as I said in the beginning. – Steffen Ullrich Jan 17 '19 at 16:13
  • Concerning cipher suites I allow exactly one: ECDHE-RSA-AES128-SHA256. This is the only one supported by the client. – C.Scharfenberg Jan 17 '19 at 16:22
  • Having a closer look onto Wireshark I notice that the client offers 16 signature algorithms to the server (not including SHA256RSA, but SHA224RSA and SHA256DSA) while the server only considers 15 of them in the Certificate Request message. It rejects an MD5 hash algorithm. So I conclude that in principle it should be possible to also reject SHA-384 and SHA-512. – C.Scharfenberg Jan 17 '19 at 16:25
  • I must correct myself: The client does include SHA256RSA in its signature algorithm list but it is not named "SHA256 RSA" (the naming convention used by most other algorithms) but instead it is named "rsa_pkcs1_sh256". I'm not yet sure if this has a special meaning. – C.Scharfenberg Jan 17 '19 at 16:36
  • The openssl library itself has the ability to set the supported signature algorithms. But this is not exposed into the configuration of haproxy. But like I said already multiple times (and it looks like you did not check yet) - it should be sufficient to disable ciphers with SHA384 and SHA512 since these should be the only places where these hashes are actually used. – Steffen Ullrich Jan 17 '19 at 16:39
  • So what do you mean by "disable ciphers with SHA384 and SHA512"? As mentioned before I've only enabled one cipher suite: ECDHE-RSA-AES128-SHA256. What else can I do to disable other cipher suites? – C.Scharfenberg Jan 17 '19 at 16:45
  • Oh, I did not see this specific comment. So it is still not working? How do you conclude that the problem is the signature_algorithm? What error messages you get? Can you provide a packet capture as pcap file? – Steffen Ullrich Jan 17 '19 at 16:51
  • Unfortuntely I do not get error messages. Instead the client just crashes. I think that this is caused by the signature algorithm because we've encountered the same type of crash some years ago when a Windows upgrade introduced the SHA-384 and SHA-512 hash algorithms in the SCHANNEL stack. We could work around this by disabling these algorithms in the Windows registry. – C.Scharfenberg Jan 17 '19 at 17:02
  • I've chosen a somewhat fishy method to share the pcap: https://pastebin.com/QVtDYf3j. It's base64 encoded. – C.Scharfenberg Jan 17 '19 at 17:08
  • I see, it is using SHA-512 in the ECC key exchange. So your only option might then be to use RSA key exchange, i.e ciphers like TLS_RSA_WITH_AES_128_CBC_SHA256 (AES128-SHA256) or TLS_RSA_WITH_AES_128_GCM_SHA256 (AES128-GCM-SHA256). It does not provide forward secrecy though. Apart from that: the server is not supposed to send the root certificate too. – Steffen Ullrich Jan 17 '19 at 17:43
  • Thanks for your support. Unfortunately I cannot change the cipher suite as this would require a software update of the client (which is feasible for 90% of all clients but not for 100%). So obviously I have to switch back to IIS... That is very unfortunate and trashes a month of work... – C.Scharfenberg Jan 18 '19 at 08:37

1 Answers1

1

The solution for me is: install haproxy 1.8.17 with openssl 1.1.1a from Debian testing. For some reason this combination uses RSA+SHA256 as signature algorithm in the DH key exchange.

The intention was to use the openssl configuration file (/etc/ssl/openssl.cnf) to set the signature algorithm E.g.

[ system_default_sect ]
SignatureAlgorithms       = RSA+SHA256
ClientSignatureAlgorithms = RSA+SHA256

This setting is only available since openssl 1.1.1. But it does not show any effect for me. Anyway, the above-mentioned software combination seems to be sufficient.

I would be grateful if anybody could offer me an explanation for this behaviour.

C.Scharfenberg
  • 63
  • 7
  • I still don't know why openssl 1.1.1a chooses RSA+SHA256 by default. But the settings in system_default_sect are respected if I build my openssl.cfg correctly. I needed to add these lines before the section:[default_conf] ssl_conf = ssl_sect [ssl_sect] system_default = system_default_sect – C.Scharfenberg Jan 22 '19 at 13:21
  • Scharfenberg - Thanks for this post...! I was pointing to the wrong direction as Steffen was too. The signature algorithm is set by OpenSSl and not by the ciphers suits. So the output from `openssl s_client -connect your_host:your_port` Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA – Nestor Sep 12 '19 at 06:06