The security of data is of the utmost importance when it comes to using databases. With cyber-attacks becoming increasingly advanced and more frequent, maintaining secure data storage is essential. One way of doing so is through encryption in transit, but this can be challenging to implement because it sometimes requires significant changes to network infrastructure. 

If your organisation uses an Oracle database, however, there is a little-known alternative way of enabling encryption over transit without additional costs or infrastructure requirements. In this blog, we’ll explain both methods and how Oracle users can add a layer of protection to their databases for free. 

What is encryption in transit?

When data is sent from one point to another, encryption plays a vital role in protecting it from malicious actors. Encryption in transit uses different encryption techniques to make data unreadable before transmission, for example between a database and an application or website, and decrypts it after arrival. That way, organisations can make sure that no unauthorized person can access or read sensitive content by “sniffing” the traffic and intercepting data packages. Most organisations focus on securing their data when it is stored (encryption at rest), but it is highly recommended to secure database messages as well. 

Assume perform following SQL Statement:

If we have no encryption in transit, we’ll be able to see the data if we intercept the data packages (between the database and the client):

This changes with Encryption in transit is enabled. Now the data is unreadable and encrypted:

Which encryption in transit options are there?

There are two ways of making sure that your sensitive data stays protected, even during transit. All databases can use the TCPS protocol to encrypt messages, but this has some drawbacks. However, Oracle databases feature a built-in set of parameters to enable encryption in transit effortlessly.

Option 1: TCPS protocol (for all databases)

The first option is to use the TCPS protocol instead of TCP for your network communications. You can compare this to using HTTPS instead of HTTP, but taking it one step further. TCPS offers an even higher level of security since it encrypts the entire data stream. The TCPS protocol also provides improved reliability by verifying the integrity of packets, ensuring that messages are delivered successfully and in the correct order. 

However, there are some drawbacks to using the TCPS protocol to encrypt your communication. TCPS can only protect communications through a local network, so any outgoing data will not have the same level of protection. It also requires compatible hardware: every router, switch, and other piece of network infrastructure will have to support the protocol in order for it to work. Finally, organisations wanting to use TCPS will have to purchase and maintain additional certificates. Activating TCPS doesn’t have to be an expensive and extensive project, but for most companies, it will be. 

Option 2: native encryption (for Oracle databases)

For organisations using Oracle databases, there is another encryption in transit option that requires far less effort to set up. Most companies might not be aware of this, but you can use a configuration file for both the Standard Edition and Enterprise Edition to enable native network encryption at no additional cost and without additional licenses or the need to maintain certificates. 

How to enable native encryption in transit for Oracle databases

To activate native encryption in an Oracle database, execute the following steps: 

1. Navigate to the sqlnet.ora configuration file in the ORACLE_HOME/network/admin directory. If you are unable to locate this directory, refer to the location set by the TNS_ADMIN environment variable.
2. Adjust the SQLNET.ENCRYPTION_SERVER parameter to one of the following options: 
   1. REQUESTED: if the client allows it, encryption will be enabled.
   2. REQUIRED: encryption will be enabled, and the connection will be refused if the client does not have it enabled. 
   3. ACCEPTED: if the client requires or requests encryption, it will be enabled. This is the default option. 
   4. REJECTED: encryption will be disabled, even if the client allows it.
3. Optional: if required by the parameter value above, adjust the SQLNET.ENCRYPTION_CLIENT parameter accordingly in the client configuration file.
4. Optional: define the type of encryption that will be used in the SQLNET.ENCRYPTION_TYPES_SERVER and SQLNET.ENCRYPTION_TYPES_CLIENT parameters in their respective configuration files. The following values are allowed: 
   1. AES128, AES192, or AES256 
   2. A list of two or more of these values, e.g. (AES192, AES256) 

How to add a checksum verification to Oracle databases

When dealing with especially sensitive data, another level of security may be required. It is possible to add this through a checksum verification. This is a cryptographic process that involves creating a digital fingerprint, or checksum, of data and using it to verify that the source data has not been modified. This process can be used to ensure the integrity of transferred data by comparing the original checksum with one created from the received data. If the two match, we can assume that the transmission was successful, and no alterations have been made. 

To activate checksum verification in an Oracle database, execute the following steps: 

1. Navigate to the sqlnet.ora configuration file in the ORACLE_HOME/network/admin directory. If you are unable to locate this directory, refer to the location set by the TNS_ADMIN environment variable.
2. Adjust the SQLNET.CRYPTO_CHECKSUM_SERVER parameter to one of the following options: 
   1. REQUESTED: if the client allows it, checksum verification will be enabled. 
   2. REQUIRED: checksum verification will be enabled, and the connection will be refused if the client does not have it enabled. 
   3. ACCEPTED: if the client requires or requests checksum verification, it will be enabled. This is the default option. 
   4. REJECTED: checksum verification will be disabled, even if the client allows it.
3. Optional: if required by the parameter value above, adjust the SQLNET.CRYPTO_CHECKSUM_CLIENT parameter accordingly in the client configuration file.
4. Optional: define the type of checksum verification that will be used in the SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER and SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT parameters in their respective configuration files. The following values are allowed: 
   1. SHA512 
   2. SHA384 
   3. SHA256 
   4. SHA1 
   5. MD5 (deprecated) 

No encryption:

To Enable Encryption in Transit:

Closing thoughts and remarks

The native encryption and checksum verification features described above are certainly convenient when it comes to adding a layer of security to an enterprise network, but they are not a silver bullet solution. Security features are never completely immune to vulnerabilities, and network encryption does not protect from attacks coming from the inside. It is therefore advised to keep an eye out for any irregularities on all traffic and attacks such as server impersonations. 

When analysing and troubleshooting traffic, keep in mind that the tracing functionality will still work as intended, albeit with encrypted content. In rare cases where it is necessary to verify if certain statements are the cause of an issue, disabling the native encryption and checksum verification features is as simple as reverting the parameters. 

If you have any remaining questions or require assistance in protecting your databases, feel free to reach out. At Monin, our database experts combine their decades of experience to provide you with the best possible solution and ease of mind through our database security audit and other services.