02/28/2006

SSL (Secure Socket Layer)

This session is about how to use SSL for deploying web applications securely over Tomcat. By deploying web applications securely using SSL, I mean two specific things. First, data confidentiality between browser and the web server. For example, if you are sending sensitive information such as your credit card number to a web server, you want to make sure nobody can read it while it is being transported on the wire. As we talked about in Web application Security session, SSL can be used to achieve this data confidentiality. The second thing I am talking about is client certificate authentication. Again here SSL can be used.

02/28/2006

Sang Shin sang.shin@sun.com www.javapassion.com/j2ee

Technology Evangelist Sun Microsystems, Inc.

02/28/2006

Disclaimer & Acknowledgments

?

Even though Sang Shin is a full-time employee of Sun Microsystems, the contents here are created as his own personal endeavor and thus does not reflect any official stance of Sun Microsystems. Sun Microsystems is not responsible for any inaccuracies in the contents. Acknowledgments All examples in this presentation is from Java WSDP
3

02/28/2006

Revision History
? ?

01/22/2002: version 1, contents created with speaker notes (Sang) 10/26/2004: version 2, slides of JSSE are added (Sang)

02/28/2006

Agenda
? ? ? ?

What is SSL? What is Certificate? SSL support in Tomcat Steps of Installation/Configuration of SSL HTTPS Connector over Tomcat Browser and Certificates

So this is what we are going to talk about in this30 minutes session. First, we will talk about what SSL is first, then we will talk about what a certificate is. We already talked about what a certificate is in Security Basics presentation. So this is a bit of rehash. SSL uses public/private key scheme and understanding what a certificate is as a container of a public key and other information is important to understand SSL. Then we will talk about how SSL can be supported over Tomcat and go over the steps you will take in order to install and configure SSL connector. And then we will talk about how a browser recognizes and maintains server certificates that it receives when it accesses the SSLprotected web page. If you don't understand what I am talking about right now, don't be concerned. We will go over each of these topics in rather detail in this presentation, and you will have relatively good understanding on these at the end of this presentation.

02/28/2006

What is SSL?
6

So let's talk about what SSL is first.

02/28/2006

SSL (Secure Socket Layer)

SSL stands for Secure Socket Layer. The primary security service SSL provides is protection of data while the data is on the wire. That is, the data can be sent over the wire in encrypted form using SSL, thus provides data confidentiality.

02/28/2006

Secure Socket Layer (SSL)

?

By far, the dominant security technology on the web Transport layer security

HTTPS is HTTP over SSL

Responsible for the emergence of e-commerce, other security sensitive services on the web Beneficiary of several years of public scrutiny

SSL is the dominant security technology especially over the web. Pretty much all secure communications over the web is based on SSL. SSL is transport layer security over TCP/IP. So any TCP/IP application can be protected by using SSL. For example, FTP communication or Telnet or HTTP communication can be protected by using SSL. By the way, you might have heard HTTPS. It stands for HTTP over SSL. SSL is so popular on the web right now and I would even claim SSL is partly responsible for the emergence of e-commerce and other security sensitive services over the web. Well.. SSL has its own limitations, however, especially under the context of web services. But for now, SSL is the only option for doing any kind of sensitive transactions over the web. And SSL has gone through many years of usage and pretty much all the products out there support it.

02/28/2006

SSL runs over TCP

source:java.sun.com

02/28/2006

Why SSL? SSL Provides ...

? ? ?

Confidentiality (Privacy) Data integrity (Tamper-proofing) Server authentication (Proving a server is what it claims it is)

Used in typical B2C transaction Would be required in B2B (or Web services environment in which program talks to program)
10

Optional client authentication

So what does SSL provide? First, as was mentioned, SSL provides confidentiality of the data while it is on the wire. We are talking about privacy or confidentiality of the data. SSL also supports data integrity, which is also called as tamper-proofing. This is done as part of digital signing. In a typical secure communication between your browser and the web server, for example, when you check out and ready to send your credit card number to a online shopping site, for example, amazon.com, the secure communication between the browser and the web server gets started with so-called server authentication. That is, when you are sending your credit card information to amazon.com, you want to make sure the amazon.com you think it is is really amazon.com. So server authentication proves the identity of amazon.com to your browser. Optionally, you can do client authentication. In this case, the server wants to make sure the client is what it claims it is. In a typical B2C environment, the server does not usually send any sensitive information to the browser so there is less need for proving the client identity. In B2B or Web services environment in the future, this will change.

