1. Introduction to Altibase SSL/TLS#
This chapter describes the concepts and features of Altibase SSL/TLS.
What is SSL/TLS?#
This chapter introduces the basic concepts of Altibase SSL/TLS.
Introduction to SSL/TLS Protocols#
Secure Sockets Layer (SSL) is the de facto standard network security protocol originally developed by Netscape Communications Corporation.
SSL 1.0 was not publicly released. A bug-ridden 2.0 was released and followed by a completely redesigned 3.0 in 1996. Afterwards, the Internet Engineering Task Force (IETF) released TLS 1.0, which was an upgrade of 3.0 defined in RFC 2246. For further information about the TLS protocol, please refer to 'RFC-2246 The TLS Protocol'.
Cryptography and Certificates#
Symmetric-key algorithms have two or more parties share a single secret key to ensure communication security. This secret key encrypts plaintext and decrypts ciphertext with an efficient algorithm. However, it is difficult for the communicating parties to safely exchange the secret key.
Asymmetric cryptography (also called public-key cryptography) was introduced thereupon. It uses a mathematically linked key pair of one public key and one private key. A message encrypted by a freely accessible public key can only be decrypted by the owner of the matching private key and vice versa.
One party encrypts the secret key with the counterparty's public key and sends it to the counterparty (the holder of the corresponding private key). The counterparty then decrypts the secret key with its own private key. Afterwards the communicating parties can safely communicate by encrypting and decrypting.
However, a man-in-the-middle (MITM) attacker can pretend to be both server and client. It is possible that a request for a public key is intercepted and the attacker's public key is sent, instead of the legitimate one.
Public key ownership can be verified with a public key certificate (a digital certificate signed by an official certificate authority (CA) trusted by both parties). In an opened-system environment such as the World Wide Web (WWW), it is important to use public certificates for communication security. On the contrary, a private certificate is a certificate generated and signed by a non-official CA. Private certificates are useful in a closed-system environment because they are free to use and can be generated whenever necessary.
Secure Communication in Altibase#
Altibase adopts SSL/TLS using symmetric-key algorithms to encrypt/decrypt data, and asymmetric cryptography to safely exchange the shared key and public/private key pair for authentication.
When a network connection over SSL is initiated, Altibase and its client perform an SSL handshake as below:
- The client and server exchange their information (e.g., SSL version, cipher setting and so on) to set up a secure connection environment.
- If the server authentication is required, the server sends the client its own certificate and the client verifies server identity with it.
- If the server requests for the client's certificate, the client also sends the server its own certificate and the server verifies client identity with it.
- The client and server exchange key information with public key cryptography and generate a session key to encrypt/decrypt data and validate data integrity.
- The client and server communicate to each other that the future message will be encrypted with the session key and that the handshake is finished.
SSL Characteristics in Altibase#
The following list of features are the SSL characteristics when using Altibase with SSL communication:
-
Altibase uses the TLS 1.0, 1.2, and 1.3 protocols supported by the OpenSSL library.
-
Altibase supports server-only authentication and mutual authentication.
- Server-only authentication: Only the server authenticates itself to the client.
- Mutual authentication: Both server and client concurrently authenticate themselves to each other
-
An additional network port such as port 443 for HTTPS (other than the one that was used) is required to use SSL connections within Altibase. This is because Altibase does not allow a connection switch from non-secure to secure in TCP connections.
-
To establish a secure connection, client applications need to be implemented with Java Secure Socket Extension (JSSE) API, which is integrated into Java 1.8 or later. JSSE provides a framework and implementation for a Java version of SSL 2.0, 3.0, and TLS 1.0, 1.2, and 1.3 protocols as well as data encryption, server authentication, message integrity, and optional client authentication.
-
Altibase provides the JDBC and ODBC interfaces for SSL connection, which is currently supported only in Intel-Linux.