Teiid Server Transport Security

There are two types of direct remote transports, each with it’s own encryption configuration:

  • "teiid" - Defaults to only encrypt login traffic, in which none of the other configuration properties are used.

  • "odbc" - Defaults to no SSL

Example Transport Configuration
            <authentication security-domain="teiid-security"/>
            <transport name="jdbc" socket-binding="teiid-jdbc" protocol="teiid"/>
            <transport name="odbc" socket-binding="teiid-odbc" protocol="pg">
                <ssl mode="disabled"/>
            </transport>
Warning
 The pg protocol for ODBC access defaults to clear text username password authentication. You should consider using a security domain that utilizes non-plaintext passwords, kerberos, or SSL.

SSL configuration is part of the transport configuration in the Teiid subsystem.

Other indirect access into Teiid, such as OData or REST via WARs, relies on the container settings for HTTP/HTTPS access.

Encryption Modes

Teiid supports a couple different encryption modes based on the mode attribute on ssl element.

  • logIn - This is the default setting for the transports.

    • Teiid JDBC (non-data by default) messages between client and server are encrypted using 128 bit AES with a Diffie-Hellman key that is negotiated per connection. When possible a 2048 bit key exchange will be used otherwise 1024 bit will be used. Oracle/Sun 1.7 JREs are known not to support key lengths over 1024 bits. The connection property encryptRequest can be used to encrypt requests and results using the same 128 bit AES scheme. Pre 9.x and unpatched client/server combinations will use a less secure ECB block mode, which is not recommended for large authentication payloads and the encryptRequest option.

    • pg authentication is expected to be secure (see the system property org.teiid.ODBCRequireSecure). However the pg transport does not support just logIn encryption. Thus the server will throw an exception rather than attempting to send a username password authentication request. GSS authentication is allowed though.

  • enabled - Mode to enable SSL. Clients are required to connect using SSL.

  • disabled - turns off any kind of encryption. This is the default for the odbc transport.

SSL Client Authentication Modes

  • anonymous – DEPRECATED No certificates are required, but all communications are still encrypted using the TLS_DH_anon_WITH_AES_128_CBC_SHA SSL cipher suite. In most secure intranet environments anonymous is suitable to just bulk encrypt traffic without the need to setup SSL certificates. No certificates are exchanged, and settings are not needed for the keystore and truststore properties. JDBC Clients must have 'org.teiid.ssl.allowAnon' set to true (the default) to connect to an anonymous server.

Note
 ODBC clients and some VMs, such as IBM, may not have the TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite available. On other VMs it may require modifying the java.security file to enable the anon cipher suites.

When the client or server lack the anonymous cipher suite, consider using server only or 1-way authentication with a self-signed certificate. ODBC clients typically do not require server certificate validation. Teiid JDBC clients by default validate the server certificate, but can use the org.teiid.ssl.trustAll property to accept any server certificate.

This mode is deprecated, as you may set the authentication mode to 1-way and the enabled-cipher-suites to TLS_DH_anon_WITH_AES_128_CBC_SHA for the same effect.

  • NONE, previously known as 1-way, is the default. Only authenticates the server to the client. Requires a private key keystore to be created for the server. If the client is configured to validate the server certificate, the client will need an appropriate truststore configured.

  • NEED, previously known as 2-way, is mutual client and server authentication. The server and client applications each have a keystore for their private keys and each has a truststore that authenticates the other. The server will present a certificate, which is obtained from the keystore related properties. The client should have a truststore configured to accept the server certificate. The client is also required to present a certificate, which is obtained from its keystore. The client certificate should be accepted by the trust store configured by the truststore related properties.

  • WANT – Similar to NEED, but the client is not required to authenticate.

If you have configured the authentication-type to be SSL or expect VDBs to specify an authentication-type of SSL, then you will need to use either the NEED or WANT client authentication modes.

For non-anonymous SSL, the suite is negotiated - see enabled-cipher-suites below below.

Depending upon the SSL mode, follow the guidelines of your organization around creating/obtaining private keys. If you have no organizational requirements, then follow this guide to create self-signed certificates with their respective keystores and truststores. The following keystore and truststore combinations are required for different SSL modes. The names of the files can be chosen by the user. The following files are shown for example purposes only.

For any non-anonymous server configuration, you must supply

  1. server.keystore - has server’s private key

  2. server.truststore - has server’s public key

For NEED or WANT client authentication, a client may also need to provide

  1. client.keystore - client’s private key

  2. client.truststore - has client’s public key