10

02/28/2006

SSL and Security Keys

?

Uses public/private key (asymmetric) scheme to create secret key (symmetric) Secret key is then used for encryption of data

SSL operation is optimized for performance: Using symmetric key for encryption is a lot faster than using asymmetric keys
11

We talked about, during the session Security Basics presentation, how keys are used in the context of cryptographic process. We also talked about there are two key schemes: public/private key scheme and secret key scheme. The public/private key scheme is called asymmetric while secret key scheme is called symmetric. We also learned that public/private key operation is very expensive from the performance standpoint. Now SSL uses both public/private key and secret key schemes. We will see how these keys are created and used in the following slides. But basically SSL uses public/private key to create what is called a secret session key. And public/private key scheme is used for authentication while the secret session key is used for encryption.

11

02/28/2006

SSL Key Exchange (Simplified)

Server
12

This picture shows a simplified view on how SSL works. First, the client, in this case, the browser, accesses the web server. And we already learned during the Web application security session, how this secure communication gets started. The web server then sends its public key in the form of certificate. Please note that the certificate contains server's public key. After making sure the server's public key that it received is a valid one, the client then creates a so called a premaster key and encrypts it using server's public key and sends it to the server. Because the premaster key is encrypted with server's public key, only the server can decrypt it. The server then creates a secret session key which will be used for encrypting data for any further data exchange between the browser and the server. There is a few more things that happens in this handshake but this is basically the guts of SSL handshake.

12

02/28/2006

SSL Key Exchange Steps

1.SSL client connects to an SSL server 2.Server then sends its own certificate that contains its public key 3.Client then creates a random key (premaster key) and uses server's public key to encrypts it 4.Client then sends encrypted premaster key to the server 5.Server then decrypts it and uses decrypted premaster key to create secret session key 6.Now both client and server uses secret session key for further communication 13 So this is the repeat of what I just said in the previous slide. (Please read the slide.)

13

02/28/2006

Negotiable Encryption Algorithms

?

Not all clients and servers use same encryption and authentication algorithms SSL client and server negotiates encryption and decryption algorithms (cipher suites) during their initial handshake

Connection will fail of they do not have common algorithms

14

Among the features of SSL that have made it the de facto standard vehicle for secure e-commerce transactions is its support for negotiable encryption and authentication algorithms. The designers of SSL realized that not all parties will use the same client software and consequently not all clients will include any particular encryption algorithm. The same is true for servers. The client and server at the two ends of a connection negotiate the encryption and decryption algorithms (cipher suites) during their initial handshake. It may turn out that they do not have sufficient algorithms in common, in which case the connection attempt will fail

14

02/28/2006

SSL Handshake Protocol

15

1.ClientHello: The client sends the server information such as SSL protocol version, session id, and cipher suites information such cryptographic algorithms and key sizes supported. 2.ServerHello: The server chooses the best cipher suite that both the client and server support and sends this information to the client. 3.Certificate: The server sends the client its certificate which contains the server's public key. While this message is optional, it is used when server authentication is required. In other words, it is used to confirm the server's identity to the client. 4.Certificate Request: This message is sent only if the server requires the client to authenticate itself. Most e-commerce applications do not require the client to authenticate itself. 5.Server Key Exchange: This message is sent if the certificate, which contains the server's public key, is not sufficient for key exchange. 6.ServerHelloDone: This message informs the client that the server finished the initial negotiation process. 7.Certificate: This message is sent only if the server requested the client to authenticate itself. 8.Client Key Exchange: The client generates a secret key to be shared between the client and server. If the Rivest-Shamir-Adelman (RSA) encryption algorithm is used, the client encrypts the key using the server's public key and sends it to the server. The server uses its private or secret key to decrypt the message and retrieves the shared secret key. Now, client and server share a secret key that has been distributed securely. 9.Certificate Verify: If the server requested to authenticate the client, this message

