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

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
theonlylawislove
Posts: 34
Joined: Thu, 2014-07-17, 09:07

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

#1 Post by 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
DCMTK Developer
Posts: 2498
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

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

#2 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

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

#3 Post by 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
Posts: 6
Joined: Thu, 2007-12-06, 23:16

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

#4 Post by 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
Posts: 6
Joined: Thu, 2007-12-06, 23:16

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

#5 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1435
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

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

#6 Post by 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.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 1 guest