SSL overview

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.

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, 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 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 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 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 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 ASE 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 ASE 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 ASE 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 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.