My client-side DCMTK TLS code broke after upgrading to 3.6.4.

[theonlylawislove]

Full details, repro, and logs, can be found here: https://github.com/pauldotknopf/dcmtk-tls-issue

These commands don't work as of 3.6.4, and they did previously:

Code: Select all

storescp --log-level trace --enable-tls /work/domain.key /work/domain.crt -ic 104
echoscu +tla -ic localhost 104

When running those commands, I get this error:

Code: Select all

E: ETLS client handshake failed: 
Receiving Association failed: 0006:031e DUL secure transport layer: no suitable signature algorithm
F: Association Request Failed: 0006:031b Failed to establish association
F: 0006:0317 Peer aborted Association (or never connected)
F: 0006:031e DUL secure transport layer: sslv3 alert handshake failure

Is there something I can add to echoscu to make the client work? Then, I can dig into the source to figure out how to fix my issue.

Thanks!

[J. Riesmeier]

Hmm, I tried the same calls with DCMTK 3.6.6 (current release), and it works.

Code: Select all

> storescp --version
$dcmtk: storescp v3.6.6 2021-01-14 $

storescp: DICOM storage (C-STORE) SCP

Host type: x86_64-unknown-linux-gnu
Character encoding: system default (unknown)

External libraries used:
- ZLIB, Version 1.2.11
- OpenSSL 1.1.1f  31 Mar 2020
- LIBWRAP

Code: Select all

> echoscu --version
$dcmtk: echoscu v3.6.6 2021-01-14 $

echoscu: DICOM verification (C-ECHO) SCU

Host type: x86_64-unknown-linux-gnu
Character encoding: system default (unknown)

External libraries used:
- ZLIB, Version 1.2.11
- OpenSSL 1.1.1f  31 Mar 2020

[Marco Eichelberg]

The TLS error message indicates that during the TLS handshake no signature algorithm could successfully be negotiated. In order to troubleshoot this issue in detail, you should capture a detailed log of the TLS handshake. You can do this for example using the "tshark" tool, which is part of the Wireshark package: https://www.wireshark.org/docs/man-pages/tshark.html. For example, on my Linux machine the following command will instruct tshark to capture and print a detailed dump of the TLS handshake where the server accepts connections on port 11112 and the client runs on the same system:

Code: Select all

sudo tshark -i lo -f "port 11112" -d tcp.port==11112,ssl -O ssl

[shlomgad]

I am facing the same problem after upgrading to 3.6.4
Using storescu to send files to storescp, on Ubuntu 20.
Getting the error "E: Receiving Association failed: 0006:031e DUL secure transport layer: no suitable signature algorithm".
Wondering if there is a fix for that.

[shlomgad]

This is also happening with storescp 3.6.6 as the server on Ubuntu 20.04 LTS (after building from source code) and storescu 3.6.4 as the client.
Output of storescp --version is:

Code: Select all

$dcmtk: storescp v3.6.6 2021-01-14 $

storescp: DICOM storage (C-STORE) SCP

Host type: x86_64-Linux
Character encoding: system default (unknown)

External libraries used:
- ZLIB, Version 1.2.11
- OpenSSL 1.1.1f  31 Mar 2020

[Marco Eichelberg]

This is probably a problem of combining DCMTK 3.6.4 with OpenSSL 1.1.1.
DCMTK 3.6.4 was developed and tested with OpenSSL 1.1.0, and a change that is required for OpenSSL 1.1.1 and newer (commit ID 7bdfa34cd) was only committed shortly after the release of DCMTK 3.6.4.