GUIDELINE DOCUMENT FOR WAP SECURITY TESTING

1. INTRODUCTION..................................................................................................................................3

2. THE ROLE OF SECURITY................................................................................................................3

3. TYPES OF SECURITY SESSIONS...................................................................................................3

4. SCOPE OF THE DOCUMENT..........................................................................................................3

5. BASIC WAP SECURITY TESTING CONCEPTS...........................................................................3

5.1 TYPES OF SECURE CONNECTIONS...........................................................................................................45.1.1 Class 1: Anonymous Connection 45.1.2 Class 2: Server Authentication 45.1.3 Class 3: Client and Server Authentication 5

6 FEASIBILITY OF WAP SECURITY TESTING.................................................................................6

7. ESTABLISHING WTLS CONNECTIONS...........................................................................................6

7.1 CLASS 1 WTLS CONNECTIONS............................................................................................................67.1.1 Settings to be made in the Gateway to establish WTLS connection: 67.1.2 Settings to be made in the mobile to establish WTLS connection: 6

7.2 CLASS 2 WTLS CONNECTIONS............................................................................................................77.2.1 Using Nokia Active Server Certificate Tool 87.2.2 Creating a CSR using Nokia Active Server Certificate Tool 87.2.3 Installing Signed Server Certificate created by a CA 107.2.4 Creating a Self-signed Server certificate 117.2.5 Ethereal trace for Client Hello Message in the WTLS session 137.2.6 Ethereal trace for Server Hello message in a WTLS session 14

8 ESTABLISHING TLS SECURE SESSIONS..................................................................................15

8.1 PROCEDURE TO CREATE SERVER CERTIFICATES USING OPENSSL........................................................158.2 CONFIGURING TLS SESSIONS...............................................................................................................17

8.2.1 SSL directives in ModSSL (Apache) 178.2.2 Ethereal trace for Client Hello message in a TLS session 208.2.3 Ethereal trace for Server Hello Message in a TLS session 21

9 ESTABLISHING SSL CONNECTIONS USING IIS SERVER...........................................................22

9.1 IMPORTING THE SERVER CERTIFICATE INTO THE CERTIFICATE CONSOLE............................................239.2 CREATING A SERVER CERTIFICATE FROM THE INTERNET....................................................................269.3 IMPORT THE CERTIFICATE INTO IIS......................................................................................................299.3 CHANGES TO BE MADE IN THE REGISTRY:...........................................................................................319.4 ETHEREAL TRACES FOR CLIENT HELLO MESSAGE IN SSL SESSION:....................................................319.5 ETHEREAL TRACE FOR SERVER HELLO MESSAGE IN SSL SESSION:....................................................32

10 ABBREVIATED HANDSHAKE IN SECURE SESSIONS................................................................33

10.1 CREATING ABBREVIATED HANDSHAKE SESSIONS.............................................................................33

11 Abbreviations and Acronyms....................................................................................................................35

1. IntroductionSecurity has an obvious role to play with regard to m-commerce and the ability to secure transactions. Secure sessions provide reliability, privacy, integrity and repudiation for the data.

2. The Role of SecuritySecurity is both an enabling and disabling technology. Its purpose is to enable communications and transactions to take place in a secure environment without fear of compromise, while at the same time disabling non-legitimate activities and access to information and facilities. Non-legitimate activities include eavesdropping, pretending to be another party (also known as impostering or spoofing), or tampering with data during transmission. In general these activities are either unacceptable or illegal outside of the digital environment, so security simply helps to enforce the status quo in that sense.

3. Types of Security Sessions

The different types of secure sessions that can be established are WTLS, TLS and SSL.

Security can be checked either at the Gateway or at the Server depending on the type of secure session that is established

4. Scope of the document

This document describes in detail the procedures to be followed to establish secure WAP sessions using WTLS, TLS and SSL. It also describes how to create various certificates and install them on the Gateway and Server machines. The Ethereal traces and screen shots are also provided for the various connections like WTLS, TLS and SSL to provide more clarity and to enhance the understandability of the reader.

