SSL is an industry standard for sending wire- or socket-level encrypted data over client-to-server and server-to-server connections. Before the SSL connection is established, the server and the client exchange a series of I/O round trips to negotiate and agree upon a secure encrypted session. This is called the SSL handshake.
When a client application requests a connection, the SSL-enabled server presents its certificate to prove its identity before data is transmitted. Essentially, the SSL handshake consists of the following steps:
The client sends a connection request to the server. The request includes the SSL (or Transport Layer Security, TLS) options that the client supports.
The server returns its certificate and a list of supported CipherSuites, which includes SSL/TLS support options, the algorithms used for key exchange, and digital signatures.
A secure, encrypted session is established when both client and server have agreed upon a CipherSuite.
For more specific information about the SSL handshake and the SSL/TLS protocol, see the Internet Engineering Task Force Web site http://www.ietf.org.
SSL provides several levels of security.
When establishing a connection to an SSL-enabled server, the server authenticates itself—proves that it is the server you intended to contact—and an encrypted SSL session begins before any data is transmitted.
Once the SSL session is established, user name and password are transmitted over a secure, encrypted connection.
A comparison of the server certificate’s digital signature can determine if any information received from the server was modified in transit.
When establishing a connection to an SSL-enabled Adaptive Server Enterprise, the SSL security mechanism is specified as a filter on the master and query lines in the interfaces file (sql.ini on Windows). SSL is used as an Open Client and Open Server protocol layer that sits on top of the TCP/IP connection.
The SSL filter is different from other security mechanisms, such as DCE and Kerberos, which are defined with SECHMECH (security mechanism) lines in the interfaces file (sql.ini on Windows). The master and query lines determine the security protocols that are enforced for the connection.
For example, a typical interfaces file on a UNIX machine using SSL looks like this:
[SERVER]
query tcp ether hostname, port ssl
master tcp ether hostname, port ssl
A typical sql.ini file on Windows using SSL looks like this:
[SERVER]
query=TCP,hostname, port, ssl
master=TCP,hostname, port, ssl
where hostname is the name of the server to which the client is connecting and port is the port number of the host machine. All connection attempts to a master or query entry in the interfaces file with an SSL filter must support the SSL protocol. A server can be configured to accept SSL connections and have other connections that accept plain text (unencrypted data), or use other security mechanisms.
For example, an Adaptive Server Enterprise interfaces file on UNIX that supports both SSL-based connections and plain-text connections looks like:
SYBSRV1 master tcp ether hostname 2748 ssl query tcp ether hostname 2748 ssl master tcp ether hostname 2749
In this examples, the SSL security service is specified on port number 2748. On SYBSRV1, Adaptive Server Enterprise listens for clear text on port number 2749, which is without any security mechanism or security filter.
Any Open Client and Open Server connection to an SSL-enabled server requires that the server have a certificate file, which consists of the server’s certificate and an encrypted private key. The certificate must also be digitally signed by a CA.
Open Client applications establish a socket connection to Adaptive Server Enterprise similarly to the way that existing client connections are established. Before any user data is transmitted, an SSL handshake occurs on the socket when the network transport-level connect call completes on the client side and the accept call completes on the server side.
To make a successful connection to an SSL-enabled server:
The SSL-enabled server must present its certificate when the client application makes a connection request.
The client application must recognize the CA that signed the certificate. A list of all “trusted” CAs is in the trusted roots file. See “The trusted roots file”.
For connections to SSL-enabled servers, the default behavior is to compare the common name in the server’s certificate with the server name in the interfaces file. In Shared Disk Cluster (SDC) environment, a client may specify the SSL certificate common name independent of the server name or the SDC instance name. For information about common name validation in an SDC environment see “Common name validation in an SDC environment”.
When establishing a connection to an SSL-enabled Adaptive Server Enterprise, Adaptive Server Enterprise loads its own encoded certificates file at start-up from:
UNIX – $SYBASE/$SYBASE_ASE/certificates/servername.crt
Windows – %SYBASE%\%SYBASE_ASE%\certificates\servername.crt
where servername is the name of the Adaptive Server Enterprise as specified on the command line when starting the server with the -S flag or from the server’s environment variable $DSLISTEN.
Other types of servers may store their certificate in a different location. See the vendor-supplied documentation for the location of your server’s certificate.
The default behavior for SSL validation in Open Client and Open Server is to compare the common name in the server’s certificate with the server name specified by ct_connect(). In a Shared Disk Cluster (SDC) environment, a client may specify the SSL certificate common name independent of the server name or the SDC instance name. A client may connect to an SDC by its cluster name—which represents multiple server instances—or to a specific server instance.
Because the client can use the transport address to specify the common name used in the certificate validation, the Adaptive Server Enterprise SSL certificate common name can be different from the server or cluster name. The transport address can be specified in one of the directory services like the interfaces file, LDAP or NT registry, or through the connection property CS_SERVERADDR.
This is the syntax of the server entries for the SSL-enabled Adaptive Server Enterprise and cluster for UNIX:
CLUSTERSSL query tcp ether hostname1 5000 ssl="CN=name1" query tcp ether hostname2 5000 ssl="CN=name2" query tcp ether hostname3 5000 ssl="CN=name3" query tcp ether hostname4 5000 ssl="CN=name4" ASESSL1 master tcp ether hostname1 5000 ssl="CN=name1" query tcp ether hostname1 5000 ssl="CN=name1" ASESSL2 master tcp ether hostname2 5000 ssl="CN=name2" query tcp ether hostname2 5000 ssl="CN=name2" ASESSL3 master tcp ether hostname3 5000 ssl="CN=name3" query tcp ether hostname3 5000 ssl="CN=name3" ASESSL4 master tcp ether hostname1 5000 ssl="CN=name4" query tcp ether hostname1 5000 ssl="CN=name4"
This is the syntax of the server entries for the SSL-enabled Adaptive Server Enterprise and cluster for Windows:
[CLUSTERSSL] query=tcp,hostname1,5000, ssl="CN=name1" query=tcp,hostname2,5000, ssl="CN=name2" query=tcp,hostname3,5000, ssl="CN=name3" query=tcp,hostname4,5000, ssl="CN=name4" [ASESSL1] master=tcp,hostname1,5000, ssl="CN=name1" query=tcp,hostname1,5000, ssl="CN=name1" [ASESSL2] master=tcp,hostname2,5000, ssl="CN=name2" query=tcp,hostname2,5000, ssl="CN=name2" [ASESSL3] master=tcp,hostname3,5000, ssl="CN=name3" query=tcp,hostname3,5000, ssl"CN=name3" [ASESSL4] master=tcp,hostname4,5000, ssl="CN=name4" query=tcp,hostname4,5000, ssl="CN=name4"
The list of known and trusted CAs is maintained in the trusted roots file. The trusted roots file is similar in format to a certificate file, except that it contains certificates for CAs known to the entity (client applications, servers, network resources, and so on). The System Security Officer adds and deletes CAs using a standard ASCII-text editor.
The trusted roots file for Open Client and Open Server is located in:
UNIX – $SYBASE/$SYBASE_OCS/config/trusted.txt
Windows – %SYBASE%\%SYBASE_OCS%\ini\trusted.txt
Currently, the recognized CAs are Thawte, Entrust, Baltimore, VeriSign and RSA.
By default, Adaptive Server Enterprise stores its own trusted roots file in:
UNIX – $SYBASE/$SYBASE_ASE/certificates/servername.txt
Windows – %SYBASE%\%SYBASE_ASE%\certificates\servername.txt
Both Open Client and Open Server allow you to specify an alternate location for the trusted roots file:
Open Client:
ct_con_props (connection, CS_SET, CS_PROP_SSL_CA, “$SYBASE/config/trusted.txt”, CS_NULLTERM, NULL);
where $SYBASE is the installation directory. CS_PROP_SSL_CA can be set at the context level using ct_config(), or at the connection level using ct_con_props().
Open Server:
srv_props (context, CS_SET, SRV_S_CERT_AUTH, “$SYBASE/config/trusted.txt”, CS_NULLTERM, NULL);
where $SYBASE is the installation directory.
bcp and isql utilities also allow you to specify an alternative location for the trusted roots file.The parameter -x is included in the syntax, allowing you to specify an alternative location for the trusted.txt file.
For a description of SSL and public-key cryptography, see the Open Client Client-Library Reference Manual.