SSL
Secure Socket Layer
- Protocol developed by Netscape for transmitting private documents
via the Internet. Actually creates a secure connection over
which any amount of encrypted data can be sent.
- SSL works by using a private key to encrypt data that's transferred
over the SSL connection.
- Both Netscape Navigator and Internet Explorer support SSL,
and many Web sites use the protocol to obtain confidential user
information, such as credit card numbers.
- By convention, Web pages that require an SSL connection start
with https: instead of http:.
|
Details:
SSL Sits on top of TCP/IP
(from
http://www.netscape.com)
- uses TCP/IP on behalf of the higher-level protocols.
- An SSL-enabled server can authenticate itself to an SSL-enabled
client, vice-versa, and allows both machines to establish an
encrypted connection.
2 Sub-Protocols
1) SSL record protocol
defines the format used to transmit data.
2) SSL handshake protocol
involves using the SSL record protocol to exchange
a series of messages between an SSL-enabled server and
an SSL-enabled client when they first establish an SSL
connection.
This exchange of messages is designed to facilitate
the following actions:
handshake steps:
1.Client sends the server it's SSL version number,
cipher settings, randomly generated data, and other
information the server needs to communicate with
the client using SSL.
2.Server sends the client the server's
SSL version number, cipher settings, randomly generated
data, and other information the client needs to
communicate with the server over SSL. The server
also sends its own certificate and, if
the client is requesting a server resource that
requires client authentication, requests the client's
certificate.
3.Client uses some of the information
sent by the server to authenticate
the server. If the server cannot be authenticated,
the user is warned of the problem and informed that
an encrypted and authenticated connection cannot
be established. If the server can be successfully
authenticated, the client goes on to Step 4.
4.Using all data generated in the handshake so
far, the client
(with the cooperation of the server, depending on
the cipher being used) creates
the premaster secret for the session, encrypts it
with the server's public key (obtained
from the server's certificate, sent in Step 2),and
sends it to the server.
5.If the server has requested client authentication
(an optional step in the handshake), the client
also signs another piece of data that is unique
to this handshake and known by both the client and
server. In this case the client
sends both the signed data and the client's own
certificate to the server along with the encrypted
premaster secret.
6.If the server has requested client
authentication, the server attempts to authenticate
the client (see Client Authentication for details).
If the client cannot be authenticated, the session
is terminated. If the client can be successfully
authenticated, the server
uses its private key to decrypt the premaster secret,
then performs a series of steps (which the client
also performs, starting from the same premaster
secret) to generate the master secret.
7.Both the client and the server use
the master secret to generate the session keys,
which are symmetric keys used to encrypt and decrypt
information exchanged during the SSL session and
to verify its integrity--that is, to detect any
changes in the data between the time it was sent
and the time it is received over the SSL connection.
8.The client sends a message
to the server informing it that future messages
from the client will be encrypted with the session
key. It then sends a separate (encrypted)
message indicating that the client portion of the
handshake is finished.
9.The server sends a message
to the client informing it that future messages
from the server will be encrypted with the session
key. It then sends a separate (encrypted)
message indicating that the server portion of the
handshake is finished.
10.The SSL handshake is now complete, and the SSL
session has begun. The
client and the server use the session keys to encrypt
and decrypt the data they send to each
other and to validate its integrity.
|
|
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. This confirmation might be important if the user,
for example, is sending a credit card number over the
network and wants to check the receiving server's identity.
Netscape's SSL-enabled client software always requires
server authentication, or cryptographic validation by
a client of the server's identity. As explained in Step
2 of The SSL Handshake, the server sends the client
a certificate to authenticate itself. The client uses
the certificate in Step 3 to authenticate
the identity the certificate claims to represent.
How Netscape SS-enabled client
software authenticates server using the server's certificate:
An SSL-enabled client goes through these steps
to authenticate a server's identity:
1.Is today's date within the validity period? The
client checks the server certificate's validity
period. If the current date and time are outside
of that range, the authentication process won't
go any further. If the current date and time are
within the certificate's validity period, the client
goes on to Step 2.
2.Is the issuing CA a trusted CA? Each SSL-enabled
client maintains a list of trusted CA certificates,
represented by the shaded area on the right side
of Figure. This list determines which server certificates
the client will accept. If the distinguished name
(DN) of the issuing CA matches the DN of a CA on
the client's list of trusted CAs, the answer to
this question is yes, and the client goes on to
Step 3. If the issuing CA is not on the list, the
server will not be authenticated unless the client
can verify a certificate chain ending in a CA that
is on the list (see CA Hierarchies for details).
3.Does the issuing CA's public key validate the
issuer's digital signature? The client uses the
public key from the CA's certificate (which it found
in its list of trusted CAs in step 2) to validate
the CA's digital signature on the server certificate
being presented. If the information in the server
certificate has changed since it was signed by the
CA or if the CA certificate's public key doesn't
correspond to the private key used by the CA to
sign the server certificate, the client won't authenticate
the server's identity. If the CA's digital signature
can be validated, the server treats the user's certificate
as a valid "letter of introduction" from that CA
and proceeds. At this point, the client has determined
that the server certificate is valid. It is the
client's responsibility to take Step 4 before Step
5.
4.Does the domain name in the server's certificate
match the domain name of the server itself? This
step confirms that the server is actually located
at the same network address specified by the domain
name in the server certificate. Although step 4
is not technically part of the SSL protocol, it
provides the only protection against a form of security
attack known as a Man-in-the-Middle Attack. Clients
must perform this step and must refuse to authenticate
the server or establish a connection if the domain
names don't match. If the server's actual domain
name matches the domain name in the server certificate,
the client goes on to Step 5.
5.The server is authenticated. The client proceeds
with the SSL handshake. If the client doesn't get
to step 5 for any reason, the server identified
by the certificate cannot be authenticated, and
the user will be warned of the problem and informed
that an encrypted and authenticated connection cannot
be established. If the server requires client authentication,
the server performs the steps described in Client
Authentication.
|
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 (CA) listed in the server's
list of trusted CAs. This confirmation might be important
if the server, for example, is a bank sending confidential
financial information to a customer and wants to check
the recipient's identity.
How Netscape SSL server engine
authenticates a client's certificate:
(from www.netscape.com)
An SSL-enabled server goes through these steps
to authenticate a client's identity:
1.Does the user's public key validate the user's
digital signature? The server checks that the user's
digital signature can be validated with the public
key in the certificate. If so, the server has established
that the public key asserted to belong to John Doe
matches the private key used to create the signature
and that the data has not been tampered with since
it was signed. At this point, however, the binding
between the public key and the DN specified in the
certificate has not yet been established. The certificate
might have been created by someone attempting to
impersonate the user. To validate the binding between
the public key and the DN, the server must also
complete Step 3 and Step 4.
2.Is today's date within the validity period?
The server checks the certificate's validity period.
If the current date and time are outside of that
range, the authentication process won't go any further.
If the current date and time are within the certificate's
validity period, the server goes on to Step 3.
3.Is the issuing CA a trusted CA? Each SSL-enabled
server maintains a list of trusted CA certificates,
represented by the shaded area on the right side
of Figure 3. This list determines which certificates
the server will accept. If the DN of the issuing
CA matches the DN of a CA on the server's list of
trusted CAs, the answer to this question is yes,
and the server goes on to Step 4. If the issuing
CA is not on the list, the client will not be authenticated
unless the server can verify a certificate chain
ending in a CA that is on the list (see CA Hierarchies
for details). Administrators can control which certificates
are trusted or not trusted within their organizations
by controlling the lists of CA certificates maintained
by clients and servers.
4.Does the issuing CA's public key validate the
issuer's digital signature? The server uses the
public key from the CA's certificate (which it found
in its list of trusted CAs in Step 3) to validate
the CA's digital signature on the certificate being
presented. If the information in the certificate
has changed since it was signed by the CA or if
the public key in the CA certificate doesn't correspond
to the private key used by the CA to sign the certificate,
the server won't authenticate the user's identity.
If the CA's digital signature can be validated,
the server treats the user's certificate as a valid
"letter of introduction" from that CA and proceeds.
At this point, the SSL protocol allows the server
to consider the client authenticated and proceed
with the connection as described in Step 6. Netscape
servers may optionally be configured to take Step
5 before Step 6.
5.Is the user's certificate listed in the LDAP
entry for the user? This optional step provides
one way for a system administrator to revoke a user's
certificate even if it passes the tests in all the
other steps. The Netscape Certificate Server can
automatically remove a revoked certificate from
the user's entry in the LDAP directory. All servers
that are set up to perform this step will then refuse
to authenticate that certificate or establish a
connection. If the user's certificate in the directory
is identical to the user's certificate presented
in the SSL handshake, the server goes on to step
6.
6.Is the authenticated client authorized to access
the requested resources? The server checks what
resources the client is permitted to access according
to the server's access control lists (ACLs) and
establishes a connection with appropriate access.
If the server doesn't get to step 6 for any reason,
the user identified by the certificate cannot be
authenticated, and the user is not allowed to access
any server resources that require authentication.
|
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 whether the data has been altered in transit.
|
Supported Cryptogrophy Alogirhtms
(Cipher Suites)
- DES. Data Encryption Standard, an encryption
algorithm used by the U.S. Government.
- DSA. Digital Signature Algorithm, part of the
digital authentication standard used by the U.S. Government.
- KEA. Key Exchange Algorithm, an algorithm used
for key exchange by the U.S. Government.
- MD5. Message Digest algorithm developed by Rivest.
- RC2 and RC4. Rivest encryption ciphers developed
for RSA Data Security.
- RSA*.
A public-key algorithm for both encryption and authentication.
Developed by Rivest, Shamir, and Adleman.
- RSA key exchange*.
A key-exchange algorithm for SSL based on the RSA algorithm.
- SHA-1. Secure Hash Algorithm, a hash function
used by the U.S. Government.
- SKIPJACK. A classified symmetric-key algorithm
implemented in FORTEZZA-compliant hardware used by the
U.S. Government. (For more information, see FORTEZZA Cipher
Suites.)
- Triple-DES. DES applied three times.
*= most commonly used. |
|
Must Install support on your Web-server
- OpenSSL freeware, (in
source code form)
- Or see your web-server's documentation, web-site for other
possibilites.
- Apache SSL (Apache
with OpenSSL)
|
|