5. Basic WAP Security Testing Concepts

For WTLS sessions, the security configuration and settings should be made in the machine (i.e. PC) in which the Gateway is running. TLS and SSL sessions are established using the secure HTTP protocol. For these sessions, security should be checked at the server machine.

Some access configurations also use a proxy between the Server and the client.

FreeProxy tool is a tool that acts as a proxy.

Using this tool, various users and groups can be created and authentications can be provided to them.

The various kinds of authentication that can be tested are:1. Basic authentication

In this mechanism, the user id and password are passed in the HTTP messages using 'clear text' after being encoded (not encrypted). Although the password cannot be read by simply looking at the message, it can easily be decoded using the right tool by anyone intent on breaking into the message.

2. Digest authenticationThis mechanism is more secure than Basic as it does not send the password in the message but rather a 'digest' or mathematical hash of the password using standard hashing algorithms. It would be extremely difficult for anyone to masquerade or derive the password from the message.

5.1 Types of secure Connections

5.1.1 Class 1: Anonymous Connection

In these connections, the data will be encrypted but the parties communicating securely do not exchange their identity with each other. There will be no exchange of certificates in between the client (mobile) and the server (content server).

The sequences of steps that occur in a Class 1 secure connection are:

ClientHello ----------->ServerHello

<----------- ServerHelloDone

ClientKeyExchange

ChangeCipherSpec

Finished -----------><----------- Finished

Application Data <----------> Application Data

5.1.2 Class 2: Server Authentication

In these types of connections, the server will show it’s identity by sending it’s certificate to the client during the handshake process while establishing a secure session. The client (mobile) will check for the validity the certificate sent by the server using a root certificate present in the mobile. It will also check whether the certificate is trusted or not.Once the server certificate is verified, the secure session will be established.

The sequences of steps that occur in a Class 2 secure connection are:

ClientHello ----------->ServerHelloCertificate

<----------- ServerHelloDone1. Verify Server Certificate

ClientKeyExchange 2. Establish session keyChangeCipherSpecFinished ----------->

<----------- Finished Application Data <----------> Application Data

5.1.3 Class 3: Client and Server Authentication

In these types of connections, both the client and the server will validate each others identities by exchanging the certificates. Once the validity of both the certificates is checked, the Class 3 secure session will be established.

The sequences of steps that occur in a Class 3 secure connection are:

Client Hello ----------->ServerHello CertificateCertificateRequest

<----------- ServerHelloDone1.Verify Server Certificate Certificate

ClientKeyExchange (only for RSA) 2. Establish Session keyCertificateVerify

3. Verify Client Certificate ChangeCipherSpec

Finished -----------><----------- Finished

Application Data <----------> Application Data

6 Feasibility of WAP Security testing

It is possible to establish only class 1 and class 2 connections using the currently available lab setup.

To establish and test the Class 3 connections any one of the following criteria should be met:

1. The mobile should have pre-installed client certificates in it (or)2. WIM is needed to generate the client certificates.Since the mobiles do not come with pre-installed client certificates and WIM is not available, testing of Class 3 connections is not feasible at Offshore.We can test this with Test WIM cards, but then these need a network simulator like the CRTU-G

7. Establishing WTLS Connections

7.1 Class 1 WTLS connection

7.1.1 Settings to be made in the Gateway to establish WTLS connection:

To test WTLS, Nokia Active Server Manager should be configured on the Gateway machine and the support for secure sessions should be enabled in it.

Ethereal protocol analyser should be running on the Gateway machine

7.1.2 Settings to be made in the mobile to establish WTLS connection:

In the WAP account settings:1. Port number should be set to 92032. Gateway should be set to the IP of the Gateway machine (i.e. 10.145.52.60) on

which Nokia active server is running.3. No WTLS server or root certificates of the Nokia gateway present in the mobile

