Open Client Client-Library/C Reference Manual

Home

Open Client Client-Library/C Reference Manual

Chapter 2 Topics

Security features

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.

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 .

Performance

There is additional overhead required to establish a secure session, because data increases in size when it is encrypted, and it requires additional computation to encrypt or decrypt information. Typically, the additional I/O accrued during the SSL handshake may make user login 10- to 20-times slower.

CipherSuites

During the SSL handshake, the client and server negotiate a common security protocol via a CipherSuite. CipherSuites are preferential lists of key-exchange algorithms, hashing methods, and encryption methods used by the SSL protocol

. For a complete description of CipherSuites, go to the IETF organization Web site .

By default, the strongest CipherSuite supported by both the client and the server is the CipherSuite that is used for the SSL-based session.

Server connection attributes are specified with directory services, such as LDAP or DCE, or with the traditional Sybase interfaces file.

The CipherSuites listed below conform to the TLS specification. TLS, or Transport Layer Security, is an enhanced version of SSL 3.0, and is an alias for the SSL version 3.0 CipherSuites.

Open Client/Open Server and Adaptive Server support the CipherSuites that are available with the SSL Plus(TM) library API and the cryptographic engine, Security Builder(TM), both from Certicom Corp.

From strongest to weakest, the supported CipherSuites in Open Client/Open Server 12.5 include:

TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_MD5,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_RC4_128_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_DES_CBC_SHA,
TLS_DHE_DSS_WITH_DES_CBC_SHA,
TLS_DHE_RSA_WITH_DES_CBC_SHA,
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA,
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA,
TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA,
TLS_RSA_EXPORT_WITH_RC4_40_MD5,
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

SSL in Open Client/Open Server

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.

SSL filter

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/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 transport layer interface (tli) and SSL looks like this:

SERVER <retries><time-outs>

     query tli tcp /dev/tcp
tli_add1 ssl

 
   master tli tcp /dev/tcp tli_add1 ssl

A typical sql.ini file on Windows NT using SSL looks like this:

[SERVER]

query=TCP,hostname,address1, ssl

master=TCP,hostname,address1, ssl

where hostname is the name of the server to which the client is connecting and address1 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 tli tcp /dev/tcp \x00020abc123456780000000000000000 ssl
    query tli tcp /dev/tcp \x00020abc123456780000000000000000 ssl
    master tli tcp /dev/tcp \x00020abd123456780000000000000000

Or, the same entry with the new style of Sybase interfaces file on UNIX looks like:

SYBSRV1
    master tli tcp hostname 2748 ssl
    query tli tcp hostname 2748 ssl
    master tli tcp hostname 2749

An example of a socket-style interfaces file looks like:

SYBSRV1
    master tcp ether hostname 2748 ssl
    query tcp ether hostname 2748 ssl
    master tcp ether hostname 2749

In these examples, the SSL security service is specified on port number 2748(0x0abc). On SYBSRV1, Adaptive Server listens for clear text on port number 2749(0x0abd), which is without any security mechanism or security filter.

Validating the server by its certificate

Any Open Client/ 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 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 common name in the server's certificate must match the server name in the interfaces file as well.

When establishing a connection to an SSL-enabled Adaptive Server, Adaptive Server loads its own encoded certificates file at start-up from:

UNIX - $SYBASE/$SYBASE_ASE/certificates/servername.crt

NT - %SYBASE%\%SYBASE_ASE%\certificates\servername.crt

where servername is the name of the Adaptive Server 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 trusted roots file

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/Open Server is located in:

UNIX - $SYBASE/config/trusted.txt

NT - %SYBASE%\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

NT - %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.

Obtaining a certificate

The System Security Officer installs signed server certificates and private keys in the server. You can get a server certificate by:

Using third-party tools provided with existing public-key infrastructure already deployed in the customer environment.
Using the Sybase certificate request tool in conjunction with a trusted third-party CA.

To obtain a certificate, you must request a certificate from a CA. If you request a certificate from a third-party and that certificate is in PKCS #12 format, use the certpk12 utility to convert the certificate into a format that is understood by Open Client/Open Server.

To test the certificate request tool and to verify that the authentication methods are working on your server, Open Client/Open Server provides a certreq and certauth tool, for testing purposes, that allows you to function as a CA and issue a CA-signed certificate to yourself.

The main steps to creating a certificate for use with a server are:

Generate the certificate request.
Generate the public and private key pair.
Securely store the private key.
Send the certificate request to the CA.
After the CA signs and returns the certificate, append the private key to the certificate.
Store the certificate in the server's installation directory.

Third-party tools to request certificates

Most third-party PKI vendors and some browsers have utilities to generate certificates and private keys. These utilities are typically graphical wizards that prompt you through a series of questions to define a distinguished name and a common name for the certificate.

Follow the instructions provided by the wizard to create certificate requests. Once you receive the signed PKCS #12-format certificate, use certpk12 to generate a certificate file and a private key file. Concatenate the two files into a servername.crt file, where servername is the name of the server, and place it in the server's installation directory. By default, the certficates for Adaptive Server's are stored in $SYBASE/$SYBASE_ASE/certificates.

Using Sybase tools to request and authorize certificates

Sybase provides tools for requesting and authorizing certificates. certreq generates public and private key pairs and certificate requests. certauth converts a server certificate request to a CA-signed certificate.

UNIX - $SYBASE/$SYBASE_OCS/bin
Windows - %SYBASE%\%SYBASE_OCS%\bin

Warning!

Use certauth only for testing purposes. Sybase recommends that you use the services of a commercial CA because it provides protection for the integrity of the root certificate, and because a certificate that is signed by a widely accepted CA facilitates the migration to the use of client certificates for authentication.

Preparing a server's trusted root certificate is a five-step process. Perform all five steps to create a test trusted root certificate so you can verify that you are able to create server certificates. Once you have a test CA certificate (trusted roots certificate) repeat steps three through five to sign server certificates.

Use certreq to request a certificate.
Use certauth to convert the certificate request to a CA self-signed certificate (trusted root certificate).
Use certreq to request a server certificate and private key.
Use certauth to convert the certificate request to a CA-signed server certificate.
Append the private key text to the server certificate and store the certificate in the server's installation directory.

See "Using Sybase tools to request and authorize certificates" for more information.

certauth and certreq are dependent on RSA and DSA algorithms. These tools only work with vendor-supplied crypto modules that use RSA and DSA algorithms to construct the certificate request.

For information on adding, deleting, or viewing server certificates on Adaptive Server, see the System Administration Guide.


	Expand Search