Chapter 3:
An SSL Primer
This chapter gives you a broad overview of the SSL technology and its application.
__Topics_________________________
The SSL
Protocol
The SSL
Handshake
What is public
key encryption?
The secure
link
How do
certificates work?
How to view
browser certificates
How does
SSL use ciphers?
How do digital
signatures work?
What are
certificate chains?
The SSL Protocol
The SSL protocol works
cooperatively with several other protocols. The underlying mechanism
is TCP/IP (Transmission Control Protocol/Internet Protocol), which
governs the transport and routing of data over the Internet.
Application protocols, such as HTTP (HyperText Transport Protocol),
LDAP (Lightweight Directory Access Protocol), and IMAP (Internet
Messaging Access Protocol), run above TCP/IP. They use TCP/IP to
support typical application tasks such as displaying web pages or
running email servers.
The SSL protocol runs
above TCP/IP and below HTTP, LDAP, and IMAP.
It uses TCP/IP on behalf
of these high-level protocols.
SSL addresses three fundamental
security concerns about communication over the Internet and other
TCP/IP networks:
-
SSL server authentication
allows a user to confirm a server's identity. SSL-enabled client
software can use standard techniques of public-key cryptography to
check that a server's certificate and public ID are valid and have
been issued by a certificate authority (CA) listed in the client's
list of trusted CAs. For example, if a PC user is sending a credit
card number to make a purchase on the web and wants to check the
receiving server's identity.
-
SSL client authentication
allows a server to confirm a user's identity. Using the same
techniques as those used for server authentication, SSL-enabled
server software can check that a client's certificate and public ID
are valid and have been issued by a certificate authority listed in
the server's list of trusted CAs. For example, if a bank is
sending confidential financial information to a customer and wants to
check the recipient's identity.
-
An encrypted SSL connection
requires all information sent between a client and a server to be
encrypted by the sending software and decrypted by the receiving
software, thus providing a high degree of confidentiality.
Confidentiality is important for both parties to any private
transaction. In addition, all data sent over an encrypted SSL
connection is protected with a mechanism for detecting tampering -
that is, for automatically determining if data has been
altered in transit.
The SSL Handshake
An SSL session always begins with an exchange of messages called the SSL
handshake. The handshake allows the server to authenticate
itself to the client using public-key techniques, also called asymmetric
encryption. It then allows the
client and the server to cooperate in the creation of symmetric
keys, which are used for rapid encryption, decryption, and
tamper detection during the session that follows. Optionally, the
handshake also allows the client to authenticate itself to the server.
This exchange of messages is
designed to facilitate the following actions:
 iPlanet:
