76 lines
5.0 KiB
HTML
76 lines
5.0 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="concept" />
|
|
<meta name="DC.Title" content="How SSL works" />
|
|
<meta name="abstract" content="SSL is actually two protocols. The protocols are the record protocol and the handshake protocol. The record protocol controls the flow of the data between the two endpoints of an SSL session." />
|
|
<meta name="description" content="SSL is actually two protocols. The protocols are the record protocol and the handshake protocol. The record protocol controls the flow of the data between the two endpoints of an SSL session." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzainconcepts.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurzahu4abunderstanddc.htm" />
|
|
<meta name="DC.Relation" scheme="URI" content="../rzajc/rzajcoverview.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002, 2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002, 2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="howssl" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>How SSL works</title>
|
|
</head>
|
|
<body id="howssl"><a name="howssl"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">How SSL works</h1>
|
|
<div><p>SSL is actually two protocols. The protocols are the record protocol
|
|
and the handshake protocol. The record protocol controls the flow of the data
|
|
between the two endpoints of an SSL session.</p>
|
|
<p>The handshake protocol authenticates one or both endpoints of the SSL session
|
|
and establishes a unique symmetric key used to generate keys to encrypt and
|
|
decrypt data for that SSL session. SSL uses asymmetric cryptography, digital
|
|
certificates, and SSL handshake flows, to authenticate one or both endpoints
|
|
of an SSL session. Typically, SSL authenticates the server. Optionally, SSL
|
|
authenticates the client. A digital certificate, issued by a Certificate Authority,
|
|
can be assigned to each of the endpoints or to the applications using SSL
|
|
on each endpoint of the connection. </p>
|
|
<p>The digital certificate is comprised of a public key and some identifying
|
|
information that a trusted Certificate Authority (CA) has digitally signed.
|
|
Each public key has an associated private key. The private key is not stored
|
|
with or as part of the certificate. In both server and client authentication,
|
|
the endpoint which is being authenticated must prove that it has access to
|
|
the private key associated with the public key contained within the digital
|
|
certificate. </p>
|
|
<p>SSL handshakes are performance intensive operations because of the cryptographic
|
|
operations using the public and private keys. After an initial SSL session
|
|
has been established between two endpoints, the SSL session information for
|
|
these two endpoints and applications can be cached in secure memory to speed
|
|
up subsequent SSL session enablements. When an SSL session is resumed, the
|
|
two endpoints use an abbreviated handshake flow to authenticate that each
|
|
has access to unique information without using the public or private keys.
|
|
If both can prove that they have access to this unique information, then
|
|
new symmetric keys are established and the SSL session resumes. For TLS Version
|
|
1.0 and SSL Version 3.0 sessions, cached information will not remain in the
|
|
secure memory for greater than 24 hours. In OS/400<sup>®</sup> V5R2 and subsequent releases
|
|
or i5/OS™,
|
|
you can minimize SSL handshake performance impacts on the main CPU by using
|
|
cryptographic hardware.</p>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzainconcepts.htm" title="SSL concepts includes supplemental information, providing some basic building blocks for the Secure Sockets Layer (SSL) protocols.">Concepts</a></div>
|
|
</div>
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
|
<div><a href="../rzahu/rzahurzahu4abunderstanddc.htm">Digital certificate concepts</a></div>
|
|
<div><a href="../rzajc/rzajcoverview.htm">Cryptographic hardware</a></div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html> |