DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Sat, 2018-08-18, 13:07

All times are UTC + 1 hour




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: Open SSL Cipher Suites
PostPosted: Sun, 2018-02-04, 10:30 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
I want to test cipher suite support for a DICOM server for the following cipher suites:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384


As a start I tried to check support for these using dcmtk binaries storescp and storescu.
But, even on creating these binaries with openssl support, the above cipher suites were not supported.
Later I added these to the DcmCipherSuiteList of tlslayer.cc.
Although the initial error is changed, association still does not happen.
The error at storescp is:
E: Receiving Association failed: 0006:031e DUL secure transport layer: no shared cipher

The error at storescu is:
E: TLS client handshake failed
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


The above error is on using openssl v1.1.0f binaries, to make dcmtk storescp and storescu, for the cipher suites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. The other cipher suites seem to work for openssl v1.1.0f.

I need to use openssl v1.0.2n, but it returns "no ciphers available" for all the above cipher suites.
On checking the openssl code, it was seen that the same is being logged from ssl3_client_hello() function inside \ssl\s3_clnt.c as shown below:
i = ssl_cipher_list_to_bytes(s, SSL_get_ciphers(s), &(p[2]), 0);
if (i == 0) {
SSLerr(SSL_F_SSL3_CLIENT_HELLO, SSL_R_NO_CIPHERS_AVAILABLE);
goto err;
}


Can anyone suggest what modification is required to make storescp and storescu support these cipher suites?
Also, is there any other tool that I could use to test support for the above four cipher suites?

Any help is highly appreciated.
Thanks in advance.

Regards,
Amal


Top
 Profile  
 
PostPosted: Mon, 2018-02-12, 20:19 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
amal.jesudas wrote:
I want to test cipher suite support for a DICOM server for the following cipher suites:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384


As a start I tried to check support for these using dcmtk binaries storescp and storescu.
But, even on creating these binaries with openssl support, the above cipher suites were not supported.
Later I added these to the DcmCipherSuiteList of tlslayer.cc.
Although the initial error is changed, association still does not happen.
The error at storescp is:
E: Receiving Association failed: 0006:031e DUL secure transport layer: no shared cipher

The error at storescu is:
E: TLS client handshake failed
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


The above error is on using openssl v1.1.0f binaries, to make dcmtk storescp and storescu, for the cipher suites TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. The other cipher suites seem to work for openssl v1.1.0f.

I need to use openssl v1.0.2n, but it returns "no ciphers available" for all the above cipher suites.
On checking the openssl code, it was seen that the same is being logged from ssl3_client_hello() function inside \ssl\s3_clnt.c as shown below:
i = ssl_cipher_list_to_bytes(s, SSL_get_ciphers(s), &(p[2]), 0);
if (i == 0) {
SSLerr(SSL_F_SSL3_CLIENT_HELLO, SSL_R_NO_CIPHERS_AVAILABLE);
goto err;
}


Can anyone suggest what modification is required to make storescp and storescu support these cipher suites?
Also, is there any other tool that I could use to test support for the above four cipher suites?

Any help is highly appreciated.
Thanks in advance.

Regards,
Amal