15

02/28/2006

SSL and Encryption

?

You need only server's certificate in order to have encrypted data transfer

This is the reason why you don't need to install client certificate on your browser in order to send your credit card number securely

16

Now I just want to repeat a key aspects of SSL one more time so that you folks get clear understanding how it works. As mentioned before, SSL is used for both encryption and authentication. For encryption, you need a certificate from only one side. In a typical B2C communication, it is the server's certificate that is used. This is the reason why you can still send your credit card information to amazon.com even without installing client certificate on your browser.

16

02/28/2006

SSL and Authentication

?

Server authentication

Server needs to provide its own certificate to a client in order to authenticate itself to the client A Web server typically has a CA-signed certificate and it provides it to its clients Client needs to provide its own certificate to a server in order to authenticate itself to the server
17

Client authentication

Mutual authentication

Another important security service SSL provides is authentication. During your initial attempt to communicate with a Web server over a secure connection, that server will present your Web browser with a set of credentials in the form of a server certificate. The purpose of the certificate is to verify that the server is who and what it claims it is. Now in an internet environment, the server certificate is typically signed by well-know certificate authority such as Verisign. In some cases, the server may request a client certificate in order to verify that the client is who and what it claims it is and that is known as client authentication. And when both server authentication and client authentication are performed using certificates, it is referred as mutual authentication.

17

02/28/2006

SSL and Authentication

?

In a typical browser talking to web server communication, only server authentication is needed

When you send your credit card to a server, you want to make sure the server is who it claims to be

In the future of B2B environment, client certification would be also required

18

So just to repeat what has been said a couple of times already, in a typical browser talking to a web server B2C communication, only the server authentication occurs. In the future of B2B communication or Web services environment, where the difference between client and server would be blurring, both parties might have to authenticate themselves to the other parties, thus mutual authentication would be required.

18

02/28/2006

SSL and Web-tier Security

?

Encrypted password move from the browser to the web server Encrypted data move between the browser and the web server Server authentication

Done before encrypted data transfer occurs Not used in most cases
19

Client Authentication

Again, I added this somewhat repeating slide to make sure you really understand how things work between a browser and the web server. Between a browser and web server, any sensitive information should be encrypted. And examples of sensitive information include your password and credit card number. Server authentication has to occur before sensitive information gets transported from the browser to the server. And on the other direction, there is a less need for it in a typical B2C environment.

19

02/28/2006

Certificates & Keytool Utility

20

Now let's talk about how certificates are created and which tool you can use to create so called self-signed certificates.

20

02/28/2006

What is a Certificate?
? ?

A certificate is like digital driver license A certificate is cryptographically signed and is practically impossible for anyone else to forge A certificate can be purchased from (signed by) a well-known CA (Certificate Authority) like Verisign (for a fee) A certificate can be self-signed when authentication over the internet is not really a concern, that is only data privacy and integrity are important
21

A certificate is a digitally-signed statement from one entity (person, company, etc.), saying that the public key (and some other information) of some other entity has a particular value. So in a sense, it is like digital version of your ID card such as driver's license. The certificate is cryptographically signed and is practically impossible for anyone else to forge. For sites involved in e-commerce, or any other business transaction in which authentication of identity is important, a signed certificate can be purchased from a well-known Certificate Authority (CA) such as Verisign or Thawte. If authentication is not really a concern, in other words, you only wants data confidentiality via encryption, then you can save the time and expense involved in obtaining a CA certificate and simply use a self-signed certificate. This is very important aspect you want to make sure you understand.

21

02/28/2006

What is Server Certificate?

?

A certificate that contains information about the server

Server's public key Other misc. information

Web server must have an associated certificate for each external interface, or IP address, that accepts secure connections

HTTP service of Tomcat will not run unless a server certificate has been installed
22

So what is server certificate? A server certificate is a container that contains server's public key and other miscellaneous information. Now as I said several times already, in a typical B2C communication, only server authentication occurs. That is, the web server sends its own certificate to each browser that connects to it. So a web server must have an certificate for any externally exposed interface for example an IP address that accepts secure connections. In fact, this is the reason why you have to install SSL package and HTTPS connector to Tomcat, otherwise, no SSL operation would occur.

