opt_certVerification

[markw]

Hi,

I'm using storescp with open ssl. Is there a way to accept connections that are encrypted as well as un-encrypted without having to redefine the connection?

I have set the opt_certVerification flag = DCV_checkCertificate. I was hoping this would let connections that were NOT encrypted still pass through ok, while those that are encrypted take advantage of the encryption support.

When trying to connect unencrypted, the returned error from ASC_receiveAssociation() is:

DUL secure transport layer: wrong version number.

Is there anything we can do?

Thanks

[markw]

Any ideas on what we can do with this?

In the worse case, I guess we could have a second listening devicec that is only for encryped connections?

It would really be a lot better if there was a way to allow the listener to support an encrypted connection if that's what the client is requesting, likewise for if they're requesting an un-encrypted connection.

Thanks

[Jörg Riesmeier]

The option opt_certVerification in the dcmnet applications is not about encryption but about the authentication of the communication peer:

Code: Select all

/** this enum describes how to handle X.509 certificates on a TLS based
 *  secure transport connection. They can be ignored, validated if present
 *  or validated and demanded.
 */
enum DcmCertificateVerification
{
  /** check peer certificate, fail if no certificate is present
   */
  DCV_requireCertificate,

  /** check peer certificate if present, succeed if no certificate is present
   */
  DCV_checkCertificate,

  /** do not check peer certificate
   */
  DCV_ignoreCertificate
};

Please note that TLS allows for both encrypted and unencrypted transmission (see ciphersuite options).

[markw]

Hi Jorg,

Ok I see - all I need to be concerned with is creating the TLS layer and then add some cipher suite to it - can you give me some information on how to specify a cipher suite? In the storescp code the command line parser is looking for --cipher and then I suppose a cipher suite name.. what names can we use, where do we get these from?

If I just create the TLS layer, then only add the cipher items (but not certificates, passwords, all that stuff) then the storescp application should be able to accept connections which use the cipher suite encryption, as well as connections that do NOT use the cipher suite encryption, without having to restart with new settings?

Thanks

[Jörg Riesmeier]

The ciphersuite support in DCMTK in documented in the text file "ciphers.txt".

The storescp always requires a certificate and a private key file when using secure TLS connections (see command line options).

[markw]

Hi Jorg,

So there MUST be the certificate/key if we wish to use an encrypted connection?

Then it's not possible for storescp to simultaneously accept encrypted/un-encrypted connections?

If I have storescp running with opt_secureConnection = true, then some device wants to send images to me that does support the TLS layer, I would have to basically shut storescp down, restart with opt_secureConnection = false, right?

I cannot find a way for storescp to accept a connection from storescu if storescp is running with opt_secureConnection = true and storescu is running with opt_secureConnection = false

Thanks

[Jörg Riesmeier]

So there MUST be the certificate/key if we wish to use an encrypted connection?

Yes, this it at least true for the storescp. The storescu also allows for a secure TLS connection without certificate (see option --anonymous-tls / +tla). The latter is similar to https connections to a web server.

Then it's not possible for storescp to simultaneously accept encrypted/un-encrypted connections?

I guess you mean with and without TLS tunneling? To my knowledge, this is only possible on a different port (i.e. running multiple instances of storescp with different options).

[Marco Eichelberg]

Then it's not possible for storescp to simultaneously accept encrypted/un-encrypted connections?

This is not possible indeed, and this was a concious design choice of the DICOM committee. If both secure and conventional DICOM associations could be negotiated over a single port, an attacker could try to coerce SCU and SCP into using the normal mode instead of the TLS-based mode, e.g. by modifying the A-ASSOCIATE-RQ packet that would contain the "request" to switch to TLS mode. By forcing each port to either only accept "normal" DICOM associations or only TLS based associations, this possible attack vector is avoided.

[wlfreefly]

hello,I have something in the Store.the Encrypted connection is set by the item "--cipher",but how I can prove that the data transmitted is encrypted by the method that the item "--cipher" sets?In the document, the item "--cipher" means " add ciphersuite to list of negotiated suites" .