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.

    • 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.

    • pg authentication is expected to be secure - which currently is only GSS logins. 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.

  • 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 Authentication Modes

  • anonymous – 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. When the client or server lack the anonymous cipher suite, consider using 1-way 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.

  • 1-way – 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.

  • 2-way – 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 expected 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.

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.

1-way

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

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

2-way

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

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

  3. client.keystore - client’s private key

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

Full Configuration Options

Example XML Configuration
<ssl mode="enabled" authentication-mode="1-way" 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 - diabled|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 - anonymous|1-way|2-way, Type of SSL 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 if 1-way or 2-way authentication is used.

  • 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 "2-way".

  • 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 1-way and 2-way 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 ""