Table of Contents Previous Next
Logo
IceSSL : 42.2 Introduction
Copyright © 2003-2009 ZeroC, Inc.

42.2 Introduction

Security is an important consideration for many distributed applications, both within corporate intranets as well as over untrusted networks, such as the Internet. The ability to protect sensitive information, ensure its integrity, and verify the identities of the communicating parties is essential for developing secure applications. With those goals in mind, Ice includes the IceSSL plugin that provides these capabilities using the Secure Socket Layer (SSL) protocol.1

42.2.1 SSL Overview

SSL is the protocol that enables Web browsers to conduct secure transactions and therefore is one of the most commonly used protocols for secure network communication. You do not need to know the technical details of the SSL protocol in order to use IceSSL successfully (and those details are outside the scope of this text). However, it would be helpful to have a high-level understanding of how the protocol works and the infrastructure required to support it. (For more information on the SSL protocol, see [24].)
SSL provides a secure environment for communication (without sacrificing too much performance) by combining a number of cryptographic techniques:
• public key encryption
• symmetric (shared key) encryption
• message authentication codes
• digital certificates
When a client establishes an SSL connection to a server, a handshake is performed. During a typical handshake, digital certificates that identify the communicating parties are validated, and symmetric keys are exchanged for encrypting the session traffic. Public key encryption, which is too slow to be used for the bulk of a session’s data transfer, is used heavily during the handshaking phase. Once the handshake is complete, SSL uses message authentication codes to ensure data integrity, allowing the client and server to communicate at will with reasonable assurance that their messages are secure.

42.2.2 Public Key Infrastructure

Security requires trust, and public key cryptography by itself does nothing to establish trust. SSL addresses the issue of trust using Public Key Infrastructure (PKI), which binds public keys to identities using certificates. A certificate issuer creates a certificate for an entity, called the subject. The subject is often a person, but it may also be a computer or a specific application. The subject’s identity is represented by a distinguished name, which includes information such as the subject’s name, organization and location. A certificate alone is not sufficient to establish the subject’s identity, however, as anyone can create a certificate for a particular distinguished name.
In order to authenticate a certificate, we need a third-party to guarantee that the certificate belongs to the subject described by the distinguished name. This third party, called a Certificate Authority (CA), expresses this guarantee by using its own private key to sign the subject’s certificate. Combining the CA’s certificate with the subject’s certificate forms a certificate chain that provides SSL with most of the information it needs to authenticate the remote peer. In many cases, the chain contains only the aforementioned two certificates, but it is also possible for the chain to be longer when the root CA issues a certificate that the subject may use to sign other certificates. Regardless of the length of the chain, this scheme can only work if we trust that the root CA has sufficiently verified the identity of the subject before issuing the certificate.
An implementation of the SSL protocol also needs to know which root CAs we trust. An application supplies that information as a list of certificates representing the trusted root CAs. With that list in hand, the SSL implementation authenticates a peer by obtaining the peer’s certificate chain and examining it carefully for validity. If we view the chain as a hierarchy with the root CA certificate at the top and the peer’s certificate at the bottom, we can describe SSL’s validation activities as follows:
• The root CA certificate must be self-signed and be present among the application’s trusted CA certificates.
• All other certificates in the chain must be signed by the one immediately preceding it.
• The certificates must not be expired or revoked.
These tests certify that the chain is valid, but applications often require the chain to undergo more intensive scrutiny (see Section 42.4.6).
Commercial CAs exist to supply organizations with a reliable source of certificates, but in many cases a private CA is completely sufficient. You can create and manage your CA using freely-available tools, and in fact Ice includes a collection of utilities that simplify this process (see Section 42.7).
Depending on your implementation language, it may also possible to avoid the use of certificates altogether; encryption is still used to obscure the session traffic, but the benefits of authentication are sacrificed in favor of reduced complexity and administration.
For more information on PKI, see [5].

42.2.3 Requirements

Integrating IceSSL into your application often requires no changes to your source code, but does involve the following administrative tasks:
• creating a public key infrastructure (if necessary)
• configuring the IceSSL plug‑in
• modifying your application’s configuration to install the IceSSL plug‑in and use secure connections
The remainder of this chapter discusses plug‑in configuration and programming.

1
IceSSL is available for C++, Java and .NET applications. Python, PHP and Ruby applications can use IceSSL for C++ via configuration.

Table of Contents Previous Next
Logo