Encryption

Encryption in transit

All network traffic between the clients and GraphDB and between the different GraphDB nodes (in case of a cluster topology) can be performed over either HTTP or HTTPS protocols. It is highly advisable to encrypt the traffic with SSL/TLS because it has numerous security benefits.

Configuring GraphDB instance with SSL

As GraphDB runs on embedded Tomcat server, the security configuration is standard with a few exceptions. See more in the official Tomcat documentation on how to enable SSL/TLS.

SSL can be enabled by configuring the following three parameters:

graphdb.connector.SSLEnabled = true
graphdb.connector.scheme = https
graphdb.connector.secure = true

GraphDB uses the Java implementation of SSL, which requires a configured key in the Java keystore.

graphdb.connector.keystoreFile = <path to the keystore file>
graphdb.connector.keystorePass = <secret>
graphdb.connector.keyAlias = graphdb
graphdb.connector.keyPass = <secret>

If you have no Java keystore, you can generate one by using one of the following methods:

Option one - generate a self-signed key. You would have to trust the certificate in all clients, including all nodes that run in a different JVM.

$ keytool -genkey -alias graphdb -keyalg RSA -keystore \path\to\my\keystore

Option two - convert a third party trusted OpenSSL certificate to PKCS12 key and then import to the Java keystore.

openssl pkcs12 -export -in mycert.crt -inkey mykey.key
               -out mycert.p12 -name tomcat -CAfile myCA.crt
               -caname root -chain

For any additional encryption information, please refer to the Encryption section or, since GraphDB runs in an embedded Tomcat, to the Tomcat ssl documentation.

In addition to the above settings, you can set any Tomcat Connector attribute through a property:

graphdb.connector.<attribute> = xxx

Currently, GraphDB does not support configuration of the SSLHostConfig part of the Tomcat configuration. So when configuring SSL, please refer to the Connector attributes and not the SSLHostConfig ones. See the Tomcat attributes documentation for more information.

Certificate trust

After configuring the GraphDB instance with SSL, certificate trust should be set up between the GraphDB node and all client nodes communicating with it. Certificate trust can be provided in one of two ways:

Use certificates signed by a trusted Certification Authority

This way, you will not need any additional configuration and the clients will not get security warning when connecting to the server. The drawback is that these certificates are usually not free and you need to work with a third-party CA. We will not look at this option in more detail as creating such a certificate is highly dependent on the CA.

Use self-signed certificates

The benefit is that you generate these certificates yourself and they do not need to be signed by anyone else. However, the drawback is that by default, the nodes will not trust each others’ certificates.

If you generate a separate self-signed certificate for each node in the communication, this certificate would have to be present in the Java Truststores of all other nodes. You can do this by either adding the certificate to the default Java Truststore or specifying an additional Truststore when running GraphDB. Information on how to generate a certificate, add it to a Truststore, and make the JVM use this Truststore can be found in the official Java documentation.

However, this method introduces a lot of configuration overhead. Therefore, we recommend that instead of separate certificates for each node, you generate a single self-signed certificate and use it on all nodes. GraphDB extends the standard Java TrustManager, so it will automatically trust its own certificate. This means that if all nodes involved in the communication are using a shared certificate, there would be no need to add it to the Truststore.

Another difference from the standard Java TrustManager is that GraphDB has the option to disregard the hostname when validating the certificates. If this option is disabled, it is recommended to add all possible IPs and DNS names of all nodes that will be using the certificate as Subject Alternative Names when generating the certificate (wildcards can be used as well).

Both options for trusting your own certificate and skipping the hostname validation are configurable from the graphdb.properties file:

• graphdb.http.client.ssl.ignore.hostname - false by default

• graphdb.http.client.ssl.trust.own.certificate - true by default

Encryption at rest

GraphDB does not provide encryption for its data. All indexes and entities are stored in binary format on the hard drive. It should be noted that the data from them can be easily extracted in case somebody gains access to the data directory.

This is why it is recommended to implement some kind of disk encryption on your GraphDB server. There are multiple third-party solutions that can be used.

GraphDB has been tested on LUKS-encrypted hard drive, and no noticeable performance impact has been observed. However, please keep in mind that such may be present, as it is highly dependent on your specific use case.