Article Katherine Reid · Jul 16, 2019 1m read

There's an easy new way to add certificate authority (CA) certificates to your SSL/TLS configurations on InterSystems IRIS 2019.1 (and 2018.1.2) on Windows and Mac.  You can ask IRIS to use the operating system's certificate store by entering:

%OSCertificateStore

in the field for "File containing Trusted Certificate Authority X.509 certificate(s)".   Here's an image of how to do this in the portal:

And here's a link to the documentation which describes this.  It's in the list of options under "File containing trusted Certificate Authority certificate(s)".

5
4 1817
Article Katherine Reid · Apr 24, 2019 5m read

The %Net.SSH.Session class lets you connect to servers using SSH. It's most commonly used with SFTP, especially in the FTP inbound and outbound adaptors.

In this article, I'm going to give a quick example of how to connect to an SSH server using the class, describe your options for authenticating, and how to debug when things go wrong.

Here's an example of making the connection:

Set SSH = ##class(%Net.SSH.Session).%New()
Set return=SSH.Connect("ftp.intersystems.com")​

This creates a new connection, and then connects to the ftp.intersystems.com SFTP server on the default port. At this point, the client and server have picked encryption algorithms and options, but no user has logged in yet.

Once you're connected, you can choose how to authenticate. There are three methods to choose from:

  • AuthenticateWithUsername
  • AuthenticateWithKeyPair
  • AuthenticateWithKeyboardInteractive

Each of these is a different type of authentication. Here's a brief intro to each type:

AuthenticateWithUsername

This uses a username and password.

AuthenticateWithKeyPair

This uses a pair of public and private keys. The public key must have been pre-loaded on the server, and you must have the matching private key. If the private key is encrypted on disk, you should provide a passphrase to decrypt it in the call to the method. Note: you should never send your private key to anyone else.

The public keys should be in OpenSSH format, and the private keys should be PEM encoded. OpenSSH format looks like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfi2Vq+u0rtt2OC84pyrkq1k7WkrS+s76u3a+2gdD43KQ2Z3vSUUfksymJjp11JBZEpOtBVIAy221UKdc7j7Qk6sUjZaK8LIy+bzDVwMyFWgVvQge7EjdWjrJLBRCDXYML6y1Y25XexThkTWSGyXzGNdr+wfIHYn/mIt0hfvrusauvT/9Wz8K2MGAj4BL7UQZpFJrlXzGmewe6++6cZDQQYi0aztwLK798oc9j0LsccdMpqWrjqoU1uANFhYIuUu/T47TEhT+e6M+KFYK5TR998eJTO25IjdN2Tgw0feXhQFF/nngbol0bA4auSPaZQsgokKK+E+Q/8UtBdetEofuV user@hostname

PEM encoded private keys have a header at the top of the file which looks like this:

-----BEGIN RSA PRIVATE KEY-----

and end with:

-----END RSA PRIVATE KEY-----

AuthenticateWithKeyboardInteractive

This is a new option available in Cache 2018.1 and later. It lets you perform challenge and response authentication. For example, you might ask for the one-time code sent via text message or generated by a Google authenticator app. To use this form of authentication, you will need to write a lambda function to handle the prompts the server sends.

You may see servers using this with just a username and password prompt in a way that looks identical to password authentication to the user. The SSH debugging flags described below can help you determine if you're seeing this.

A final note on authentication: If you're interested in using two forms of authentication for a single connection, make sure you're using Cache 2018.1 or any version of InterSystems IRIS. There are updates in this version to allow the use of multiple forms, such as keypair and username.

What to do when things go wrong...

Common errors you might see include:

Failed getting banner

This might look like:

ERROR #7500: SSH Connect Error '-2146430963': SSH Error [8010100D]: Failed getting banner [FFFFFFFF8010100D] at Session.cpp:231,0

Getting the banner is the first thing an SSH client does. If you're seeing this error, you should verify that you're connecting to the right server and that it is an SFTP server.

For example: if the server is actually an FTPS server, you would see this error. FTPS servers use SSL, not SSH, and therefore don't work with the %Net.SSH.Session class. You can use the %Net.FtpSession class to connect to an FTPS server.

Unable to exchange encryption keys

This error might look like:

ERROR #7500: SSH Connect Error '-2146430971': SSH Error [80101005]: Unable to exchange encryption keys [80101005] at Session.cpp:238,0

This error usually means that the client and server couldn't agree on encryption or MAC algorithms. If you see this, you may need to upgrade either the client or server to add support for new algorithms.

If you're using a version of Cache before 2017.1, I would recommend trying 2017.1 or later. The libssh2 library was upgraded in 2017.1 and added multiple new algorithms.

You can find more details in the logs provided by the debugging flags that I describe below.