22

02/28/2006

Why Server Certificate is Needed?

?

Enables server authentication

Verifies the server's identity to the client Client would need to have an access to the server certificate Server sends server certificate as part of SSL key handshake HTTPS service of Tomcat would not work unless a server certificate is installed

23

Certificates are used with the HTTPS protocol to authenticate Web servers to clients. (There is incorrect information in Java WSDP regarding this. ) The HTTPS service of the Tomcat server will not run unless a server certificate has been installed. Use the procedure outlined in Java WSDP to set up a server certificate that can be used by Tomcat to enable SSL.

23

02/28/2006

keytool Utility
? ?

A key and certificate management utility Enables users to create and administer their own public/private key pairs and associated certificates Ships with JDK (Uses RSA-based JCE provider as default) Allows users to cache the public keys (in the form of certificates) of their communicating peers Stores the keys and certificates in a so-called keystore
24

One tool that can be used in order to set up a Tomcat server certificate is keytool, a key and certificate management utility. The keytool utility let you create a self-signed certificate among others things it lets you do. The keytool utility that ships with the J2SE SDK version also supports a Java Cryptographic Extension provider that has implementations of RSA algorithms. This provider enables you to import RSA-signed certificates. It also enables users to administer their own public/private key pairs and associated certificates for use in self-authentication (where the user authenticates himself/herself to other users/services) or data integrity and authentication services, using digital signatures. It also allows users to cache the public keys (in the form of certificates) of their communicating peers. The keytool stores the keys and certificates in a so-called keystore. The default keystore implementation implements the keystore as a file. It protects private keys with a password. For more information on keytool, read its documentation at http://java.sun.com/j2se/1.4/docs/tooldocs/solaris/keytool.html.

24

02/28/2006

SSL Support in Tomcat

25

Now let's talk about how SSL is being supported in Tomcat.

25

02/28/2006

SSL on Tomcat
?

You need the following modules

JSSE (Java Secure Socket Extension) Server certificate keystore An HTTPS connector

You have to install and configure SSL HTTPS connector over Tomcat

26

You only need to configure Tomcat to take advantage of SSL support when you are planning on running it as a stand-alone Web server. When you are planning to run Tomcat primarily as a JSP and Java Servlet container behind another Web server, such as Apache Web server, it is usually necessary to configure the primary Web server to handle the SSL connections from users. The communications between the primary Web server and Tomcat do not need to be encrypted. To install and configure SSL support on Tomcat, you need the following three things * Java Secure Socket Extension (JSSE) * A server certificate keystore * An HTTPS connector

26

02/28/2006

JSSE
?

Included in Java WSDP

<JWSDP-Install>/common/jsse.jar

Provides Java packages that support SSL/TLS (jsse.jar) SSL supports Encryption, server authentication, message integrity over TCP/IP

Data over any application level protocol (HTTP, FTP, Telnet, ...) can be securely protected

Based on Certificate-based (Public and Private key) security scheme

27

You need to have Java Secure Socket Extension (JSSE) package installed in order for Tomcat to use SSL. JSSE is integrated into the Java WSDP. JSSE is a set of Java packages that enables secure Internet communications. These packages implement a Java version of SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols and include functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol (such as HTTP, Telnet, NNTP, and FTP) over TCP/IP. By default, the location of the jsse.jar file under Java WSDP is <JWSDP_HOME>/common/lib/jsse.jar.

27

02/28/2006

Steps of Installing and Configuring SSL over Tomcat

28

Now let's go over the steps you will follow in order to install and configure SSL over Tomcat.

28

02/28/2006

1. Generate a key pair and a self-signed Server certificate

?

keytool -genkey -keyalg RSA -alias tomcat -keystore <keystore_filename> Enter password, fully-qualified name of your server, organizational unit, organization, etc. Tomcat is looking for the keystore to have the name .keystore in the home directory of the machine on which Tomcat is running as a default 29

First, you want generate a public/private key pair and generate a server certificate from the pair. To generate the certificate, run the keytool utility as follows, setting <keystore_filename> with the name of your keystore file: keytool -genkey -keyalg RSA -alias tomcat -keystore <keystore_filename> Tomcat is looking for the keystore to have the name .keystore (dot keystore) in the home directory of the machine on which Tomcat is running.

