o reilly Web Security & Commerce phần 10 ppt

Server Key Exchange The server sends the server key exchange message if the server has no certificate or if it has a certificate that is used only for signing.. Table C.3, Server Key Exc

C.4.1.4 4 Server Key Exchange

The server sends the server key exchange message if the server has no certificate or if it has a certificate that

is used only for signing This might happen in one of three cases:

• The server is using the Diffie-Hellman key exchange protocol

• The server is using RSA, but has a signature-only RSA key

• The server is using the Fortezza/DMS encryption suite

The key exchange message consists of the fields shown in Table C.3

Table C.3, Server Key Exchange Parameters

Field Meaning

For Diffie-Hellman key exchange:

ServerDHParams params The server's Diffie-Hellman public value (Ys)

opaque y_c<0 128> The client's Yc value used in the Fortezza Key

Exchange Algorithm (KEA)

opaque r_c[128] The client's Rc value used in the KEA

opaque

wrapped_client_write_key[12] The client's write key, wrapped by the Fortezza's

token encryption key (TEK)

encrypted_pre_mater_secret[48] 48 bytes generated with a secure random number

generator and encrypted using the TEK

Signatures may be RSA signatures, DSA signatures, or anonymous (in which case there are no signatures) Servers that have no signatures offer no protection against man-in-the-middle or server substitution attacks SSL 3.0 defines three modes of Diffie-Hellman operations for the initial key exchange:

Anonymous Diffie-Hellman

In this mode, the server generates its Diffie-Hellman public value and the Diffie-Hellman parameters and sends them to the client The client then sends back its client value This mode is susceptible to the man-in-the-middle attack, because the server's parameters and public value are not

authenticated (In a man-in-the-middle attack, an attacker could simply conduct anonymous

Diffie-Fixed Diffie-Hellman

In this mode, the server's certificate contains its fixed Diffie-Hellman parameters instead of an RSA or DSS public key As SSL 3.0 allows only one key per server, a server that is configured to operate in fixed Diffie-Hellman mode cannot interoperate with SSL clients that expect to perform RSA key

exchanges

Ephemeral Diffie-Hellman

In this mode, the server generates its own Diffie-Hellman parameters, then uses a pre-existing RSA or DSS public key to sign the parameters, which are then sent to the client This third mode appears to

be the most secure SSL 3.0 operating mode

Netscape Navigator Versions 1, 2, and 3 do not implement Diffie-Hellman, but future versions of the product might More programs may implement the algorithm in the future, however, as the Diffie-Hellman patent expires on March 30, 1997

C.4.1.5 5 Certificate Request

If the server wishes to authenticate the client, it can send a Certificate Request to the client Certificate

Requests consist of five parts, shown in Table C.4

Table C.4, Certificate Request Message

Field Meaning

ClientCertificateType

certificate_types<1 28-1> The types of certificates requested by the

server

Random random A random structure (consisting of a 32-bit

timestamp and 28 bytes generated by a secure random number generator)

SessionID session_id

The session ID This field is never empty If it matches the session_id provided by the client in the ClientHello, it indicates that the previous SSL session will be resumed Otherwise, the session_id of the new session is provided

CipherSuite ciper The cipher chosen by the server for this

session

CompressionMethod

for this session

C.4.1.6 6 Client Sends Certificate

If requested by the SSL server, the client sends any certificates that were requested If no certificate is

available, the client sends the no certificate alert

It is up to the SSL server to decide what to do if a no certificate alert is received The SSL server could

continue the SSL transaction with an anonymous client Alternatively, the SSL server could terminate the connection by sending a data handshake failure alert

C.4.1.7 7 ClientKeyExchange

The client can send one of three kinds of key exchange messages, depending on the particular public key

algorithm that has been selected These are shown in Table C.5

Table C.5, Server Key Exchange Parameter

Field Meaning

For Diffie-Hellman key exchange:

opaque dh_Yc<1 216-1> The client's Diffie-Hellman public value (Yc)

Signature signed_params The signature for the parameters

For RSA:

ServerRSAarams params The server's RSA parameters

Structure signed_params The signature for the parameters

For Fortezza/DMS:

ServerFortezzaParams params The server's Fortezza parameters

C.4.1.8 8 CertificateVerify

If the client sends a public certificate that has signing capability (such as an RSA or a DSS certificate), the

client now sends a CertificateVerify message This message consists of two message authentication codes,

one calculated with the MD5 algorithm and one calculated with SHA They are:

The handshake_messages refers to all handshake messages starting with the ClientHello up to but not

including the CertificateVerify message

C.4.1.9 9 ChangeCipherSpec

After the CertificateVerify is sent, the ChangeCipherSpec message is sent After the message is sent, all

following messages are encrypted according to the specified cipher suite and compressed according to the

opaque md5_hash[16] A 16-byte MD5 hash code

opaque sha_hash[20] A 20-byte SHA hash code

C.4.2 Application Data

After the SSL Finished message is sent, application data is transported All application data is divided into individual SSL record-layer messages These messages are then compressed and encrypted according to the current compression method and cipher suite

Holds the private key certificates used by the SSL servers on your system

SSLeay can be freely used outside the United States Within the United States, its use is governed by the patents on public key cryptography

C.5.1 SSLeay Examples

Michael Grant has created several small programs that demonstrate how to use SSLeay to create a secure SSL server and client The programs run under Solaris 2.5 They are included here with his permission

it prints) and then disconnects