Access a page from the server using the above mentioned settings

The page is loaded on the browser. A secure session icon is shown on the top right hand side of the page indicating that a secure session is established.

The details about the established secure sessions can be observed from the “Page Information” and “Certificate” dialogs.

The “Page Information” dialog displays the algorithms used in establishing the secure connection.

The above figure shows that the WTLS algorithm is used for encryption. Key Exchange is done using the RSA 512 bit algorithm; the strength of this WTLS connection is medium. The integrity of the received data is checked using SHA_80 algorithm.

The “Certificates” dialog contains the information “Server anonymous” in the server tab and “User anonymous” in the user tab.

This indicates that a WTLS class 1 connection is established.

7.2 Class 2 WTLS connection

To test the Class 2 WTLS sessions, a WTLS Server certificate and a WTLS root certificate should be created.

These certificates can be created using the Nokia Active Certificate tool

7.2.1 Using Nokia Active Server Certificate Tool

Click on “Create” if you want to create and install a self-signed server certificate.Click on “CSR” if you want to request a signed certificate from a CSR.Click on “Install” if you want to install a server certificate signed by a CA

7.2.2 Creating a CSR using Nokia Active Server Certificate Tool

1. Open the Nokia active Certificate tool2. From the Certificate Tool dialog, click on CSR which opens the Create Certificate

Signing Request dialog where you can enter the required certificate information in the boxes:

3. Enter the Service Name, which is the Organisation Unit. This is the WAP service name for example Customer Support.

4. Enter the Organisation or the Company Name. 5. Enter the Country which is a two-character ISO country name, e.g. United

States=US. 6. Enter the Common Name, which is the address of your Nokia Active Server.

Type either the host name or the IP address. 7. Extensions are optional and not normally used so it can be skipped. 8. Select the Key Length to indicate the key length of the public and private key that

the new signed certificate supports. 9. Enter the Certificate Signing Request File Name that will contain the signing

request. Clicking Browse opens the Save As dialog, where you can type the name of the new file and select the desired directory.

10. Leave the Name Character Set field as the default value 4, which means the iso-8859-1 (Latin-1) character set is used. You should not change this default value unless you are sure that the user's terminals also support other character sets.

11. Click Create to create the certificate signing request (CSR) file you specified as well as the corresponding private key file

The CSR can be sent to the CA by mail or by copying it’s contents into a webpage.

7.2.3 Installing Signed Server Certificate created by a CA

Clicking “Install” copies the server and root certificates in the Nokia Active Server certificate directory. However before the server certificate is brought to use the program checks if the corresponding private key is present in the server.

If the server certificate is not found then the “Select Private Key” dialog is shown listing all the available private keys.

7.2.4 Creating a Self-signed Server certificate

1. Open the Nokia active Certificate tool2. From the Certificate Tool dialog, click on Create which opens the Create

Certificate dialog where you can enter the required certificate information in the boxes:

3. Enter the Service Name, which is the Organisation Unit. This is the WAP service name for example Customer Support.

4. Enter the Organisation or the Company Name. 5. Enter the Country which is a two-character ISO country name, e.g. United

States=US. 6. Enter the Common Name, which is the address of your Nokia Active Server.

Type either the host name or the IP address. 7. Extensions are optional and not normally used so it can be skipped.

8. Select the Key Length to indicate the key length of the public and private key that the new signed certificate supports.

9. Leave the Name Character Set field as the default value 4, which means the iso-8859-1 (Latin-1) character set is used. You should not change this default value unless you are sure that the user's terminals also support other character sets.

10. Click Create to create the server certificate files and the corresponding root certificate files.

Once the Server certificate is created, the corresponding root certificate is also be generated automatically.

Import the created Server Certificate into the Nokia Active Server.

Download the root certificate into the EUT and install it.

Now start Ethereal protocol analyzer on the Gateway machine and access a page from the Server.

