Page 1 of 3

An Introduction to PKI and SSL [ID 264080.1] Modified 13-JAN-2011 Type WHITE PAPER Status PUBLISHED

Applies to:
Oracle HTTP Server - Version: 1.0.2 and later [Release: 9iAS and later ] Oracle Fusion Middleware - Version: 1.0.2.0.0 and later [Release: 9iAS and later] Oracle HTTP Server - Version: 1.0.2 and later [Release: 9iAS and later] Information in this document applies to any platform.

Abstract
In order to understand how the Secure Sockets Layer Protocol (SSL) works, it is necessary to understand the fundamental concepts of Symmetric Encryption and Public Key Infrastructure (PKI). All of these technologies are used in SSL. This article aims to outline these concepts.

An Introduction to PKI and SSL Abstract

In order to understand how the Secure Sockets Layer Protocol (SSL) works, it is necessary to understand the fundamental concepts of Symmetric Encryption and Public Key Infrastructure (PKI). All of these technologies are used in SSL. This article aims to outline these concepts.

Introduction
SSL uses PKI and Symmetric Key Technologies. It uses Symmetric Encryption, Public/Private Key (Asymmetric) Encryption, and Digital Signatures.

Symmetric Encryption
Both parties in the conversation use the exact same symmetric keys for encryption and decryption. The symmetric key is kept secret between both parties All data is encrypted into a cipher using the symmetric key and transmitted over the network. The recipient takes the cipher and decrypts it using the same symmetric key How the symmetric key is generated on both sides of the conversation is dependant on the Key Exchange Algorithm Examples of Symmetric Key Excahnge Algorithms are RSA and Diffie Hellman All Browsers use RSA Key Exchange Algorithm when exchanging Symmetric Keys Products like Advanced Security Option for Oracle Net can use RSA or Diffie-Hellman for key exchange Each symmetric key uses a Symmetric Key Encryption Algorithm. The most common Encryption Algorithms are: RC4 and DES The longer the key the more secure the data and RC4 and DES can encrypt at different key lengths RC4 can encrypt at 256, 126, 56, and 40bits - DES can encrypt at 3DES168, 3DES112, 56 and 40 bits Advantages: Extremely quick encryption and decryption Disadvantages: Key deployment is complex

PKI Encrpytion
Different to symmetric encryption in that both parties in the conversation have their own individual private and public key pair. What one key does the other key undoes i.e if you encrypt with the public key you decrypt with the corresponding private key. Encryption always uses the recipients public key i.e if a client wishes to send data to the server, it encrypts it with the servers public key. The servers private key is then used to decrypt it The private key must be kept private and nobody but the owner should have access to it Public and Private Keys are always generated using one algorithm (RSA) Public/Private Keys have a key length also. The longer the key the stronger the encryption Common key lengths (strongest first) are: 2048, 1024, 512bits In Internet SSL connections, the most common public key length is 1024bits Also known as 'Asymmetric Encryption' Advantages: Key deployment is easier Disadvantages: Encryption/Decryption is extremely slow. Everyone wishing to have a conversation would have to have their own public/private key pair Note: Bulk Encryption with private/public keys never happens in reality due to slowness and the fact everyone has to have a public/private key pair. It is only ever really used for performing authentication and symmetric key exchange. See the later SSL section.

Digital Signatures
Digital Signatures determine the authenticity of the message i.e has it been tampered with it.The data to be sent is put through a one way hash algorithm to produce a Digest The digest is then encrypted using the encryption key to produce a Digital Signature The recipient takes the Digital Signature and decrypts it using the relevant key to produce the Digest The recipient takes the original data and puts it through the same algorithm the sender used, to produce a Digest The recipient compares the two digests, and if they match then the message has not been tampered with The most common One-Way Hash Algorithms are MD5 and SHA1