There are two arguments:

hostname to connect to

port number (which the server will tell you when it starts)

You will need to supply a certificate for a CA This is used in CAfile below */

#define CAfile "demoCA/cacert.pem"

#define CApath NULL

main(int argc, char **argv)

{

int sock; /* The TCP/IP socket */

struct sockaddr_in server;

struct hostent *hp;

char buf[1024];

SSL_CTX *c_ctx=NULL; /* The Client's context */

SSL *c_ssl=NULL; /* The Client's SSL connection */

/* Create a new context This holds information pertinent to the

* client's SSL side of the connection

/* Tell SSL to request the server's certificate when we connect */

SSL_CTX_set_verify(c_ctx,SSL_VERIFY_PEER, verify_callback);

/* Now we can create a basic TCP/IP connection */

if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)

/* Lets find out who the peer *really* is We look though the

* server's certificate to see who he says he is

/* Send some data to the server */

printf("sending data\n");

SSL_write(c_ssl,"hello from client",18);

memset(buf, 0, sizeof(buf));

printf("waiting for data\n");

/* Now we receive some data from the server and print it out */

server ready waiting on port 43205

starting connection using RC4-MD5 cipher

>hello from client

This program implements a simple server which accepts TCP/IP connections,

starts SSL on the connection, waits for some data (which it prints), sends

some data back to the client, then waits for more data When the connection

is closed by the client, it continues to wait for a new connection

There are no arguments When the server starts, it will tell you what

port it is waiting on This information is used to start the client

You will need to supply a certificate for a CA, the server's certificate,

and the server's private key These are used in CAfile, SERVER_CERT, and

SERVER_KEY respectively below

#define CAfile "demoCA/cacert.pem"

#define CApath NULL

#define SERVER_CERT "./server_cert.pem"

#define SERVER_KEY "./server_key.pem"

SSL_CTX *s_ctx=NULL; /* The Server's context */

SSL *s_ssl=NULL; /* The Server's SSL connection */

SSL_load_error_strings();

/* Create a new context This holds information pertinent to the

* client's SSL side of the connection

/* Now we create a socket and wait for a basic TCP/IP connection */

if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0)

printf("server ready waiting on port %d\n", ntohs(server.sin_port));

/* We now are ready to wait for a basic TCP/IP connection up

*/

listen(sock, 5);

while (1) /* Do this for each incoming TCP/IP connection */