A secure session is established. Secure session icon is shown on the top right side of the page. Open the Page information and check the Algorithms field.

WTLS is listed indicating that a WTLS connection is established.

Open the Certificates dialog and tap on the “Server” tab. The details of the server certificate used to establish the WTLS session is listed. The User tab shows “User anonymous” indicating that no client certificates are used to establish the connection. This indicates that a WTLS Class 2 session is established.

7.2.5 Ethereal trace for Client Hello Message in the WTLS session

The above picture shows the ethereal trace for the Client Hello message in aWTLS class 2 connection.

The client hello message is sent to the server and it lists the various key exchange algorithms, Cipher Suites, and Trusted Keys that are supported by the EUT.

7.2.6 Ethereal trace for Server Hello message in a WTLS session

The server sends it’s server certificate during the Server Hello done message and a WTLS class 2 session will be established.

8 Establishing TLS Secure sessions X.509 certificates should be used to establish TLS connections. These certificates can be created using the Openssl tool.

The server has to be configured with Apache and Openssl.

Using the following mentioned Openssl commands, the Server and the root certificates can be generated.

8.1 Procedure to create Server certificates using Openssl

1. Generate a key pair for a CA

Openssl genrsa -out RSA1024CACERT.key 1024

2. Generate a new request for a certificate

Openssl req -new -key RSA1024CACERT.key -out RSA1024CACERT.csr -config myssl.cnf

When asked for the certificate details, accept the default values for all the entries by hitting enter. When asked the common name, specify the name www.wipro.com.

3. Create a CA certificate

openssl x509 -in RSA1024CACERT.csr -out RSA1024CACERT.cert -req -signkey RSA1024CACERT.key -extfile myssl.cnf -extensions v3_ca -days 1000 (1000 indicates the number of days the certificate is valid).

The file you create here RSA1024CACERT.cert, is the CA certificate and the related private key for this certificate is RSA1024CACERT.key

4. Create a windows recognizable format of the certificate RSACACERT.cert

Openssl x509 –in RSA1024CACERT.cert –out RSA1024CACERT.der.crt -outform DER

If you double click on RSA1024CACERT.1024.der.crt in Windows, windows will open the certificate and display the details to you.

5. Create a key pair for the server certificate

Openssl genrsa -out RSA1024SVRCERT.key 1024

6. Open the myssl.cnf file, and go to the 10th line. The line should be " extensions= v3_ca". Comment this line by placing a # in the front. Uncomment the next line by removing the # in the front of the line.

7. Create a request for the server certificate.

Openssl req -new -key RSA1024SVRCERT.key -out RSA1024SVRCERT.csr -config myssl.cnf

When asked for the certificate details, accept the default values for all the entries by hitting enter. When asked the common name, specify the server IP address where you are going to use the certificate.

8. Create a certificate for the server by signing it with the CA key.

Openssl x509 -in RSA1024SVRCERT.csr -out RSA1024SVRCERT.cert -req -CA RSA1024SVRCERT.cert -CAkey RSA1024CACERT.key -CAcreateserial -extfile myssl.cnf -extensions usr_cert -days 1000

The file you create here RSA1024SVRCERT.cert, is the server certificate and the related private key for this certificate is RSA1024SVRCERT.key

9. Create a windows recongisabe format of the certificate

Openssl x509 -in RSA1024SVRCERT.cert -out RSA1024SVRCERT.der.crt -outform DER

If you double click on RSA1024SVRCERT.der.crt in Windows, windows will open the certificate and display the details to you

10. Apache configuration

Copy the RSA1024SVRCERT.cert, RSA1024SVRCERT.key to the directory where you have the certificates for apache.

Modify the SSLCertificateFile and the SSLCertificateKeyFile directives to point to this certificate and key file.

13. Open mime.types file under the conf directory in apache, and see if you have any associated mime type listed for .crt.

If the mime type for .crt file is not listed, then add the line application/x-x509-ca-cert crt