Invalid signature for supplied public key

Error [80101013]: Invalid signature for supplied public key, or bad username/public key combination [80101013] at Session.cpp:418

This error can be quite misleading. You'll see this if your server wanted two forms of authentication and you've only provided one. If that's the case, keep going and try the next one! Everything may still work out.

Error -37

You may see messages about error -37. For example, here it is in the debugging log:

[libssh2] 0.369332 Failure Event: -37 - Failed getting banner

Any time error -37 is listed, the operation which failed will be re-tried. This error is not what caused the final failure. Check for other error messages.

The SSH debuging flags

Detailed logging for SSH connections can be enabled for a connection using the SSH debugging flags. The flags are enabled with the SetTraceMethod method. Here's an example of a connection using them:

Set SSH = ##class(%Net.SSH.Session).%New()
Do SSH.SetTraceMask(511,"/tmp/ssh.log")  
Set Status=SSH.Connect("ftp.intersystems.com")​ 

The first argument to SetTraceMask tells it what to collect. It is a decimal representation of bits. 511 asks for all the bits except for 512, and is the most commonly used setting. If you'd like to know more about each bit, they are listed in the class documentation for the %Net.SSH.Session class.

The second argument tells it what file to put the logging information about the connection in. In this example, I used the file /tmp/ssh.log, but you can enter any absolute or relative path you want to use.

In the example above, I've only run the Connect method. If your problem is in the authentication, you'll need to run the appropriate authentication method as well.

Once you've run your test, you can check the log file for information. If you're not sure how to interpret the log file, the WRC can help.

4
1 6626
Article Katherine Reid · Dec 6, 2016 7m read

When using Studio, ODBC or a terminal connection to Caché or Ensemble, you may have wondered how to secure the connection. One option is to add TLS (aka SSL) to your connection. The Caché client applications - TELNET, ODBC and Studio - all understand how to add TLS to the connection. They just need to be configured to do it.

Configuring these clients is easier in 2015.1 and later. I'm going to be discussing this new method. If you're already using the old, legacy method, it will continue to work, but I would recommend you consider switching to the new one.

Background

These client applications can be installed on a machine which does not have the server install. They can't depend on having access to the normal places to store settings, such as the CACHESYS database or cpf file. Instead, their settings for which certificates or protocols to accept are stored in a text file. Many of the settings in this file are similar to settings in an SSL/TLS configuration in the management portal.

Where is the settings file?

You will have to create your own file. The client installer doesn't create one for you.

By default the settings file is called SSLDefs.ini and should be put in the InterSystems\Cache directory under the directory for 32-bit common program files. This directory is found in the Windows environment variable CommonProgramFiles(x86) on 64-bit Windows or CommonProgramFiles on 32-bit Windows.

For example, on Windows 8.1, the default file would be:

C:\Program Files (x86)\Common Files\InterSystems\Cache\SSLdefs.ini

If you would like to change this, you will have to tell the client executables where to find the settings file. You can do this by defining the environment variable ISC_SSLconfigurations and setting it to the entire path and file name of your file. You may need administrator permissions to do this.

What's in the settings file?

The file has two types of sections. The first type matches connections with TLS configurations. For example, it might tell Studio to use the section named "Default Settings" to find its TLS parameters when connecting to development.intersystems.com.

The second type defines the TLS settings to use for the connection. For example, these would define what Certificate Authority to expect the server's certificate to be signed by. The settings in these sections are very similar to the settings in an SSL/TLS configuration on a Caché or Ensemble server.

The first type of section looks like this:

[Development Server]
Address=10.100.0.17
Port=1972
TelnetPort=23​
SSLConfig=DefaultSettings​

The name in brackets can be anything you want. It's only there to make it easier for you to keep track of which connection this is.

The Address, Port, and TelnetPort settings are used to decide which connections should match this section. Either IP addresses or DNS names can be used for the address on 2016.1 or later clients. Both the address and either the Port or TelnetPort must match where the client application is connecting to in order for the configuration to be used.

The final parameter (SSLConfig) is the name of the configuration to get TLS settings from. It needs to match the name of one of the configurations in the file.

The second type of section looks like this:

[DefaultSettings]
VerifyPeer=2
VerifyHost=1
CAfile=c:\InterSystems\certificates\CAcert.pem
CertFile=c:\InterSystems\certificates\ClientCert.pem
KeyFile=c:\InterSystems\certificates\ClientKey.key
Password=
KeyType=2
Protocols=24
CipherList=ALL:!aNULL:!eNULL:!EXP:!SSLv2 

The name of the section is listed on the first line: [DefaultSettings] and matches the name listed in the SSLConfig parameter of the example first section above. Therefore, this config will be used for connections to the 10.100.0.17 server on port 1972 or port 23.