Certificates
If using public/private keys, how do we know if the public key we have received is from the server itself or from elsewhere? Some method of authentication is needed and Certificates provide this A certificate is a means by which a client or server can identify the third party with whom it is having a conversation To prove the server is who it says it is, it has a Certificate, which associates its public key with the real identity of the server itself. A certificate includes the following information: Subject Name - the owners distinguished name Subject's Public Key Issuer - the issues distinguished name CA's digital signature - a hash of all the data in the webservers certificate, encrypted with the CAs private key Certificate Validity Dates -when the certificate is valid from, and its expiry date Administration information - Version/Serial Number Extended information - constraints, browser flags etc So if a browser connects to https://www.oracle.com, the contents of the certificates are as follows: Subject Name: "CN = www.oracle.com, OU = Global IT, O = Oracle Corporation, L = Redwood Shores ,S = California, C = US" Subjects Public Key: RSA (1024 Bits) Issuer: OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US Signature Algorithm: sha1(RSA) Valid From: 16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=264080.1

2/7/2012

Page 2 of 3

Version: V3 Serial Number: 7731 4540 FD6E 1385 2512 6234 3A22 A271 Using all this information, the client can determine whether or not the public key in the certificate is from the server itself. A more indepth look into how a client uses these details can be found in the 'How an SSL Session is established section' More on types of Certificate later

Why does SSL use all these different types of technologies?

Symmetric Encryption/Decryption algorithms are extremely quick compared with Public/Private Key Encryption/Decryption Key Deployment is easier with Public/Private Keys than with Symmetric Keys Encryption does give message tampering protection to a degree, but not to the degree that Digital Signatures does Certificates allow us to associate an identity with a public key Using all these technologies we can harness the adavantages of each one for the most reliable, fast, secure connection

How an SSL Connection is established?

Lets say we want to access the following site via SSL: https://www.oracle.com The browser and web server establish the SSL protocol version, Ciphersuite, and a Session ID. The Protocol and Ciphersuite negotiated depends on the version of the browser and the web server used. SSL Protocol versions are SSLV2, SSLV3 and TLSV1, with SSLV3 being the most common. The SSL Ciphersuite outlines the following: The Key Exchange Algorithm - how the client and server exchange symmetric keys, i,e RSA or Diffie-Hellmann) The Symmetric Encryption Algorithm e.g. RC4 128bit or DES 56bit The Message Digest function i.e. MD5 (128bit), or SHA-1 (160bit) For the purposes of this explanation the negotiated Ciphersuite is RSA-RC4128-MD5 The server sends the certificate to the browser The browser takes the certificate, and checks via the trusted CA certificate that the certificate is valid. Remember that the certificate contains the validity date, DN of the Issuer CA, the webserver's public key and the CAs digital signature (i.e a hash of all the data in the certificate, encrypted with the CAs private key). Firstly the client checks that the certificate is valid as per today's date and the certificates validity period. In this case the validty dates are Valid From:16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59. At the time of writing the date is 23rd February 2004 , hence the certificate is valid. It then checks that the Issuer DN matches the DN on the clients list of trusted CAs certificates. These are stored in the browsers trusted certificate list. If it matches one of the trusted CAs certificates then we have proved that the issuing CA is trusted. In this case the certificate for www.oracle.com was issued by "OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US". As this is a common certificate provider it ships with most browsers by default. Next the digital signature is decrypted using the CAs public key, which it has as it is contained within the CA's certificate stored in the browser. Then the original certificate is put through the hash to produce a digest. If the two digests match we know that the certificate was issued by the trusted CA and has not been tampered with. Next, the Subjects Common Name (CN) from the Subjects DN, is checked against the hostname of the server where the certificate came from, to prove it came from the server. In this case we made a connect to http://www.oracle.com , so the browser checks the Subjects CN matches. As the certificate has "CN = www.oracle.com" then this test is passed If everything checks out, the browser can now trust that it has the servers public key. In this example all the tests succeed. If however it doesnt check out then the user is informed of the problem via a warning message. Lets say for example that the Certificate had expired, in this scenario the warning message would be displayed: "The security certificate is expired or not yet valid" Now the browser has the webservers public key, the browser requests that the server proves its identity again by sending a randomly piece of generated data for it to digitally sign. The server produces a digest of the data using the hash, encrypts it with its private key, and sends the digital signature. The browser receives the digital signature and decrypts it using the servers public key to produce a digest, and then puts the original random data though the hash algorithm to produce another digest. If the two digests match then the server has proven its identity. The browser and server then exchange symmetric encryption keys using the Key Exchange Algorithm (KEA) defined in the negotiated ciphersuite. In our example the negotiated KEA was RSA . At this point the SSL Handshake is complete and these symmetric keys are then used to encrypt and decrypt data over the session using the encryption algorithm negotiated at the beginning of the session i.e RC4128 Any data transmitted is also put through the negotiated hash algorithm (MD5) to prevent tampering