29

02/28/2006

1.1 Example: keytool usage

C:\>keytool -genkey -keyalg RSA -alias tomcat -keystore \tmp\keyfile.keystore Enter keystore password: changeit What is your first and last name? [Unknown]: localhost What is the name of your organizational unit? [Unknown]: sun What is the name of your organization? [Unknown]: mde What is the name of your City or Locality? [Unknown]: burlington What is the name of your State or Province? [Unknown]: ma What is the two-letter country code for this unit? [Unknown]: us Is CN=localhost, OU=sun, O=mde, L=burlington, ST=ma, C=us correct? [no]: yes Enter key password for <tomcat> (RETURN if same as keystore password):
30

This slide shows an example of creating a certificate. The keytool utility prompts you for the following information: # Keystore password--Enter a password. (You may want to use changeit to be consistent with the default password of the J2SE SDK keystore.) # First and last name--Enter the fully-qualified name of your server. This fullyqualified name includes the host name and the domain name. For testing purposes on a local machine, this will be localhost. (Yes, I know entering localhost as a value of first and last name is somewhat confusing.) # Organizational unit--Enter the appropriate value. # Organization--Enter the appropriate value. # City or locality--Enter the appropriate value. # State or province--Enter the unabbreviated name. # Two-letter country code--For the USA, the two-letter country code is US. # Review the information you've entered so far, enter Yes if it is correct. # Key password for Tomcat--Do not enter a password. Press Return.

30

02/28/2006

2. Configure SSL Connector & Restart Tomcat

? ?

By default, SSL HTTPS is not enabled in Tomcat You enable and configure an SSL HTTPS Connector on port 8443 in one of two methods

via Admintool Modify (actually uncomment SSL connector element) <JWSDP_HOME>/conf/server.xml as described in
?

<JWSDP_HOME>/docs/tutorial/doc/WebAppSecurity6. html#68482

Restart Tomcat
31

By default, an SSL HTTPS Connector is not enabled in Tomcat. You can enable and configure an SSL HTTPS Connector on port 8443 using either of the two mentioned above, either by using Admintool or modifying the server.xml file manually. Then restart Tomcat. Now let's take a look at each step in detail in the following slide.

31

02/28/2006

2.1 Admintool

32

To configure an SSL Connector using admintool, you must first have created a keystore as described in Setting Up a Server Certificate of Java WSDP. Tomcat will be looking for a keystore file named .keystore in the home directory of the machine on which Tomcat is running. When you have verified that you have created the .keystore file, follow these steps. # Start Tomcat, if you haven't already done so. # Start admintool by entering http://localhost:8080/admin in a Web browser. # Enter a user name and password combination that is assigned the role of admin. # Select Service (Java Web Services Developer Pack) in the left pane. # Select Create New Connector from the drop-down list in the right pane. # In the Type field, select HTTPS. # In the Port field, enter 8443 (or whatever port you require). This defines the TCP/IP port number on which Tomcat will listen for secure connections. # Enter the Keystore Name and Keystore Password if you have created a keystore file named something other than .keystore, if .keystore is located in a directory other than the home directory of the machine on which Tomcat is running, or if the password is something other than the default value of changeit. If you have used the default values, you can leave these fields blank. The home directory is generally /home/user_name on Unix and Linux systems, and C:\Documents and Settings\user_name on Microsoft Windows systems. Make sure you give the full path name, for example, c:\Documents and Settings\boda\keyfile.keystore under Windows. # Select Save to save the new Connector for this session. # Select Commit Changes to write the new Connector information to the server.xml file so that it is available the next time Tomcat is started.

32

02/28/2006

2.2 SSL Connector Element in server.xml

<!-- SSL Connector on Port 8443 --> <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8443" minProcessors="5" maxProcessors="75" enableLookups="false" acceptCount="10" connectionTimeout="60000" debug="0" scheme="https" secure="true"> <Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" clientAuth="false" protocol="TLS" /> 33 </Connector>

