0

I've got a scenario where some older clients are only able to support MD5 and SHA1 signatures. Obviously these are generally considered deprecated but I do still need to support them. Upgrading these clients is not something that can be done (Updates to firmware are no longer being published, ideally I'd like to axe all these devices but that isn't viable either).

Assume I can still get hold of an MD5 or SHA1 signed certificate.

Is it possible to on any (https) server serve different certificates based on the incoming TLS version as contained in the ClientHello block sent by the client on first connecting?

I trust it should be possible by writing a small "proxy" of sorts that just read the first few bytes incoming from the client and then splicing the connection to alternate ports serving different requests in the worst case, but if possible I'd prefer to avoid that if there are existing web servers that do support something like this.

Aside: As I understand the SSL/TLS protocol does contain protection against downgrade attacks, so if the server supports 1.2 and the client also support 1.2 then if a downgrade to 1.0 happens then the connection should terminate (in case of an active man-in-the-middle attack). I believe this should mitigate the risk of serving MD5 or SHA1 signed certificates at least as much as can be done whilst still supporting older SSL/TLS versions.

0

Nginx with its lua extension and the ssl part of it can choose a certificate to expose based on the start of the handshake, and what the client sent as ClientHello but maybe not what you need precisely (list of algorithms supported).

The full documentation is at https://github.com/openresty/lua-resty-core/blob/master/lib/ngx/ssl.md and https://github.com/openresty/lua-nginx-module/#ssl_certificate_by_lua_block

It states:

It is particularly useful for setting the SSL certificate chain and the corresponding private key on a per-request basis.

...

One can also do interesting things with the SSL handshake requests from the client side, like rejecting old SSL clients using the SSLv3 protocol or even below selectively.

You can easily access the client or server IP (for multihomed ones) through the function raw_client_addr and raw_server_addr, as well as the hostname the client is attempting to reach by reading the SNI part with server_name. Based on the documentation I do not see getting access to other part of client ClientHello, but you could maybe find a solution already with the above if you can discriminate your clients based on their IP maybe, or if you have two separate server names, each one can become tied to a specific certificate.

Reading https://github.com/openresty/lua-nginx-module/blob/master/src/ngx_http_lua_ssl_certby.c I see no specific method accessing the list of cipher suites sent by client. However that piece of code gets all underlying "SSL" information from the openssl library so I suspect what you want is technically possible there but just needs to be coded.

Now two other points:

1) "Assume I can still get hold of an MD5 or SHA1 signed certificate."

This may be hard. At least from a public known CA under default operation. CAB Forum requirements (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf) has this on page 38:

Subscriber Certificates

Digest algorithm: SHA1*, SHA-256, SHA-384 or SHA-512

* SHA-1 MAY be used with RSA keys in accordance with the criteria defined in Section 7.1.3.

and then:

7.1.3. Algorithm Object Identifiers

Effective 1 January 2016, CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm.

2) "As I understand the SSL/TLS protocol does contain protection against downgrade attacks, so if the server supports 1.2 and the client also support 1.2 then if a downgrade to 1.0 happens then the connection should terminate (in case of an active man-in-the-middle attack)."

Yes, but only if using extension TLS_FALLBACK_SCSV, and probably forbidding client renegotiation during an existing session. See https://crypto.stackexchange.com/questions/19673/how-does-tls-fallback-scsv-help#19674 for explanations, but quoting the core part of it:

Essentially, TLS_FALLBACK_SCSV allows clients to send a hidden version number in the downgraded connection attempt in a way that doesn't trigger the server bugs.

Wikipedia page at https://en.wikipedia.org/wiki/Transport_Layer_Security also discusses in detail things about downgrade attacks.

This is improved in TLS 1.3 by the way, quoting 4.1.3. Server Hello from RFC8446:

TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 servers which negotiate TLS 1.2 or below in
response to a ClientHello MUST set the last 8 bytes of their Random
value specially in their ServerHello.

and

For all handshake modes, the Finished MAC (and, where present, the signature) prevents downgrade attacks. In addition, the use of
certain bytes in the random nonces as described in Section 4.1.3
allows the detection of downgrade to previous TLS versions. See
[BBFGKZ16] for more details on TLS 1.3 and downgrade.

  • WOW. Thank you for a very complete and comprehensive answer. I'll mark this accepted based purely on the documentation: get_tls1_version My assuption currently is that the provider of the devices have installed their own CA cert on the devices and is capable of signing certs with that root cert still. – Jaco Kroon Feb 6 at 19:05
0

I had a very similar problem. I don't believe you will find a server that does what you ask. I also think you should stop looking for one:

You should NOT rely on MD5 or SHA1 certificates to secure any connections. These certificates are considered vulnerable because there is a risk that someone can forge these certificates. All clients should now reject old MD5 and SHA1 certificates.

You should avoid any clients talking to your servers on insecure connections. If any clients or servers can't be upgraded then you should put them in their own secure sandbox.

How to solve the problem

Like you, I've supported old software that could not be upgraded. Whatever the security advice, we all have to work with what we've got.

I recommend stunnel. This runs as a stand alone server which forwards all connections it receives: either encrypting or decryption them first.

To use this, you would ideally install it on the old host. Disable SSL on the old software and configure it to connect unencrypted to stunnel instead of connecting with (insecure) encryption to your server:

[  "Sandbox"                             ]      [    Wherever       ]
[[ old box                              ]]      [[   Wherever      ]]
[[[ old Client ] ---->[ stunnel client ]]] ---->[[[ actual server ]]]

If installing it on the same box is not an option then install it on a new box securely connected to the old host. That could just be a raspberry pi plugged into the same switch:

[  Securely on the same LAN  ("Sandbox")   ]      [    Wherever       ]
[[ old box      ]      [ new box          ]]      [[   Wherever      ]]
[[[ old Client ]] ---->[[ stunnel client ]]] ---->[[[ actual server ]]]

If the old software refuses to connect unencrypted then you could use stunnel again, act as a server offering up an old MD5 or SHA1 certificate. Again, the two should be physically connected because you should think of a connection with an old certificate like it is unencrypted:

[             Securely on the same LAN ("Sandbox")                ]      [    Wherever       ]
[[ old box      ]      [ new box                                 ]]      [[   Wherever      ]]
[[[ old Client ]] ---->[[ stunnel server ]---->[ stunnel client ]]] ---->[[[ actual server ]]]
  • I fully agree with this: You should NOT rely on MD5 or SHA1 certificates to secure any connections. This isn't about making it secure. It's about "making it work". As you yourself noted. Thanks for your response. However ... using stunnel isn't an option since both the older as well as newer devices connect to the same URL (destination IP) and I have no way of differentiating them until I've received (seen) the ClientHello. – Jaco Kroon Feb 6 at 18:58

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.