Save the file. Restart apache.

Install RSA1024CACERT.der.crt file into the EUT and connect to the server.

Creating X509 Client certificates

1.  Create a client private key (clienttest.pk8) of DER format  openssl genrsa -out clienttest.pem 1024openssl pkcs8 -nocrypt -topk8 -inform PEM -outform DER -in clienttest.pem -out clienttest.pk8 2. Import the private key clienttest.pk8 into the EUT. 3. Create  the corresponding client cert (clienttestcert.der) using the following commands (The necessary root cert ca.der is already present in the EUT). (The following settings should be done in the configuration file before creating the client certificate extensions = usr_cert

 In the [usr_cert] extension, following values are setbasicConstraints=critical,CA:FALSEnsCertType = client, email keyUsage = nonRepudiation, digitalSignature, keyEncipherment) openssl req -new -key  clienttest.pem -out  clienttest.csr -config myssl.cnf openssl x509 -in  clienttest.csr -out  clienttestcert.pem -req -CA ca.cert -CAkey ca.key -CAcreateserial -extfile myssl.cnf -extensions  usr_cert -days 365openssl x509 -in clienttestcert.pem -out clienttestcert.der  -outform DER Creating an X509 Client cert of PKCS#12 format:

1.Generate the client’s private/public keypair:openssl genrsa –des3 -out clientkey.key 1024

2. Generate the client’s certificate signing request (CSR):openssl req -new -key clientkey.key –config openssl_config.txt –out clientcsr.csrFill in the following fields with your info:Country [ ]:State or Province [ ]:Locality [ ]:Organization Name [ ]:Organizational Unit Name [ ]:Domain Name [ ]:test@email.address [ ]:

Set the following properties in openssl cnf file.subjectAltName = email:[ ]basicConstraints = critical,CA:FALSEnsCertType = client,emailnsComment = "This certificate was issued for testing purposes"- Save the file as: \certs\clientext.txt

4. Sign the client’s CSR with the CA and apply the extension file:- OpenSSL> x509 -req -days 365 -CA \certs\cacert.pem –CAkey \certs\cakey.key -CAcreateserial–in \certs\clientcsr.csr –extfile \certs\clientext.txt –out \certs\clientcert.pem- Enter the passphrase used to protect the CA’s key.

5. Convert the client’s key and certificate into PKCS#12 format:- OpenSSL> pkcs12 -export -clcerts -in \certs\clientcert.pem –inkey \certs\clientkey.key –out\certs\clientpkcs12.pfx- Enter the passphrase used to protect the client’s key.- Enter a complex export passphrase, and enter it again to confirm.

8.2 Configuring TLS sessions

To establish TLS sessions, Apache should be running on the Server machine and the “httpd.conf” should be configured accordingly to cater the various needs and pre-requisites of the test cases.

The directive LoadModule ssl_module modules/mod_ssl.so should be enabled in order to allow SSL/TLS sessions on Apache.

8.2.1 SSL directives in ModSSL (Apache)

SSL Protocol

This directive mentions the SSL protocol to be used by Apache in order to establish SSL sessions.

Eg: SSL Protocol ALL – This directive enables all the protocols available in the Openssl and the protocol having the highest

priority will be used,When all the protocols are enabled, Apache uses the latest protocol. Hence TLS protocol will be used and TLS sessions will be established.

SSLCipherSuite

This directive describes the cipher suite used for establishing SSL sessions.

SSLCipherSuite ALL – Indicates all the cipher suites can be used to establish secure sessions.

To use only a particular cipher suite while establishing the sessions, use

SSLCipherSuite RSA-RC4-MD5 (Key Exchange – Encryption – Integrity)

The different Cipher Suites that can be used are:

Key Exchange Algorithm: RSA or Diffie-Hellman variants.

Authentication Algorithm: RSA, Diffie-Hellman, DSS or none.