Using copy and paste on the example above often causes non-printing characters in your text file. Please make sure you have removed any extra characters, for example, by saving the file as text only and re-opening it.

Here's a description of what the parameters mean:

  • VerifyPeer

    Options for this are 0=none, 1=request, and 2=require. Require is the recommended value. If you choose none, it is possible for a malicious server to pretend to be the server you mean to connect to. If you choose require, you'll need to fill in a Certificate Authority that you trust to verify certificates for the CAFile value. This is the equivalent of "Server certificate verification" in the portal. (Note: request doesn't make sense for a client configuration, but I've included it here so you can understand why the options are 0 and 2.)

  • VerifyHost

Options for this are 0=none, 1=required. This option checks that the server's certificate lists the host name or IP you've asked to connect to in the Subject's Common Name or subjectAlternativeName fields. This field does not have an equivalent in the portal, but is the same type of check as the SSLCheckServerIdentity property of the %Net.HttpRequest class. It is only configurable if your client is using Caché / Ensemble 2018.1 or later, or any version of InterSystems IRIS Data Platform.

  • CAfile

    The path to the trusted Certificate Authority (CA) file. This should be the CA that signed the certificate of the other side (the server), not your own certificate. This should be filled in if you have picked a VerifyPeer value of 2. This is the equivalent of "File containing trusted Certificate Authority certificate(s)" in the portal. Certificates must be in PEM format.

  • CertFile

    The path to your own certificate. This should be blank if your client doesn't have one. This is the equivalent of "File containing this client's certificate" in the portal. Certificates must be in PEM format.

  • KeyFile

    The path to the matching private key for CertFile. This should be filled in if you have a CertFile, and blank if you don't. This is the equivalent of "File containing associated private key" in the portal.

  • Password

    The password needed to decrypt your private key. This should be blank if you're not using a certificate for this client, or if the certificate's private key is not encrypted on disk.

  • KeyType

    Is your private key RSA (2) or DSA (1)? The value is only relevant for configurations which have CertFile and KeyFile set. If you're not sure which it is, your key is probably RSA.

  • Protocols

    This is a decimal representation of bit values for the versions of SSL/TLS supported. The options are: 1=SSLv2, 2=SSLv3, 4=TLSv1, 8=TLSv1.1, 16=TLSv1.2. SSLv2 and SSLv3 have known problems and are not recommended. More than one version may be specfied by adding numbers. For example, 24 is TLSv1.1 and TLSv1.2. This the equivalent of the "Protocols" checkboxes in the portal. (Note: the 8 and 16 bits aren't in 2015.1. If you want to use them, you need to upgrade to 2015.2 or higher.)

  • CipherList

    This is the equivalent of "Enabled ciphersuites" in the portal. This controls exactly which types of encryption and hashing will be acceptable to this client. ALL:!aNULL:!eNULL:!EXP:!SSLv2 is the default value for this setting in the management portal. If you're having trouble with your connection, it's probably not this. Changing this can make your connection less secure by allowing weak encryption. You can find more information about this value on the openssl website.

Final notes

That's all you need to do! If you create your file and put it in the known location, it will automatically be used if the name or IP address and port you're connecting to match one of the connections listed in the file.

Server setup

This article is about how to configure the client side of your connection to use SSL, but don't forget that the server you're connecting to also needs to understand how to accept SSL. The documentation on setting the SuperServer to use SSL can be found here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_superserver

And the documentation configuring the Telnet service is here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_telnet_svr

The $SYSTEM.Security.Users.SetTelnetSSLSetting() method allows you to control whether the Telnet server allows or requires SSL to be used. It is available in 2016.1 and later.

DSN configuration

You do not need to change the DSN for an ODBC connection as long as you have a matching connection address and port in your settings file. SSL will be used even if Password is selected for the authentication method in the DSN. The Password with SSL/TLS and SSL/TLS server name options were for the pre-2015.1 style of configuring SSL for ODBC.

Documentation link

Documentation on TLS for client applications is now available on the IRIS docs site:

https://irisdocs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_windotinifile

7
4 6168
Article Katherine Reid · Aug 26, 2016 2m read

Question:

What version of Caché supports TLS v1.2? 

Answer:

Caché 2015.2 announced support for TLS v1.1 and v1.2.  In this version, the SSL/TLS configuration page provides checkboxes for TLS v1.1 and v1.2, which allows the versions to be configured individually.  This allows sites to, for example, require TLS v1.2 only.

Additionally, some earlier versions of Caché provide undocumented support for TLS v1.1 and v1.2, specifically Caché 2014.1.3 and above and 2015.1, on Windows, Linux and Unix.

1
0 2415