Secure Sockets Layer and Oracle 11g Security

Much
of the communication between client and server, in an Oracle environment, is
unsecured and clear-text. With Oracle Advanced Security and Secure Sockets
Layer, network traffic and communication between user and database can become
more secured.

Secure Sockets Layer (SSL) is a cryptographic protocol
that provides security for communication over the network by encrypting
segments of network connections at the transport layer end-to-end. The purpose
for SSL is to allow client-server applications to communicate in a secure
fashion across the network—preventing eavesdropping, tampering, and message
spoofing. In Oracle, authentication is supported by using Oracle Advanced Security
with digital certificates over SSL as well as additional capabilities of these
products. The use of Oracle Advanced Security over SSL helps secure
communications in a client-server environment by encryption between a client
and server as well as authenticating the client or server.

To work in an Oracle environment there is a SSL handshake
between client and server that validates authentication and includes the
following steps:

1. 
Client and
server determine which cipher suite is being used. A cipher suite is just a set
of authentication, encryption, and data integrity algorithms that will be used
for exchanging messages back and forth.

2. 
Server will
send a certificate to the client that the client then uses to verify a server’s
identity.

3. 
Client will
send a certificate, if needed, to verify its identity.

4. 
Client and
server exchange key information using a public key, which will generate a
session key that will be used for encryption between client and server for the
duration of the communication session.

5. 
When a
handshake is successful the server will verify a user has appropriate
authorization to access the database.

Within and Oracle environment, Oracle makes use of a
Public Key Infrastructure (PKI) that enables network entities to access
security services. Instead of the traditional private-key or symmetric-key
implementation that is difficult to secure keys, Oracle implements a public-key
cryptography that distributes securely a public and private key pair where a
public key is used to encrypt traffic that can then only be decrypted by a
holder of the private key. This private key is stored with other credentials in
an encrypted container called a wallet. While a public-key may guarantee the
security of a message, it does not guarantee a secure communication between
client and server. To do this, verification of the public-key is done through
an authentication process called certificate authority (CA) which is a third
party trusted by both client and server. To help clarify, here is a brief
explanation of each of the PKI components:

Certificate Authority (CA) – is nothing more than a trusted
third party that issues a digital certificate for use by other parties. By default,
Oracle uses trusted certificates from VeriSign, RSA, Entrust, and GTE
CyberTrust when wallets are created. This third party will certify the identity
of parties, such as a client and server, by granting a signed (CA’s private
key) certificate to a requesting party after verifying identity. For communication
to work, each party, after validating with a CA, will validate that the other
has one of these signed certificates from a CA.

Certificate – is an electronic document, a signed (by a CA) public
key from an entity, which will use a digital signature to ensure an party’s
information is correct and that the public key provided actually belongs to
that party. This certificate will remain valid until it expires or until
revoked.

Certificate Revocation Lists – whenever a CA signs a certificate
that certificate is only valid for a specific period of time. When events
happen that compromise the validity of private keys and thus render a
certificate invalid before the pre-assigned expiration period a CA will revoke
the certificate and add the serial number to a Certificate Revocation List
(CRL). These CRLs are then periodically published by CAs so that the user
community knows when a certain public key is no longer acceptable. For an
Oracle environment, clients and servers will validate the certificate by
checking the expiration date, signature, and this revocation status against
published CRLs if this option has been turned on. CRLs are searched either on
the local file system, Oracle Internet Directory, or a CRL Distribution Point.

Wallets – straight from the Oracle documentation set: a wallet is
a container that will be used to store authentication and signing credentials,
including private keys, certificates, and trusted certificates needed by SSL. In
an Oracle environment, every party that wants to communicate over SSL must have
a wallet containing an X.509 version 3 certificate, private key, and list of
trusted certificates. Wallets are managed by Oracle Wallet Manager on both the
server and client to generate public-private key pairs and create a certificate
request, store a user certificate that matches with the private key, and
configure trusted certificates.

Hardware Security Modules –Oracle Advanced Security can
make use on the server side hardware boxes where keys are stored in the box and
managed by using tokens or on the client side by smart card readers, which
store private keys on tokens. These hardware security modules are then used to
store cryptographic information, perform cryptographic operations through the use
of APIs that conform to the RSA Security, Inc., Public-Key Cryptography
Standards (PKCS) #11 specification.

Much of the communication between client and server, in an
Oracle environment, is unsecured and clear-text. With Oracle’s Advanced
Security and Secure Sockets Layer, the same networking protocol that Web
servers used when protecting transactions can be employed to secure network
traffic. With any add-on, and adding on the SSL protocol is no different, there
is a price to pay in the way of responsiveness and encryption, decryption, and
certificate handling does require additional CPU cycles. However, if you need
to secure traffic between users and database, SSL might be the way to go. While
this article has introduced the basics and hopefully given you an idea of the
components for SSL, the next article will provide a step-by-step setup of SSL
in an Oracle environment.

»


See All Articles by Columnist
James Koopmann

James Koopmann
James Koopmann
James Koopmann has fourteen years of database design, development and performance tuning experience. In addition, he has extensive database administration experience in Oracle and other relational databases in production environments, specializing in performance tuning of database engines and SQL based applications. Koopmann is an accomplished author with several technical papers in various Oracle related publications such as Oracle Magazine, Oracle Professional and SQL>UPDATE_RMOUG. He is a featured author and database expert for DatabaseJournal, a member of the editorial review committee for Select Journal (The Magazine for the International Oracle Users Group), an Oracle Certified Professional DBA and noted speaker at local Oracle User Groups around the country.

Latest Articles