You can also configure HTTP Connector by changing the server.xml. An example Connector element for an SSL connector is included in the default server.xml. This Connector element is commented out by default. To enable the SSL Connector for Tomcat, remove the comment tags around the SSL Connector element.

33

02/28/2006

3. Verify SSL Support

?

From the browser, go to

https://localhost:8443/

Port 8443 is where SSL connector is created

34

The next step is verifying if SSL is configured correctly. For testing purposes, and to verify that SSL support has been correctly installed on Tomcat, load the default Tomcat introduction page with the following URL: https://localhost:8443/ The https in this URL indicates that the browser should be using the SSL protocol. The port of 8443 is where the SSL Connector was configured in the previous step.

34

02/28/2006

3.1 Example: Verify SSL Support

35

Now the first time a user accesses secure site, the New Site Certificate dialog displays. What this dialog box is saying is that the browser has no knowledge of this web server meaning the browser does not have any way to verify if the server's certificate it received is in fact a valid one or not. This is because the server's certificate is the one that I created, that is, self-signed. If the certificate has been signed by well-known Certificate Authority such as VeriSign, then the browser will automatically will recognize that the public key is a valid one and would not display this dialog box. Now since the browser is not sure, it is asking the user to verify the validity of the certificate using a series of dialog box. So here it says that the web server's name is localhost and it receives a certificate from it. By the way, since we are running the server on the localhost, the name of the web server happened to be set to localhost. If the server is a machine other than localhost, that machine's host name will be displayed.

35

02/28/2006

3.2 Example: Verify SSL Support

36

So the browser display a bit of information about the certificate it received so that you can make in intelligent decision whether to accept this certificate or not. So here the browser found out that the certificate was created for an organization entity called MDE and signed by MDE and which encryption method is used. (By the way, MDE stands for Market Development Engineering group within Sun. And since I work for MDE, I used it as a organization name when I created the self-signed certificate.)

36

02/28/2006

3.3 Example: Verify SSL Support

37

Now it is asking if you are ready to accept this certificate. And you have a choice to accept this certificate only for this session or forever or you can certainly reject it.

37

02/28/2006

3.4 Example: Verify SSL Support

38

This is another warning message. Basically what is saying is that certificate can be used in order to encrypt the information that is being transported between the browser and the web server. However, it does not protect it from fraud. That is, if in fact, this website is run by Sadam Hussein, the information that you are exchanging with him can be seen only by you and him, but you don't know what he will do with the information you passed to him.

38

02/28/2006

3.5 Example: Verify SSL Support

39

This is the final message.

39

02/28/2006

Browser & Certificates

40

We touched upon a bit how a browser deals with newly received certificate from a new web server it encounters for the first time. Let's talk about some of the certificate management features of a typical browser. This example is used using Netscape navigator.

40

02/28/2006

Netscape: Certificates of CA's

41

If picture shows all the certificate authorities that the browser knows about. These are typically pre-installed by the browser vendor. As you can see, they include Verisign as one of the primary certification authorities.

41

02/28/2006

Netscape: Certificates of Websites

42

This is the list of certificates from websites that this browser has accessed.

42

02/28/2006

Netscape: Certificates of Other People

43

People certainly can use certificates as a way to communicate with you, for example, through email, in a secure fashion. And this is the list of people who sent you emails using certificates. These certificates are mainly used for confidentiality only.

43

02/28/2006

Netscape: Certificates of Yourself

44

This is the list of certificates you have installed yourself.

44

02/28/2006

JSSE
45

Now let's talk a bit on Web services tools for J2EE.

45

02/28/2006

What is JSSE?
?

Java API for Secure Sockets Layer (SSL) Now standard part of J2SE 1.4

SSL 3.0 and TLS 1.0 Encryption Server authentication Optional client authentication Data integrity
46

Supports

SSL was founded by netscape. IETF standardized it as TLS. Provides security at the session layer. Uses the keys transparently.

46

02/28/2006

Why Why JSSE? JSSE?

?? ??

100% 100% pure pure Java Java implementation Abstracts Abstracts the the complex complex underlying underlying cryptographic cryptographic algorithms and and thus thus minimizes minimizes the the risk risk of creating subtle subtle and and dangerous dangerous security security vulnerabilities vulnerabilities
Uses Usesalgorithms, algorithms, keys