Cipher/Encryption Algorithm: DES, Triple-DES, RC4, RC2, IDEA or none.

MAC Digest Algorithm: MD5, SHA or SHA1.

SSLSessionCache

This directive describes the type of the global/inter-process SSL Session Cache

Example: SSLSessionCache none - disables the global/inter-process Session Cache.

Example: SSLSessionCache dbm: /usr/local/apache/logs/ssl_gcache_data - Enables Session cache and describes the location where the cache file will be stored.

SSLVerifyClient

This directive sets the Certificate verification level for the Client Authentication. The following levels are available for level:

none: no client Certificate is required at all optional: the client may present a valid Certificate require: the client has to present a valid Certificate optional_no_ca: the client may present a valid Certificate

but has not to be (successfully) verifyable.

SSLSessionCacheTimeout

This directive sets the timeout in seconds for the information stored in the global/inter-process SSL Session Cache and the

SSLeay internal memory cacheExample: SSLSessionCacheTimeout 600

SSLLog

This primitive describes the name of the dedicated SSL engine log fileExample: SSLLog logs/SSL.logExample: SSLLog none – No log file will be created for the SSL Engine.

SSLLogLevel

This directive sets the verbosity degree of the dedicated SSL protocol engine logfile

Noneno dedicated SSL logging is done, but messages of level ``error'' are still written to the general Apache error logfile.

Errorlog messages of error type only, i.e. messages which show fatal

situations (processing is stopped). Those messages are also duplicated to the general Apache error logfile.

Warnlog also warning messages, i.e. messages which show non-fatal problems (processing is continued).

Infolog also informational messages, i.e. messages which show major processing steps.

Tracelog also tace messages, i.e. messages which show minor processing steps.

Debuglog also debugging messages, i.e. messages which show development and low-level I/O information.

SSLCertificateChainFile This directive points to the SSL Certificate Chain fileExample: SSLCertificateChainFile"C:/Apache/conf/ssl.crt/ca.crt”

Access a page from the server (with TLS configured). The TLS session is established and the page is loaded into the EUT.

8.2.2 Ethereal trace for Client Hello message in a TLS session

In the Ethereal trace under the Secure Sockets Layer, the record layer for the Client hello message is shown as TLS Record Layer.

8.2.3 Ethereal trace for Server Hello Message in a TLS session

Once the secure session is established, have a look at the Page information in the mobile.

The Algoritms field should list TLS indicating that the secure session is created using TLS protocol.

In the certificates dialog will have the server and the client tabs.

The Server tabs displays the server certificate information where as the client tab displays the text “User anonymous”.

9 Establishing SSL connections using IIS server

To establish SSL sessions, SSL server certificate should be generated, and imported into the server.

The SSL server certificate can be obtained in two ways:

1. Create an SSL Server certificate using OpenSSL Commands and import them into IIS Server

2. Create a Certificate request, process it, create a server certificate and install it into the IIS Server

Use the openssl commands mentioned above to create the SSL server certificates and their keys.

9.1 Importing the server certificate into the Certificate console1. In the IIS server machine, click the Start Button then select Run and type mmc

(Microsoft Maanagent Console).2. Click Console and select Add/Remove Snap in 3. Select Add, select Certificates from the Add Standalone Snap-in box and click

Add

4. Select Computer Account from the “Certificates Snap-in” and click Finish5. Close the Add Standalone Snap-in box, click OK in the Add/Remove Snap-in6. Expand the Certificates entry in the MMC and right click the Trusted Root

Authorities, select All Tasks, select Import.7. Using the Import wizard import the certificate into the Certificates console.

Import the server certificate into Personal console also.

Now, open the IIS Server and right-click on it.

Select the “Properties” option.

Open the “Directory security” and tap on the “Server Certificate” button.

Select the option “Assign an existing certificate” and tap on “Next”.

The list of certificates available for installation in the IIS Server is listed.

Select the newly created certificate and tap on “Next”.