Full Configuration Options

Example XML Configuration
<ssl mode="enabled" authentication-mode="NONE" ssl-protocol="TSLv1" keymanagement-algorithm="algo"
         enabled-cipher-suites="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA">
            <keystore name="cert.keystore" password="passwd" type="JKS" key-alias="alias" key-password="passwd1"/>
            <truststore name="cert.truststore" password="passwd"/>
</ssl>

Properties

  • mode - disabled|login|enabled disabled = no transport or message level security will be used. login = only the login traffic will be encrypted at a message level using 128 bit AES with an ephemeral DH key exchange. Only applies to the teiid transport and no other config values are needed in this mode. enabled = traffic will be secured with SSL using the other configuration properties. teiid transport clients must connect using SSL with the mms protocol. ODBC "pg" transport clients may optionally use SSL.

  • ssl-protocol- Type of SSL protocol to be used. Optional - by default TLSv1.

Caution
 SSLv3 is not recommended due to the POODLE security vulnerability.

  • keystore/type - Keystore type created by the keytool. Optional - by default "JKS" is used.

  • authentication-mode - NONE|NEED|WANT - Type of SSL Client Authentication Mode.

  • keymanagement-algorithm - Type of key algorithm used. Optional - by default is based upon the VM, e.g. "SunX509"

  • keystore/name - The file name of the keystore, which contains the private key of the Server. The file name can be relative resource path available to the Teiid deployer classloader or an absolute file system path. A typical installation would place the keystore file in the conf directory of the profile where Teiid is deployed with a file name relative to the conf path. Typically required for non-anonymous authentication.

  • keystore/password - password for the keystore. Required if the keystore has a password.

  • keystore/key-alias - Alias name for the private key to use. Optional - only needed if there are multiple private keys in the keystore and you need to choose which one to use.

  • keystore/key-password - Alias name for the private key to use. Optional - only needed if the key password is different than the keystore password.

  • truststore/name - This is the truststore containing the public certificate(s) for client keys. Depending upon how you created the keystore and truststores, this may be same file as defined under "keystore/name" property. Required if "authenticationMode" is "WANT" or "NEED".

  • truststore/password - password for the truststore. Required if the truststore has a password.

  • truststore/check-expired - Whether to check for expired client certificates. Default false.

  • enabled-cipher-suites - A comma separated list of cipher suites allowed for encryption between server and client. The values must be valid supported cipher suites otherwise SSL connections will fail. Optional - defaults to all supported cipher suites for the vm.

Alternatively, you can use the CLI to add or modify the transport configuration

/subsystem=teiid/transport=jdbc:write-attribute(name=ssl-mode,value=enabled)
/subsystem=teiid/transport=jdbc:write-attribute(name=ssl-authentication-mode,value=1-way)
/subsystem=teiid/transport=jdbc:write-attribute(name=ssl-ssl-protocol,value=TLSv1)
/subsystem=teiid/transport=jdbc:write-attribute(name=ssl-keymanagement-algorithm,value=SunX509)
/subsystem=teiid/transport=jdbc:write-attribute(name=ssl-enabled-cipher-suites,value="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA")
/subsystem=teiid/transport=jdbc:write-attribute(name=keystore-name,value=ssl-example.keystore)
/subsystem=teiid/transport=jdbc:write-attribute(name=keystore-password,value=redhat)
/subsystem=teiid/transport=jdbc:write-attribute(name=keystore-type,value=JKS)
/subsystem=teiid/transport=jdbc:write-attribute(name=keystore-key-alias,value=teiid)
/subsystem=teiid/transport=jdbc:write-attribute(name=keystore-key-password,value=redhat)
/subsystem=teiid/transport=jdbc:write-attribute(name=truststore-name,value=ssl-example.truststore)
/subsystem=teiid/transport=jdbc:write-attribute(name=truststore-password,value=redhat)
Note
 If you do not like to leave clear text passwords in the configuration file, then you can use WildFly vault mechanism for storing the keystore and truststore passwords. Use the directions defined here https://community.jboss.org/docs/DOC-17248

Encryption Strength

Both anonymous SSL and login only (JDBC specific) encryption are configured to use 128 bit AES encryption by default. By default non-anonymous SSL allow for cipher suite negotiation based upon the default cipher suites supported by the respective Java platforms of the client and server. Users can restrict the cipher suites used by specifying the enabled-cipher-suites property above in the SSL configuration.

Examples

results matching ""

    No results matching ""