{

/* Accept the new TCP/IP connection */

if ((fd = accept(sock, NULL, NULL)) == -1) {

printf("SSL_new() failed\n");

exit(1);

}

/* Tell SSL that this connection is to use the socket we

* just created above

ERR_reason_error_string (ERR_get_error()));

{

/* If everything is OK, print out data received */

/* Now send some data back to the client */

SSL_write(s_ssl,"hello from server",18);

C.5.1.3 SSLeay CA

Michael Grant has also put together a very simplified CA to create and sign the certificates needed for the

demo client and server programs The ca.conf file is included below

Here is the program's operation First we create a configuration file and a directory to hold the certificates:

% ssleay req -config ca.conf -x509 -new -keyout cakey.pem -out

cacert.pem Generating a 1024 bit private key

+++++

+++++

unable to write 'random state'

writing new private key to 'cakey.pem'

-

You are about to be asked to enter information that will be incorperated into

your certificate request

What you are about to enter is what is called a Distinguished Name or a DN

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank

-

Country Name (2 letter code) [US]:US

Organization Name (eg, company) [MegaWidget]:MegaWidget

Organizational Unit Name (eg, section) [Eng]:Eng

Common Name (eg, YOUR name) [Michael Grant]:CA

% ls

ca.conf cakey.pem new_certs/

cacert.pem index.txt serial

Now we generate a request for a certificate and a private key for the server This request could be emailed to the CA

% ssleay req -config ca.conf -new -keyout server_key.pem -out

server_req.pem Generating a 1024 bit private key

.+++++

+++++

unable to write 'random state'

writing new private key to 'server_key.pem'

-

You are about to be asked to enter information that will be incorporated

into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank

-

Country Name (2 letter code) [US]:US

Organization Name (eg, company) [MegaWidget]:MegaWidget

Organizational Unit Name (eg, section) [Eng]:Eng

Common Name (eg, YOUR name) [Michael Grant]:Michael Grant Server

When the certificate request is received, the CA signs it:

% ssleay ca -config ca.conf -keyfile cakey.pem -cert cacert.pem -in

server_req.pem -out server_cert.pem Check that the request matches the

commonName :PRINTABLE:'Michael Grant Server'

Certificate is to be certified until Jan 24 09:02:06 1998 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

[unix% 559] ls

ca.conf index.txt serial server_key.pem

cacert.pem index.txt.old serial.old server_req.pem

cakey.pem new_certs/ server_cert.pem

Now let's look at the contents of the CA's self certifying certificate Notice that the Issuer (the signer) and the subject (the owner of the key) are the same:

% ssleay x509 -text -noout -in cacert.pem

Certificate:

Data:

Version: 0 (0x0)

Serial Number: 0 (0x0)

Signature Algorithm: md5withRSAEncryption

Issuer: C=US, O=MegaWidget, OU=Eng, CN=CA

Validity

Not Before: Jan 24 08:59:30 1997 GMT

Not After : Feb 23 08:59:30 1997 GMT

Subject: C=US, O=MegaWidget, OU=Eng, CN=CA

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

This shows the server's CA certified certificate Notice that the issuer is the CA (the signer) and the subject (the owner) is the server:

% ssleay x509 -text -noout -in server_cert.pem

Certificate:

Data:

Version: 0 (0x0)

Serial Number: 1 (0x1)

Signature Algorithm: md5withRSAEncryption

Issuer: C=US, O=MegaWidget, OU=Eng, CN=CA

Validity

Not Before: Jan 24 09:02:06 1997 GMT

Not After : Jan 24 09:02:06 1998 GMT

Subject: C=US, O=MegaWidget, OU=Eng, CN=Michael Grant Server

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

C.5.1.4 Running the server

The server program must be run before the client is started It prints the number of the port that it is running on:

% /server

server ready waiting on port 43436

starting connection using RC4-MD5 cipher

>hello from client

C.5.1.5 Running the client

The client program should be run in another window Its argument is the hostname and port where the server

>hello from server

There are two certificates, one for a CA (that's the depth=1) and one for the server (that's depth=0)

C.5.1.6 SSLeay ca.conf file

This is the configuration file needed for the example:

#

# SSLeay example configuration file

# This is mostly being used for generation of certificate requests

certs = $dir/certs # Where the issued certs are kept

database = $dir/index.txt # database index file

new_certs_dir = $dir/new_certs # default place for new certs

certificate = $dir/cacert.pem # The CA certificate

serial = $dir/serial # The current serial number

private_key = $dir/ca_key.pem # The private key

RANDFILE = $dir/.rand # private random number file

# A few difference way of specifying how similar the request should

# look

# For type CA, the listed attributes must be the same, and the optional

# and supplied fields are just that :-)

# For the 'anything' policy

# At this point in time, you must list all acceptable 'object'

Appendix D The PICS Specification

The PICS specification introduced in Chapter 17, consists of two parts:

• A specification for the protocols that must be supported by a rating service This specification is located at http://w3.org/PICS/services.html

• A specification for the format of the labels themselves This specification is located at

http://w3.org/PICS/labels.html

An excellent article describing PICS is "PICS: Internet Access Controls Without Censorship," by Paul Resnick

and James Miller, Communications of the ACM, October 1996, p 87 The online version of the article appears

(name "The Movies Rating Service")

(description "A rating service based on the MPAA's movie rating scale")

(category

(transmit-as "r")

(name "Rating")

(label (name "G") (value 0) (icon "icons/G.gif"))

(label (name "PG") (value 1) (icon "icons/PG.gif"))

(label (name "PG-13") (value 2) (icon "icons/PG-13.gif"))

(label (name "R") (value 3) (icon "icons/R.gif"))

(label (name "NC-17") (value 4) (icon "icons/NC-17.gif"))))