More on Certificates
Server Certificates can be obtained from many online vendors, or software can be bought or downloaded that allows you to generate you own certificates e.g: OpenSSL. As there are many different vendors it is impossible to go through what everyone calls their server certificates, so we will outline the ones issued by two of the main Interent vendors: Verisign and Thawte. Server Certificates: There are 2 major types of server certificates, and their marketing name varies depending on the Certificate Authority issuing the certificate. 1. Global Server ID's (GSID) (issued by Verisign) Global Server Certificates, sometimes known as Server Gated Cryptography or 128bit certificates, are certificates that enable all browsers to use 128bit symmetric encryption, even if the browser is an Export browser where only 40bit symmetric encryption is allowed. A GSID usually has two parts, the certificate itself, and an extra intermediate certificate, which is used to provide the step-up. This is useful because of past export regulations where only Export browsers could be used outside the US. Now export regulations are relaxed new browsers can use 128bit encryption world-wide. As outlined earlier the names of these certificates vary. Thawte for example, calls these certificates 128bit SuperCerts. These types of certificates should not be necessary at this point in time as all the latest browsers support 128bit symmetric encryption. 2. Secure Server Certificates (issued by Verisign) These are sometimes called 40bit certificates. However, they will allow 128bit bulk encryption or higher if both the web server and client browser support 128 bit symmetric encryption or higher. This sounds illogical but it is down to the ciphersuites used for generating the symmetric key. Thawte calls these certificates SSL Certificates. In reality there is no such thing as a 40bit or 128bit certificate. They both support the same levels of encryption, its just that GSIDs will allow old export type browsers to use SSL Symmetric Encryption at 128bit. The certificates can be said to have a key size, but it refers to the length of the public key contained in the certificate (I.e 512/1024/2048 bits). The names of the Certificates were chosen purely for marketing reasons. Client Certificates: In most Internet applications the server sends a certificate to the client for the purposes of server authentication. In SSL it is also possible for a server to ask a client to authenticate itself to provide extra security. This is not common practice in most Internet applications, but is common in web based Intranet applications. In this scenario, both the client and server both have a certificate, and the server will perform the authentication against the client as well. If client authentication is desired, then a client certificate needs to be issued for your browser/application. These are available via Internet vendors like Verisign or Thawte, and also using commercially avalaible software like Oracle Certificate Authority, Netscape Certificate Server, RSA Keon Server. If a browser is used, then the private key for the corresponding client certificate is stored within a browser database usually protected with a password. If using somebody like Versign or Thawte for the client certificates, then all the private key generation is performed by a combination of the browser and the Web site. During generation you will be asked for a PIN which you will need to enter when you make a SSL connection if the server requires client authentication. Client certificates are sometimes referred to as Personal Certificates. Client certificates contain the same information as a server certificate, however they do not have a User Common Name (CN). Instead, they tend to have this attribute set to your full name or email address. When a server authenticates the client, it therefore does not do validation against a hostname.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=264080.1

2/7/2012

Page 3 of 3