Once the certificate is installed, select the directory, for which security settings are to be made,

Select the properties option for this directory and enable SSL Connections.

Once this is done, the user will be able to establish secure sessions with the IIS server.

9.2 Creating a server certificate from the Internet

Request a certificate for a web server

Before you can use SSL, you have to first install a certificate on your IIS web server.

1. In IIS, right-click on the site you want to secure.2. Select Properties

The “Website properties” dialog is shown.3. Select the “Directory Security” tab, and click on “Server Certificate”

The “Welcome to web server certificate wizard” is shown.

4. Click “Next” and select “Create a New Certificate” 5. Select “Prepare the Request Now, But Send It Later” and click “Next“6. Type a name for the certificate and bit length, and then click “Next”. 7. Type your organizational name and organizational unit in the box provided and

click “Next”. 8. Enter your Web server name and click “Next”. 9. In the next dialog box, provide some geographical information and click “Next”. 10. Enter the location and the name for the certification request and then click “Next”. 11. Verify the information and click “Next”, and then click Finish. 12. Open the “Certificate Wizard” again and choose to submit the created certificate

request.13. Open the certificate request file you created previously, copy and paste its

contents into the form provided, and click Submit. 14. In the “Administrative Tool” folder, open the “Certification Authority” console,

and select “Pending Requests” 15. Right-click the pending certificate and select “All Tasks”, and select “Issue”.16. Select “Check on a Pending Certificate”, and click “Next”. 17. Select the certificate and click Next 18. Select DER Encoded, and click Download CA Certificate 19. Select a folder in which to store the certificate, and click Save

9.3 Import the certificate into IIS

1. Go back to the Internet Services Manager console 2. Right-click the site and select Properties 3. In the Directory Security tab, click Server Certificate 4. Select “Process the pending Request and install The Certificate” and click Next.

5. Type the path to the CA response file you saved and click Next

6. Verify the information and click Next, and then click Finish.

9.3 Changes to be made in the Registry:

Go to the path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\ TLS 1.0 \Server.

Create a DWORD, Set its name to Enabled and its value to 0xffffffff.

Now establish an SSL session by connecting to the server and download a page from the server.

9.4 Ethereal traces for Client Hello message in SSL session:

Client Hello message during SSL Session establishment

9.5 Ethereal trace for Server Hello Message in SSL session:

In the EUT, the type of secure session established can be known by observing the page information.

The Algorithms field shows that an SSL secure session is established.

Open the “Certificates” dialog.

The server certificate used to create SSL sessions can be seen in the Server tab, The “User” tab will display the text “User anonymous” indicating that no client certificates are used to establish the SSL session.

10 Abbreviated Handshake in secure sessionsAll the sessions that are established till now are secure sessions created using Full Handshake procedure.

Abbreviated handshake uses the session ID of the previously created session. Hence an already existing session will be used instead of creating a new secure session.

10.1 Creating Abbreviated Handshake sessions

To establish a WTLS abbreviated handshake session, the SSLSessionCache primitive should be enabled in the httpd.conf file.

Access a page from the server using the secure WTLS, TLS or SSL session.

Capture a trace at the Gateway (if the established session is a WTLS session) or at the server (if the established session is a TLS or SSL session).

Observe the Ethereal trace.

When a new session is created initially, the Client Hello message will have the Session ID length and value as 0, indicating that it is a new session.

The Server Hello message will assign a Session ID of length 32 bytes to the newly created session.

Disconnect the session and try to connect to the server again.

Now the Client Hello message has a session ID.

Observe the value of session ID shown in the above and in the previous figure.The SessionID values of both the sessions are the same, indicating that the second TLS connection is using an already existing session. This is known as abbreviated Handshake process in security sessions.

11 Abbreviations and Acronyms

EUT Equipment under TestWTLS Wireless Transport Level SecuritySSL Secure Sockets LayerTLS Transport Level Security

----------------------------------- End of the Document --------------------------------------------