First, are you sure socat is using OpenSSL 1.1.0? Upstream (from socat.org) 1.7.2.4 source (released in 2014) is not compatible with OpenSSL 1.1.0 (released in 2016) which made significant API changes. Check ldd $(which socat). Are (both) your socat and OpenSSL from standard repositories, other builders/packagers, or built from source?

Anyway, although "what's new" doesn't say so and assuming whatever the "sig" patch is doesn't change it, 1.7.2.4 (upstream) source defaults to 512-bit DH parameters. That is indeed too small -- it was known breakable even before Logjam, and unacceptable to any libssl client from 1.0.1n or 1.0.2b up (both released 2015-06) (and any 1.1.0, first released 2016-08).

AFAICS your alternatives are:

• upgrade socat to at least 1.7.3.0 (which in upstream does have 1024-bit); 3.1+ with 2048-bit is even better

• generate, or obtain from somewhere, DH parameters of at least 1024 bits (2048 is better for most clients, including yours, although some clients may have trouble such as obsolete versions of Java) and add them to your server's cert file.

  You can generate DH parameters with openssl dhparam $n >file where $n is 1024 or 2048. If this is too slow you can add -dsaparam.

• ditto, but put the parameters in a separate file configured on the server. The manpage says this option is dhparams=<file> but the code says it is dh= and testing confirms the latter.

• configure the server or client, or both in some combination, so that they don't agree on a ciphersuite that uses DHE; since your server is the one at fault here, personally I would configure only the server. Again the manpage says ciphers but reality is cipher. Since 1.7.2.4 doesn't set 'tmp_ecdh' parameters, and (AFAICT) it can't use 1.1.0, it won't support ECDHE, which means without DHE your connections will not have Perfect Forward Secrecy. If you can accept that limitation, using ,cipher='DEFAULT:!DHE' on the server is a simple fix.

  (1.7.3.0 up do set 'tmp_ecdh' and support ECDHE, which would avoid the problem here even if they didn't default DH-1024 or better, because ECDHE suites are preferred over DHE, so ECDHE would be selected and then the DHE parameters aren't used and don't matter.)

First, are you sure socat is using OpenSSL 1.1.0? Upstream (from socat.org) 1.7.2.4 source (released in 2014) is not compatible with OpenSSL 1.1.0 (released in 2016) which made significant API changes. Check ldd $(which socat). Are (both) your socat and OpenSSL from standard repositories, other builders/packagers, or built from source?

Anyway, although "what's new" doesn't say so and assuming whatever the "sig" patch is doesn't change it, 1.7.2.4 (upstream) source defaults to 512-bit DH parameters. That is indeed too small -- it was known breakable even before Logjam, and unacceptable to any libssl client from 1.0.1n or 1.0.2b up (both released 2015-06) (and any 1.1.0, first released 2016-08).

AFAICS your alternatives are:

• upgrade socat to at least 1.7.3.0 (which in upstream does have 1024-bit); 3.1+ with 2048-bit is even better

• generate, or obtain from somewhere, DH parameters of at least 1024 bits (2048 is better for most clients, including yours, although some clients may have trouble such as obsolete versions of Java) and add them to your server's cert file.

  You can generate DH parameters with openssl dhparam $n >file where $n is 1024 or 2048. If this is too slow you can add -dsaparam.

• ditto, but put the parameters in a separate file configured on the server. The manpage says this option is dhparams=<file> but the code says it is dh= and testing confirms the latter.

• configure the server or client, or both in some combination, so that they don't agree on a ciphersuite that uses DHE; since your server is the one at fault here, personally I would configure only the server. Again the manpage says cipher but reality is ciphers. Since 1.7.2.4 doesn't set 'tmp_ecdh' parameters, and (AFAICT) it can't use 1.1.0, it won't support ECDHE, which means without DHE your connections will not have Perfect Forward Secrecy. If you can accept that limitation, using ,ciphers='DEFAULT:!DHE' on the server is a simple fix.

  (1.7.3.0 up do set 'tmp_ecdh' and support ECDHE, which would avoid the problem here even if they didn't default DH-1024 or better, because ECDHE suites are preferred over DHE, so ECDHE would be selected and then the DHE parameters aren't used and don't matter.)