Oracle Application Server (9iAS, 10G) and Fusiom Middleware 11g Support
This sections outlines what types of certificate, SSL Protocol, HTTP Server modules, supported within HTTP Server with different versions of the Application Server. Certificates: 1.0.2.X* 9.0.2 9.0.3 Server Certificates Global Server ID's** Client Certificates Y Y Y Y N Y Y N Y 9.0.4.X (10GR1) Y Y(1) Y 10.1.2(10GR2) Y Y(2) Y 10.1.3(10GR3) Y Y Y
11.1.1.X (FMW11g) Y Y Y

* Includes versions of OHS shipped with Oracle RDBMS 8.1.7, and 9.X ** Includes any Vendors certificates that upgrade encryption in old export browsers 1) 9.0.4.3 must be installed for GSID to work 2) 10.1.2.3 must be installed for GSID to work Protocols: 1.0.2.X* 9.0.2 9.0.3 9.0.4 10.1.2 (10GR1) (10GR2)*** ** N Y N Y Y Y 10.1.3 (10GR3) Y Y Y
11.1.1.X (FMW11g) N Y Y

SSL V2.0 SSL V3.0 TLS V1.0

Y Y Y

N Y N

N Y N

* Includes versions of OHS shipped with Oracle RDBMS 8.1.7, and 9.X ** Includes versions of OHS shipped with 10.1 RDBMS. *** Includes versions of OHS shipped with 10.2 RDBMS Note that in the above, the SSLProtocol ALL directive also supports SSLV3_V2H i.e SSLV3 with a SSLV2 Client Hello OHS Directive: SSLProtocol 1.0.2.X* 9.0.2 9.0.3 9.0.4 10.1.2 10.1.3 11.1.1.X (10GR1) (10GR2) (10GR3) (FMW11g) ** *** N Y N Y N Y
N Y****

MOD_SSL/OPENSSL MOD_OSSL/OWM

Y N

N Y

N Y

* Includes versions of OHS shipped with Oracle RDBMS 8.1.7, and 9.X ** Includes versions of OHS shipped with 10.1 RDBMS *** Includes versions of OHS shipped with 10.2 RDBMS **** FMW 11g supports many different ways of generating a Wallet - See Note 1218603.1 Understanding Wallets and Keystores in Fusion Middleware 11g OWM - Oracle Wallet Manager

Summary
SSL uses a combination of symmetric encryption and PKI technologies to provide authentication, encryption and message authenticity. Certificates are used to ensure that a public key recevied is from the entity that sent it. There are different types of server certificates and different vendors give them different names. Oracle Application Server supports a number of SSL Protocols, and Ciphersuites and HTTP Server can be configured to use them if that version supports them @ This article is adapted from Russ Hodgson's "Introduction to PKI and SSL" presentation. presentation here

References
BUG:10185543 - TLS1.1 & TLS1.2 WEBCACHE CONNECTIONS FAILED WHEN RE-NEGOTIATE DOWN TO LOWER VER NOTE:1218603.1 - Understanding Wallets and Keystores in Fusion Middleware 11g NOTE:1218695.1 - Master Note for SSL Configuration in Fusion Middleware 11g NOTE:1275428.1 - Support Status for SHA2 Certificates in Oracle Application Server (10.1.2.X.X) and Fusion Middleware 11g (11.1.1.X) NOTE:1281035.1 - Master Note for SSL Configuration in Oracle Application Server 10g (10.1.2 - 10.1.3)

Related

Products Middleware > Application Servers > Oracle Application Server > Oracle HTTP Server Middleware > Application Servers > Oracle Application Server > Oracle Fusion Middleware Middleware > Application Servers > Oracle Application Server > Oracle HTTP Server Keywords CERTIFICATE; SSL; ENCRYPTION; OHS; AUTHENTICATION; PRIVATE KEY; DES; SECURE; KEY EXCHANGE ALGORITHM

Back to top Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=264080.1

2/7/2012