TLS v1.3 support issue

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
amal.jesudas
Posts: 18
Joined: Tue, 2017-12-19, 11:49

TLS v1.3 support issue

#1 Post by amal.jesudas » Mon, 2021-03-29, 09:08

Hi,

Recently I observed a case where TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 was set at the client side (SCU) but the client hello message listed below cipher suites:
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
This occurred when the SCU was hosted from a virtual machine.
Similar case was not observed when I ran the SCU from a host machine and tested using dcm4che test applications.
On analysis, one possible cause that we came across was related with TLSv1.3 support.

When using openssl, there is a possible issue scenario where TLSv1.3 could be negotiated even if we set only TLSv1.2 cipher suites.
To do away with this, one suggested solution is to call openssl API SSL_CTX_set_max_proto_version() to disable TLSv1.3.
Does dcmtk have support to limit the supported TLS version?

Regards,
Amal
Last edited by amal.jesudas on Thu, 2021-04-08, 13:23, edited 1 time in total.

J. Riesmeier
DCMTK Developer
Posts: 2291
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: TLS version support

#2 Post by J. Riesmeier » Mon, 2021-03-29, 11:41

Does this commit (from May 2019) solve your issue?

amal.jesudas
Posts: 18
Joined: Tue, 2017-12-19, 11:49

Re: TLS version support

#3 Post by amal.jesudas » Thu, 2021-04-01, 08:31

J. Riesmeier wrote:
Mon, 2021-03-29, 11:41
Does this commit (from May 2019) solve your issue?
Hi Jörg,

I was just scrolling through the commit you mentioned.
As per initial impression the flag "tls13_enabled" could do the trick for us.

In tlslayer.cc, SSL_CTX_set_max_proto_version() API is called to set TLSv1.2 as maximum version if tls13_enabled flag is false.
Also, I am seeing that in constructor of DcmTLSCiphersuiteHandler in tlsciphr.cc, the flag is initialized with OFTrue.
If an application that uses dcmtk does not work in profile mode, I don't see a provision for resetting this flag or setting max proto version.
It would have been better if there was an API for setting max proto version so that people using TLS functionality in legacy applications could call and use the same.
Something on below lines:

Code: Select all

DcmTransportLayerStatus DcmTLSTransportLayer::SetMaxProtoVersion(long version)
{
    if (transportLayerContext)
    {
       #if OPENSSL_VERSION_NUMBER >= 0x10101000L && !defined(LIBRESSL_VERSION_NUMBER)
           SSL_CTX_set_max_proto_version(transportLayerContext, version);
       #endif
    }else return TCS_illegalCall;
    
   return TCS_ok;
}
The above observations are made based on my limited exposure on these implementations.
Please correct me if my understanding and observations are in-correct.

Regards,
Amal

amal.jesudas
Posts: 18
Joined: Tue, 2017-12-19, 11:49

Re: TLS version support

#4 Post by amal.jesudas » Wed, 2021-04-07, 08:34

Just as a note to help people facing similar issues due to TLSv1.3 support, the above proposed solution works.
I modified tlslayer.cc to add a new API to set max proto version.
In our case, we set max proto version directly to TLS1_2_VERSION instead of passing as parmeter to API.

Code: Select all

DcmTransportLayerStatus DcmTLSTransportLayer::SetMaxProtoToTLS1_2()
{
	if (transportLayerContext)
	{
#if OPENSSL_VERSION_NUMBER >= 0x10101000L && !defined(LIBRESSL_VERSION_NUMBER)
		SSL_CTX_set_max_proto_version(transportLayerContext, TLS1_2_VERSION);
#endif
	}
	else return TCS_illegalCall;

	return TCS_ok;
}
The call to the new API was made as soon as a valid transport layer object [DcmTLSTransportLayer] was created.

For example:

Code: Select all

obj_tLayer = new DcmTLSTransportLayer(NET_ACCEPTOR, NULL, OFTrue);
if (obj_tLayer == NULL)
{
    Log("Failed to create transport layer object.");
    return;
}

if (TCS_ok != obj_tLayer->SetMaxProtoToTLS1_2())
{
    Log("Unable to set max supported version as TLSv1.2.");
    return;
}
Regards,
Amal

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1280
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: TLS v1.3 support issue

#5 Post by Marco Eichelberg » Sun, 2021-04-11, 17:20

Normally there should not be the need to limit the TLS version. The TLS versions and ciphersuites negotiated are defined in profiles in DICOM part 15. You select a profile and DCMTK will do the right thing. The "Extended BCP 195 TLS Profile" will only negotiate TLS 1.2, whereas the default "BCP 195 TLS Profile" and the "Non-downgrading BCP 195 TLS Profile" will support both TLS 1.2 and TLS 1.3.

amal.jesudas
Posts: 18
Joined: Tue, 2017-12-19, 11:49

Re: TLS v1.3 support issue

#6 Post by amal.jesudas » Mon, 2021-04-12, 10:27

Marco Eichelberg wrote:
Sun, 2021-04-11, 17:20
Normally there should not be the need to limit the TLS version. The TLS versions and ciphersuites negotiated are defined in profiles in DICOM part 15. You select a profile and DCMTK will do the right thing. The "Extended BCP 195 TLS Profile" will only negotiate TLS 1.2, whereas the default "BCP 195 TLS Profile" and the "Non-downgrading BCP 195 TLS Profile" will support both TLS 1.2 and TLS 1.3.

Hi Marco,

As you mentioned, this issue will not occur if cipher suite implementation is done based on profiles.
In our application, we have not implemented profile support.
We are setting individual ciphers to DcmTLSTransportLayer.
Being a legacy application, we need to support a number of cipher suites including some that are no longer recommended.
We have already proposed to change to cipher suites based on profiles.

Regards,
Amal

Post Reply

Who is online

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