transparently transparently

??

Simple Simple to to use use to to create secure application application

47 47

SSL was founded by netscape. IETF standardized it as TLS. Provides security at the session layer. Uses the keys transparently.

47

02/28/2006

JSSE JSSE Framework

??

??

Supplements Supplements java.security java.security and and java.net java.net packages packages Provides Provides javax.net javax.net and javax.net.ssl javax.net.ssl packages packages
Extends Extends networking networking

socket classes, classes, trust trustand and key keymanagers, managers, and a socket factory factory framework framework for for encapsulating encapsulating socket creation creation behavior behavior

48 48

SSL was founded by netscape. IETF standardized it as TLS. Provides security at the session layer. Uses the keys transparently.

48

02/28/2006

SunJSSE Provider
? ?

JSSE provider that comes with JDK 1.4.1 Installed and pre-registered with the Java Cryptography Architecture Supplies implementations of the SSL v3.0 and TLS v1.0 as well as most common SSL and TLS cipher suites

getSupportedCipherSuites getEnabledCipherSuites setEnabledCipherSuites

49

The J2SE v1.4.1 release comes with a JSSE provider, SunJSSE, that comes installed and pre-registered with the Java Cryptography Architecture. Think of the SunJSSE provider as the name of the implementation. It supplies implementations of the SSL v3.0 and TLS v1.0 as well as most common SSL and TLS cipher suites. If you wish to find the list of cipher suites that are supported by your implementation of SSL (SunJSSE in this case), make a call to the getSupportedCipherSuites method in SSLSocket. Not all of these cipher suites, however, might be enabled. To find out which ones are enabled, call the method getEnabledCipherSuites. The list can be modified by calling setEnabledCipherSuites.

49

02/28/2006

JSSE JSSE Programming: Programming: Server Server Side Side

import import java.io.*; java.io.*; import import javax.net.ssl.*; javax.net.ssl.*; public public class class Server Server { { int int port port == portNumber; portNumber; SSLServerSocket SSLServerSocket server; server; try try {{ SSLServerSocketFactory SSLServerSocketFactory factory factory = = (SSLServerSocketFactory) (SSLServerSocketFactory) SSLServerSocketFactory.getDefault(); SSLServerSocketFactory.getDefault(); server server = = (SSLServerSocket)factory.createServerSocket(portNumber); (SSLServerSocket)factory.createServerSocket(portNumber); SSLSocket SSLSocket client client = = (SSLSocket) server.accept(); server.accept(); // // Create Create input input and and output streams streams as as usual usual // // send send secure secure messages messages to client client through through the the // // output output stream stream // // receive receive secure secure messages messages from client client through through // // the the input input stream stream }}catch(Exception catch(Exception e) e) { { }} }} 50 50

Converting the previous program to use SSL is fairly trivial. We use a SSLServerSocketFactory to get a factory which is used to create a socket associated with a port, which is then used to accept connections

50

02/28/2006

JSSE JSSE Programming: Programming: Client Client Side Side

import import java.io.*; java.io.*; import import javax.net.ssl.*; javax.net.ssl.*; public public class class Client Client { { ... ... try try {{ SSLSocketFactory SSLSocketFactory factory factory = (SSLSocketFactory) (SSLSocketFactory) SSLSocketFactory.getDefault(); SSLSocketFactory.getDefault(); server server = = (SSLServerSocket)factory.createServerSocket(portNumber); (SSLServerSocket)factory.createServerSocket(portNumber); SSLSocket SSLSocket client client = = (SSLSOcket) (SSLSOcket) factory.createSocket(serverHost, factory.createSocket(serverHost, port); port); // // Create Create input input and and output streams streams as as usual usual // // send send secure secure messages messages to server server through through the the // // output output stream stream receive receive secure // // messages messages from from server server through through the the input input stream stream }}catch(Exception catch(Exception e) e) { { }} }} 51 51

Converting the previous program to use SSL is fairly trivial. We use a SSLServerSocketFactory to get a factory which is used to create a socket associated with a port, which is then used to accept connections

51

02/28/2006

Passion!

52

52