This rating description indicates a location where information about the rating system and service can be found, gives it a name, and creates a single rating category called Rating Rated objects can have one of five different ratings: G, PG, PG-13, R, or NC-17 The standard gives each of these ratings a value and an

associated icon to be displayed with the rating

The PICS rating service description is defined to have a MIME file type application/pics-service The file

is formatted as a list

The PICS format makes extensive use of name/value pairs These are formatted as (name value) They are interpreted as "name has the value of value." For example, (min 0.0) means that the particular object being described has a minimum value of 0.0

The following names are used to describe the ratings services themselves:

PICS-version aVersion

The version number of the PICS standard being supported Should be 1.1

rating-system aURL

A URL that indicates the location of a human-readable description of the categories, scales, and

intended criteria for assigning ratings

Introduces a list of elements that describe a particular label

Integer

Indicates that the label is transmitted as an integer By default, PICS ratings are not integers

Each PICS label is further described by a collection of name/value pairs:

name aValue

The name of the label and its value

Ratings services can operate label bureaus A label bureau is "a computer system which supplies, via a

computer network, ratings of documents It may or may not provide the documents themselves."

D.2 PICS Labels

The PICS label specification defines the syntax for document labels Labels can be obtained over the Web from a search service using an HTTP extension defined in the PICS standard Alternatively, labels can be automatically included with a document, as part of the document's header

Here is a PICS label that ranks a URL using the service described in the previous section:

This label describes the web site for the Paramont movie Mission: Impossible using the fictitious labeling

service described in the previous section The label was created on June 1, 1996, and is valid until December

31, 1996 The label is for information stored at the URL http://www.missionimpossible.com/ The label was

written by Simson L Garfinkel Finally, the label gives the rating "(r 0)."

Although the movie Mission: Impossible had a rating of "R," the web site has a rating of "G." (The value "G" is transmitted with using the http://moviescale.org/v1.0 rating service.)

Ratings may include more than one transmitted value For example, if a rating service defined two scales, a label rating might look like this: "(r 3 n 4)."

Labels can be substantially compressed by removing nearly all information except the ratings themselves For example, the above label could be transmitted like this:

(PICS-1.0 "http://moviescale.org/v1.0"

r 0)

Labels can optionally include an MD5 message digest hash of the labeled document This allows software to determine if the fetched document has been modified in any way since the label was created Labels can also have digital signatures, which allows labeling services to sign their own labels That would allow a site to distribute labels for its content that were created by a third-party labeling service and give users the

assurance that the labels had not been modified in any way

Here is a complete description of all of the fields in revision 5 of the label format:

Information about the document that is labeled

The MD5 hash value of the item being rated

Information about the document label itself

by name

The name of the person or organization that rated the item Name, like all strings in the label

specification, may be either a human-readable quoted name or a Base64 encoded string

-or- exp quoted-ISO-date

The date on which this rating expires

Other information

comment acomment

A comment It's not supposed to be read by people

complete-label quotedURL

-or- full quotedURL

A URL of the complete label The idea of this field is that an abridged label might be sent with a

document in the interest of minimizing transmission time Then, if a piece of software wants the

complete label, that software can get it from the quotedURL