It seems no one at dcmtk has seen a similar issue.
At present dcm4che supports the four cipher suites that I require.
So, one tool supports for sure.
Still would have preferred to work with storescp and storescu of dcmtk :( .

Regards,
Amal


Top
 Profile  
 
PostPosted: Mon, 2018-02-12, 21:13 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1963
Location: Oldenburg, Germany
I only have a few general remarks:

  • Make sure that the desired ciphersuites are supported by your OpenSSL version (check with "openssl ciphers -v").
  • If they are not supported, check whether a newer version supports them or whether you need to enable them by some switch.
  • If you add new ciphersuites to the DCMTK (in "tlslayer.cc"), make sure that you use the correct OpenSSL names.

Btw, please avoid double postings, i.e. write the same question to multiple forums.


Top
 Profile  
 
PostPosted: Mon, 2018-02-12, 21:41 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
J. Riesmeier wrote:
I only have a few general remarks:

  • Make sure that the desired ciphersuites are supported by your OpenSSL version (check with "openssl ciphers -v").
  • If they are not supported, check whether a newer version supports them or whether you need to enable them by some switch.
  • If you add new ciphersuites to the DCMTK, make sure that you use the correct OpenSSL names.


Thank you Jörg for taking time to reply.
Regarding your points, i would like to put my two cents:

[1]I checked with 1.1.0f(pre-compiled binaries provided by dcmtk) and 1.0.2n versions of openssl. 1.1.0f version supports the below two cipher suites(but not the other two):
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
[2] Enabling using some switch was also what I thought I could have missed. Would be helpful if you could provide some more information on this. At present, somewhere I could see mention of enabling a flag to get support for 3DES ciphers.
[3] The open ssl mapping I did is as given below:
{"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256", TLS1_TXT_DHE_RSA_WITH_AES_128_GCM_SHA256}
{"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384", TLS1_TXT_DHE_RSA_WITH_AES_256_GCM_SHA384}
{"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256", TLS1_TXT_ECDHE_RSA_WITH_AES_128_GCM_SHA256}
{"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", TLS1_TXT_ECDHE_RSA_WITH_AES_256_GCM_SHA384}
Please let me know if you think something is wrong.

Additionally, would like to add a query regarding updating storescp support for new cipher suites.
The current cipherSuiteList [File: \dcmtls\libsrc\tlslayer.cc] is not updated to include many new items.
Does this update to include new items take place with new versions of dcmtk OR is there some other reason for not preferring to update the same?

* I shall remove a similar posting in another thread. Added there because Marco worked on something very similar.

Regards,
Amal


Top
 Profile  
 
PostPosted: Tue, 2018-02-13, 09:41 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1963
Location: Oldenburg, Germany
Quote:
At present, somewhere I could see mention of enabling a flag to get support for 3DES ciphers.

Yes, and this flag was not set for the DCMTK 3.6.2 support libraries, so the Basic TLS Secure Transport Connection Profile did not work anymore. With the recently published DCMTK 3.6.3, this flag has been enabled. See DCMTK Bug #799.

Quote:
Additionally, would like to add a query regarding updating storescp support for new cipher suites.
The current cipherSuiteList [File: \dcmtls\libsrc\tlslayer.cc] is not updated to include many new items.
Does this update to include new items take place with new versions of dcmtk OR is there some other reason for not preferring to update the same

Next time, the list will probably be updated for adding support for Supplement 204 (see DCMTK Conformance #792). As far as I know (I'm not the author of this part of the DCMTK), the list of supported ciphersuites is not updated regularly but only if there is a need (e.g. in order to reflect changes in the DICOM standard) or if someone comes up with a patch. I will also ask the DCMTK team member who originally added support for TLS to the toolkit to have a look at this thread.


Top
 Profile  
 
PostPosted: Tue, 2018-02-13, 10:24 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Tue, 2004-11-02, 17:22
Posts: 1215
Location: Oldenburg, Germany
In order to add support for a specific TLS ciphersuite in DCMTK, you have to do the following:
  • Make sure that the ciphersuite is supported in the OpenSSL library you compile against (e.g. OpenSSL 1.1.0 needs to be compiled with specific flags to enable 3DES)
  • Add the ciphersuite to the list of known ciphersuites in dcmtls/libsrc/tlslayer.cc
  • Make sure that the tools that initiate/accept the network connection propose/accept the ciphersuite. For example, by default StoreSCP and StoreSCU will only negotiate the two ciphersuites defined in DICOM Part 14. The list of ciphersuites can be modified on the command line using the --cipher command line option.

And yes, I (being the author) agree that it's high time to update the list of ciphersuite, which still reflects a rather ancient OpenSSL release.
Apparently few people use this, and nobody has asked for it in the last couple of years.


Top
 Profile  
 
PostPosted: Thu, 2018-02-15, 17:05 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1963
Location: Oldenburg, Germany
To the OP: DICOM Supplement 204 (currently being Letter Ballot) will introduced exactly these four cipher suites as part of the new "Non-Downgrading BCP195 TLS Profile". Implementing support for it is already on our to-do list.


Top
 Profile  
 
PostPosted: Fri, 2018-02-16, 02:29 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
J. Riesmeier wrote:
To the OP: DICOM Supplement 204 (currently being Letter Ballot) will introduced exactly these four cipher suites as part of the new "Non-Downgrading BCP195 TLS Profile". Implementing support for it is already on our to-do list.


Hi Jörg,

Thanks for the info.
So once in place,
- Best Practices TLS Profile will support old cipher suites (considering backward compatibility).
- Non-Downgrading Best Practices TLS Profile will not support weaker cipher suites.
Please correct me if my understanding is wrong.
Also, is the target version 3.6.4 or later?

Thanks & Regards,
Amal


Last edited by amal.jesudas on Fri, 2018-02-16, 06:07, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri, 2018-02-16, 03:22 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
Marco Eichelberg wrote:
In order to add support for a specific TLS ciphersuite in DCMTK, you have to do the following:
  • Make sure that the ciphersuite is supported in the OpenSSL library you compile against (e.g. OpenSSL 1.1.0 needs to be compiled with specific flags to enable 3DES)
  • Add the ciphersuite to the list of known ciphersuites in dcmtls/libsrc/tlslayer.cc
  • Make sure that the tools that initiate/accept the network connection propose/accept the ciphersuite. For example, by default StoreSCP and StoreSCU will only negotiate the two ciphersuites defined in DICOM Part 14. The list of ciphersuites can be modified on the command line using the --cipher command line option.

And yes, I (being the author) agree that it's high time to update the list of ciphersuite, which still reflects a rather ancient OpenSSL release.
Apparently few people use this, and nobody has asked for it in the last couple of years.


Hi Marco,

Thank you for checking this query.
In-order to support the new cipher suites, I too have followed the same steps as mentioned by you.
I have added the four new cipher suites to the cipher suite list in dcmtls/libsrc/tlslayer.cc.
Also, the ciphers are specified in the command line for store scp and store scu using the +cs(--cipher) option.
I am using 1.0.2n version of Openssl.
Could verify that generated storescu-storescp binaries supports the below cipher suites(required for backward compatibility):
    TLS_RSA_WITH_NULL_SHA
    TLS_RSA_WITH_3DES_EDE_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA


Still, am not able to get the four new cipher suites working.
I checked the openssl support for these cipher suites using the command: openssl ciphers -v -tlsv1
And all four are present in the list as shown below:
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
    DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD

For the new cipher suites I receive the following errors:
SCP side:
E: Receiving Association failed: 0006:031e DUL secure transport layer: unspecified TLS error

SCU side:
E: TLS client handshake failed.
F: Association Request Failed: 0006:o31b Failed to establish association.
F: 0006:0317 Peer aborted Association <or never connected>
F: 0006:031e DUL secure transport layer: no ciphers available


Additionally I tried with latest dcmtk (version 3.6.3) and Openssl v1.0.2n.
The binaries behaved similar and the four new cipher suites still did not work.

Please let me know if I missed a trick or if I am doing something wrong.

Thanks & Regards,
Amal


Top
 Profile  
 
PostPosted: Mon, 2018-02-19, 15:48 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Tue, 2004-11-02, 17:22
Posts: 1215
Location: Oldenburg, Germany
Well, at this point you'll probably have to check things with the debugger. I noticed that the new cipher suites you refer to are TLSv1.2 suites. You should probably check which TLS version is proposed by the client, and which version(s) the server is willing to accept. The error code "unspecified TLS error" means that the error occurs somewhere in the OpenSSL code.


Top
 Profile  
 
PostPosted: Mon, 2018-02-19, 20:02 
Offline

Joined: Tue, 2017-12-19, 11:49
Posts: 11
Marco Eichelberg wrote:
Well, at this point you'll probably have to check things with the debugger. I noticed that the new cipher suites you refer to are TLSv1.2 suites. You should probably check which TLS version is proposed by the client, and which version(s) the server is willing to accept. The error code "unspecified TLS error" means that the error occurs somewhere in the OpenSSL code.


Hi Marco,

My initial impression was also that the error was from OpenSSL code.
Got a bit of help from the OpenSSL forum in GitHub when I mentioned the error being logged.
As per their suggestion, calls to SSL_CTX_set_tmp_dh() and SSL_CTX_set_ecdh_auto() are required on the server.
These calls are required to set the appropriate parameters to use for DHE/ECDHE ciphersuites.
Also, they provided the reason for the difference in behavior for OpenSSL versions 1.1.0f and 1.0.2n, as stated in my post made on Mon, 2018-02-12, 21:41.
According to them, in 1.1.0 ecdh_auto is on by default (and in fact cannot be switched off).
This causes ECDHE cipher suites to work in v1.1.0f.

In dcmtk source, I could see SSL_CTX_set_tmp_dh() being called inside DcmTLSTransportLayer::setTempDHParameters().
However, SSL_CTX_set_ecdh_auto() was not found in code.
Does this mean that as of now ECDHE cipher suites is not supported by dcmtk?
Also, the setTempDHParameters() gets called when +dp(--dhparam) option is used.
Can you confirm if it is mandatory to use +dp option for DHE cipher suites?

Thanks & Regards,
Amal


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group