Introduction to SSL
What is public key encryption?
In traditional, non-Internet environments, encrypted information is
sent between parties that both use the same key to encode and decode
information. This is called symmetrical encryption.
In the case of the Internet, there is no way for one computer to send
the encryption key to another without the risk that a third party can
steal the key and decode subsequent communications. A method other
than symmetrical encryption is required to transmit the encryption
key securely on the Internet.
The principals of public key cryptography were developed by Whitfield
Diffie and Martin Hellman. The Diffie-Hellman key
agreement protocol was published in 1976. It is also called asymmetric
encryption because it uses two keys instead of one key. |
The solution is a system that uses two keys. The first is a public
key, and usually available to anyone who wants it. The
second, a private key, is held by just one party.
Only the private key can decipher information encrypted using the
public key; it is impossible to decipher the message using the public
key. Similarly, only the private key can create encrypted messages
decipherable with the public key. Because there can be only one
public key for each private key, and vice-versa, it is nearly
impossible to impersonate the holder of the private key.
The two keys are mathematically related, but in such a way that it is
virtually impossible to derive the private key from the
public one.
During the SSL handshake, each computer generates a set of codes to
encrypt information. From these codes, each computer creates two keys,
one private and one public. Your computer keeps the private key
secret, but sends out the public key to the other computer, which
uses that key to encode subsequent messages so that only your
computer can read them. The public key cannot, however, be used to
decode the message; the decoding can only be done using the private key.
These keys allow you and the other computer to lock and unlock
information so that only the holder of the private key can read
messages encrypted by the public key. Since only you and the other
computer have a copy of your respective private keys, there is no way
for anybody else to intercept and decode your messages.
Webopedia
Definition and Links
The secure link
When a user enters a secure link to send information with either
Netscape Communicator or Microsoft Internet Explorer, the browser
negotiates the key code exchanges so the user is not aware of this
happening. However, the page information downloads more slowly on the
secure link than it does on unsecured links because of the extra
encryption information being sent. Both the user's computer and the
server computer generate a public-private key set, and then exchange
public keys with each other.
Once this exchange has occurred, a new master key is generated and
transmitted through the secure connection. This master key is
symmetrical; messages can now be both encrypted and decrypted using
the same key. In addition, a message authentication code (MAC) is
used to make sure that the information being exchanged is not altered
during transmission.
How do certificates work?
A certificate, or digital
certificate, is
an electronic document used to identify an individual, a server, a
company, or some other entity and to associate that identity with a
public key. Like a driver's license, a passport, or other commonly
used personal IDs, a certificate provides generally recognized proof
of a person's identity. Public-key cryptography uses certificates to
address the problem of impersonation.
Certificates are issued by certificate authorities (also known as
certification authorities). These are trusted third parties that
verify the identity of the site you are connected with. Like any form
of identification, the authenticity of the issuer is essential.
The role of CAs in validating identities and issuing certificates is
analogous to the way a government issues passports and driver's
licenses. CAs can be either independent third parties or
organizations running their own certificate-issuing server software
(such as Netscape Certificate Server). |
The methods used to validate an identity vary depending on the
policies of a given CA. In general, before issuing a certificate, the
CA must use its published verification procedures for that type of
certificate to ensure that an entity requesting a certificate is in
fact who it claims to be.
The certificate issued by the CA binds a particular public key to the
name of the entity the certificate identifies (such as the name of an
employee or a server). Certificates help prevent the use of fake
public keys for impersonation. Only the public key certified by the
certificate will work with the corresponding private key possessed by
the entity identified by the certificate.
In addition to a public key, a certificate always includes the name
of the entity it identifies, an expiration date, the name of the CA
that issued the certificate, a serial number, and other information.
Most importantly, a certificate always includes the digital signature
of the issuing CA. The CA's digital signature allows the certificate
to function as a "letter of introduction" for users who
know and trust the CA but don't know the entity identified by the certificate.
IPlanet: Introduction to Public-Key Cryptography
How to view browser certificates
Netscape and Microsoft browsers have built-in lists of CAs, which you
can choose to alter. There is no absolute list of which
certificate authorities are reliable, but the ones included in
Netscape and Microsoft browsers have been accepted as dependable by
Netscape and Microsoft. If you connect with a secure site authorized
by a CA not listed in your browser's list, you will be alerted and
asked if you want to add the new CA to your browser's list. You should not add a new CA to your list unless you
have a good reason to trust the CA.
Viewing certificates in Microsoft
Internet Explorer
To view CA certificates that are
contained in the browser's Certificate Manager:
-
On the Tools menu in Internet Explorer, click Internet Options.
- Click the Content tab.
- In the Certificatesarea, click the Certificates
button to view the list of current certificates by category,
including Trusted Root Certification Authorities.
Viewing certificates in Netscape Navigator
To view the CA certificates that are contained in the browser's
Trusted Root Library:
-
On the Netscape toolbar, click the Security icon to open the Security
Info window.
- Click the link labeled Signers to
open the Certificate Signers' Certificates window,
containing a list of all the CA certificates contained in the browser.
In addition, you can view the specific certificate being used in a
secure connection by double-clicking on the padlock symbol in your
browser's status bar.
How does SSL use ciphers?
Integral to the SSL protocol is
its use of cryptographic algorithms, generally called ciphers. These
are required to authenticate the server and client to
each other, transmit certificates, and establish session keys.
Clients and servers may support different cipher suites, or
sets of ciphers, depending on factors such as the version of SSL they
support, company policies regarding acceptable encryption strength,
and government restrictions on export of SSL-enabled software.
Among its other functions, the
SSL handshake protocol determines how the server and client negotiate
which cipher suites they will use to authenticate each other, to
transmit certificates, and to establish session keys. Key-exchange
algorithms like KEA and RSA key exchange govern the way in which the
server and client determine the symmetric keys they will both use
during an SSL session. The most commonly used SSL cipher suites use
RSA key exchange.
The SSL 2.0 and SSL 3.0 protocols
support overlapping sets of cipher suites. Administrators can enable
or disable any of the supported cipher suites for both clients and
servers. When a particular client and server exchange information
during the SSL handshake, they identify the strongest enabled cipher
suites they have in common and use those for the SSL session.
Decisions about which cipher
suites a particular organization decides to enable depend on
trade-offs among the sensitivity of the data involved, the speed of
the cipher, and the applicability of export rules.
Cipher
Suite with RSA Key Exchange
iPlanet
e-Commerce Solutions
FORTEZZA
Cipher Suites
How do digital signatures work?
Encryption and decryption address the problem of eavesdropping.
However, tampering and impersonation are still possible.
Public-key cryptography addresses the problem of tampering using a
mathematical function called a one-way
hash (also called a message digest).
A one-way hash is a fixed-length number whose value is unique to the
data being hashed. Any change in the data, even deleting or altering
a single character, results in a different value.
The content of the hashed data cannot, for all practical purposes, be
deduced from the hash, which is why it is called "one-way."
This principle is the crucial part of digitally signing any data.
Instead of encrypting the data itself, the signing software creates a
one-way hash of the data, then uses your private key to encrypt the
hash. The encrypted hash, along with other information, such as the
hashing algorithm, is known as a digital
signature.
What are certificate chains?
The X.509 standard (the certificate protocol used by SSL) includes a
model for setting up a hierarchy of CAs, making it possible to
delegate certificate-issuing responsibilities to subordinate CAs.
Inspecting a browser's certificate store will show a collection of
"intermediate CAs."
CA hierarchies are reflected in certificate
chains. A certificate chain is a succession of certificates
issued by successive CAs. Trusted root
CAs are at the pinnacle of the pyramid and are the only
entities to self-sign their certificates.
Using the mod_ssl directive SSLVerifyDepth
you can determine how many levels of intermediate CAs you would like
your server to authenticate.
SSLVerifyDepth
directive
|
