Beruflich Dokumente
Kultur Dokumente
A PROJECT REPORT
Submitted by
M.Lakshmi Narayana,
G.Jayanthu Babu,
K.Rajesh Kumar.
of
BACHELOR OF TECHNOLOGY
IN
INFORMATION TECHNOLOGY
APRIL-2007
1
DEPARTMENT OF INFORMATION TECHNOLOGY
V.R.SIDDHARTHA ENGINEERING COLLEGE
VIJAYAWADA
BONAFIDE CERTIFICATE
SIGNATURE SIGNATURE
DEPARTMENTT OF DEPARTMENT OF
INFORMATION TECHNOLOGY INFORMATION TECHNOLOGY
2
ACKNOWLEDGEMENTS
We would also like to thank our project guide Mrs. Jaya Lakshmi,
lecturer, Department of Information Technology, for her support and
encouragement throughout the duration of the project. Her words of
encouragement motivated us to get along with the project.
We also thank all others who have helped us at various stages of this
project work.
Project Associates
3
Abstract:
Computer security has become one of the most important concerns in the
entire discipline of computing. The recent explosive growth of the Internet
and the World Wide Web has brought with it a need to protect sensitive
communications over the open networks.
In the past, security violations were generally done by Young adults, just for
fun. But as technology and usage of internet increased, there is always the
threat of planned attack (cyber terrorists), where the loss of money could be
large in billions.
So we have chosen this area of network security, and studied regarding VPN
(Virtual Private Networks) and SSL (Secure Socket Layer) protocol, the
current driving topics in the field of security.
In the recent past SSL protocol has revolutionized the area of VPN (Virtual
Private Network). SSL based VPN products allow users to establish secure
communication from virtually any Internet-connected web browser. It is
simpler and efficient than its predecessor (IPSec), in implementing a secure
remote access.
Security of client – server communication is achieved by achieving the
principles of security, like Authentication and Encryption. These techniques
are achieved using new packages of J2SDK, v 1.4, like JSSE and Key tool.
The rest of the Application code is developed using JAVA SWINGS.
4
APPENDIX 3
TABLE OF CONTENTS
ABSTRACT iv
1. INTRODUCTION 1
2.1 Introduction 10
2.2 SSL in Tcp/Ip protocol stack 12
2.3 Establishing Secure Tunnels Using SSL 14
2.4 Goals of SSL. 15
2.5 SSL Architecture 16
2.6 SSL Hand Shake messages. 17
2.7 SSL Limitations 20
5
3. Java Secure Socket Extension 23
Bibliography 59
6
List of Figures
7
List of Tables
8
Chapter 1 “INTRODUCTION”
In this we would introduce you the topic of VPN ‘Virtual Private Network’,
the back bone of this project. This gave us motivation regarding secure
remote access, to learn it, deploy and find new implementations.
9
Authenticating is just confirming that the sender is reliable and trustworthy.
And finally non-repudiation means that it can be verified that the sender and
the recipient were, in fact, the parties who claimed to send or receive the
message, respectively. In short, non-repudiation of origin proves that data
has been sent, and non-repudiation of delivery proves it has been received.
Classification:
The Virtual private networks can be classified into two main categories as
follows: Secure and Trusted.
Secure VPNs use cryptographic tunneling protocols to provide the
necessary confidentiality (preventing snooping), sender authentication
(preventing identity spoofing), and message integrity (preventing message
alteration) to achieve the privacy intended. When properly chosen,
implemented, and used, such techniques can provide secure communications
over unsecured networks. Because such choice, implementation, and use are
not trivial, there are many insecure VPN schemes on the market. Secure
VPN technologies may also be used to enhance security as a 'security
overlay' within dedicated networking infrastructures.
Secure VPN protocols include the following:
* IPSec (IP security), an obligatory part of IPv6.
* SSL used either for tunneling the entire network stack, such as in
OpenVPN, or for securing what is essentially a web proxy. Although the
latter is often called a "SSL VPN" by VPN vendors, it is not really a fully-
fledged VPN.
* PPTP (point-to-point tunneling protocol), developed jointly by a number
of companies, including Microsoft.
10
Some large ISPs now offer "managed" VPN service for business customers
who want the security and convenience of a VPN but prefer not to undertake
administering a VPN server themselves. In addition to providing remote
workers with secure access to their employer's internal network, sometimes
other security and management services are included as part of the package,
such as keeping anti-virus and anti-spyware programs updated on each
client's computer.
Trusted VPNs do not use cryptographic tunneling, and instead rely on the
security of a single provider's network to protect the traffic. Multi-protocol
label switching (MPLS) is commonly used to build trusted VPNs. Other
protocols for trusted VPNs include:
* L2F (Layer 2 Forwarding), developed by Cisco.
* L2TP (Layer 2 Tunneling Protocol), including work by both Microsoft and
Cisco.
* L2TPv3 (Layer 2 Tunneling Protocol version 3).
VPN Architectures:
• Intranet VPN: VPN is used to make connection among
fixed locations such as branch offices. This kind of LAN-
to-LAN VPN connection joins multiple remote locations
into a single private network.
• Extranet VPN: VPN is used to connect business partners
such as suppliers and customers. This kind of VPN
allows various parties to work in a shared environment.
11
• Remote Access VPN: This is a user-to-network
connection for the home user and mobile user
connecting to corporate private network from various
remote locations. This kind of VPN permits secure,
encrypted connections between a corporate private
network and remote users.
Employees
Intranet
Applications
Web
Email Extranet
Database Partners
Mainframe
E-Commerce (Remote
Access)
Citizens
12
• Tunneled data: Data that is encapsulated and encrypted, and sent
across a private link.
• Transit network: The shared or public network such as a private
intranet or the Internet where the encapsulated data passes through it.
13
lowered cost of operation is explained by the fact that the organization
does not need to employ as many trained and expensive networking
personnel as it would if the VPN were managed by the organization
itself.
• Provide broadband networking compatibility: In the case of Internet
connectivity based on leased lines, the bandwidth is entirely wasted in
the absence of an active Internet connection. VPNs, on the other hand,
create logical tunnels to transmit data as and when required. As a
result, the network bandwidth is used only when there is an active
Internet connection. Therefore, there is considerably less chance of
available network bandwidth waste.
• Reduce time and transportation costs for remote users
• Improve productivity since resources can be accessed from remote
networks.
• Simplify network topology in certain scenarios.
• Provide global networking opportunities.
• Provide telecommuter support.
• Provide faster ROI (return on investment) than traditional
leased/owned WAN lines: Show a good economy of scale.
14
Historically, VPN tunneling was typically performed at the Network Layer
or lower (e.g., IPSec, which operates at the Network Layer). SSL VPNs
work differently. They establish connectivity using SSL, which functions at
Levels 4-5. They also encapsulate information at Levels 6-7 and
communicate at the highest levels in the OSI model. Today, some SSL
VPNs are also able to tunnel network level information over SSL, making
SSL the most versatile remote access VPN technology available.
15
“Internet Protocol Security” Protocol (IPSec) provides enhanced security
features such as better encryption algorithms and more comprehensive
authentication. IPSec has two encryption modes: tunnel and transport.
IPSec can be used in two modes: Tunnel encrypts the header and the payload
of each packet while transport only encrypts the payload.
• Transport mode is normally used between the end points of a
connection - for example, to establish a secure connection such as a
VPN between a client device and a server.
• Tunnel mode is normally used between two systems where one or
both of them are not the endpoint of the connection. For example, to
communicate between a firewall and a VPN server on a LAN, or
between a remote dial-in system and an edge device such as a router
or gateway, you might use tunnel mode (or IPSec tunneling).
Tunnel mode and transport mode are implemented in different ways. In
transport mode, the IP header of a packet is modified, and has a trailing
16
IPSec header added to it. In tunnel mode, the entire packet is wrapped with a
new IP header that has a trailing IPSec header attached to it.
“Secure Sockets Layer” (SSL) protocol, on the other hand, is the standard
security technology for establishing an encrypted link between a web server
and a browser. This link ensures that all data passed between the web server
and browsers remain private and integral. SSL is an industry standard and is
used by millions of websites in the protection of their online transactions
with their customers.
Let us review in deep, regarding this SSL in the next chapter.
17
Chapter 2 “Secure Socket Layer”
18
secure for the future, but it does mean that many of the brightest minds in
cryptography and mathematics have been unable to find any holes in its
cryptographic armor. In the past, SSL/TLS was a general protocol that would
be tightly coupled with specific applications, thus the extreme confusion
about what an SSL VPN really is. It would be used to secure session
communication between two hosts using a single application or protocol at a
time. The most well known use of SSL is in the HTTPS protocol to enable
secure web-based ecommerce. SSL is the default security solution for
application to application needs, but it has never been implemented to
handle arbitrary multiple protocols at the same time, until now.
SSL encrypted pages had the prefix HTTPS whereas non-encrypted pages
used a prefix of HTTP. Today in addition to the change in the URL, most
browsers display some icon indicating that the session is encrypted—a lock,
a key, etc.
HTTPS is the web protocol that utilizes SSL to encrypt HTTP, and is used
worldwide today for secure web communications. HTTPS should not be
confused with S-HTTP, an alternative method for encrypting web
communications. S-HTTP competed with HTTPS in the early days of secure
web sessions, but was generally considered inferior to HTTPS for e-
commerce use (as it did not encrypt some session information), and is no
longer used. S-HTTP is an extension to the HTTP protocol used to support
sending data securely over the World Wide Web. S-HTTP is designed to
send individual messages securely where as SSL is designed to establish a
secure connection between two computers.
19
FIG 2.1 SCREEN SHOT OF SSL ENABLED WEBPAGE
Today, servers typically provide regular web service HTTP on port 80, and
SSLencrypted web traffic HTTPS over port 443. Overleaf is an HTTPS
encrypted web page. Note the https at the start of the URL and the lock icon
near the bottom right of the screenshot:
20
TCP/IP
Protocol Model
Application
SSL / TLS
(RFC 2246) Transport
Between Application
and Transport Layer
Network IPsec
Over Network Layer
Link Layer
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.
Security’s worst enemy is complexity and SSL VPN defeats this enemy.
Note that while SSL allows both the client and the server to authenticate
each other, typically only the server is authenticated in the SSL layer. Clients
are customarily authenticated in the application layer, through the use of
passwords sent over an SSL-protected channel. This pattern is common in
banking, stock trading, and other secure Web applications.
Compared to IPSec VPNs, SSL VPNs provide:
• Clientless Access,
21
• Compatibility with any Remote Access situation,
• More Security, with granular access control,
• More control for IT,
• Easier management, with lower total cost of ownership.
• Provide faster ROI (return on investment) than other protocols: Return
of Investment is your annual benefit divided by your investment
amount. By replacing your IPSec VPN with SSL VPN, you will see
bottom line benefits in the areas of operations, security productivity,
and business partner collaboration. Statistics show that by upgrading
only 1000 IPSec VPN users to SSL, over three years you could expect
operational benefits of $115,200 and productivity benefits of
$3,600,000, by extending it to 1000of your business partners over an
extranet, you could also add additional collaborative benefits of
$300,000, resulting in cumulative benefits of $4,015,200.
Clientless SSL VPN solutions are easier, cheaper, and faster to deploy than
IPSec VPNs, because there is no difficult-to-configure, difficult-to-manage,
and difficult-to-support components.
22
the river to point B on the other side and prevents environmental elements
like water from interfering with the traffic as shown in the diagram below.
The communications tunnel allows communications between
two computers over public networks securely so that other
computers on those networks
cannot access the communications between the two
machines.
Goals of SSL:
23
Encryption protects data from unauthorized use by converting it to an
apparently meaningless form before transmission. The data is encrypted by
one side (the client or the server), transmitted, decrypted by the other side,
and then processed.
Data integrity refers to means of ensuring that data has not been modified
in transit. Besides protecting data through encryption, SSL uses hashing to
ensure that the contents of a communications session are not modified
between the time one computer sends a message and the time the recipient
reads it. It offers encryption, source authentication, and data integrity as
means to protect information exchanged over insecure, public networks.
Basic understanding of SSL will help us understand the workings of SSL
VPNs, so let us look in to the Architecture of SSL protocol.
SSL Architecture:
24
This consists of three major sub protocols namely: Handshake protocol,
Record protocol, and Alert protocols.
• Handshake: This mechanism is called Session creation, and allows
client and server authentication.
• Record protocol : This provides Confidentiality and Message
Integrity.
Record protocol
Before data can be sent across an SSL connection, the two ends must
negotiate and exchange key information. We won't go into much detail about
the handshake protocol here, because it isn't necessary for our purposes. The
SSL full handshake protocol is illustrated in the next figure. It shows the
sequences of messages exchanged during the SSL handshake.
25
• 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.
• ServerHello: The server chooses the best cipher suite that both the
client and server support and sends this information to the client.
• 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.
• 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.
• Server Key Exchange: This message is sent if the certificate, which
contains the server's public key, is not sufficient for key exchange.
• ServerHelloDone: This message informs the client that the server
finished the initial negotiation process.
• Certificate: This message is sent only if the server requested the client
to authenticate itself.
26
Fig 2.2 “SSL Messages”
27
• Finished: The client tells the server it is ready for secure
communication.
• Change Cipher Spec: The server asks the client to change to encrypted
mode.
• Finished: The server tells the client it is ready for secure
communication. This marks the end of the SSL handshake.
• Encrypted Data: The client and server can now start exchanging
encrypted messages over a secure communication channel.
28
Fig 2.6 SSL Record protocol
The Change Cipher Spec sub-protocol is used to change the keying material
used for encryption between the client and server. It consists of a single
message to tell other party in the SSL/TLS session, who is also known, is the
peer that the sender wants to change to a new set of keys. The key is
computed from the information exchanged by the Handshake protocol.
SSL Limitations
The SSL protocol, like any other technology has its limitations. And because
SSL provides security services, it is it is especially important to understand
its limits. After all, a false sense of security may be worse than no security.
The limitations of SSL fall generally into three categories. First are
fundamental constraints of SSL. These are consequences of the design of
SSL. The SSL protocol also inherits some weaknesses from the tools it uses,
namely encryption and signature algorithms. If these algorithms have
weaknesses, SSL generally cannot rehabilitate them. Finally the
environments in which SSL is deployed have their own shortcomings and
limitations, some of which SSL is helpless to address.
Fundamental Protocol Limitations
29
Though its design includes considerations for many different applications,
SSL is definitely focused on securing Web transactions. For example, SSL
requires a reliable transport protocol such as TCP. That is a completely
reasonable requirement in the world of web transactions, because the HTTP
itself requires TCP. The decision means, that SSL cannot operate using a
connectionless transport protocol like UDP (User DataGram Protocol).
Another role that SSL fails to fill is support for a particular security service
known as non- repudiation. Non- repudiation associates the digital
equivalent of a signature with data;
Tool Limitations
The secure socket layer is simply a communication protocol, and any SSL
implementation will rely on other components for many functions, including
the cryptographic algorithms. These algorithms are the mathematical tools
that actually perform tasks such as encryption and decryption, no SSL
implementation can be any stronger than the cryptographic tools on which it
is based.
Some common cryptographic algorithms, however, have been successfully
attacked. So in general, SSL implementations must consider not only the
security of SSL, but also that of the cryptographic services on which it is
built.
Environmental Limitations
A network protocol alone can only provide security for information as it
transits a network. No network protocol protects data before it is sent or after
it arrives at its destination.
Security in any computer network, whether the public network or private
facilities, is a function of all the elements that make up that network. It
30
depends on the network security protocol, the computer systems that use and
the human beings who use those.
These SSL protocol is a strong and effective security tool, but it is only a
single tool. True security requires many such tools, and a comprehensive
plan to employ them.
The Java Secure Socket Extension (JSSE) provides a framework and a 100%
Pure Java implementation of the SSL and TLS protocols. It provides
mechanisms for data encryption, server authentication, message integrity,
and optional client authentication.
What is fascinating about JSSE is that is abstracts the complex underlying
cryptographic algorithms and thus minimizes the risk of creating subtle and
31
dangerous security vulnerabilities. In addition, it makes the development of
secure applications quite simple by allowing you to seamlessly integrate SSL
into your applications. The JSSE framework is capable of supporting many
different secure communication protocols such as SSL 2.0, 3.0 and TLS 1.0.
The Java platform's security and encryption features have grown
tremendously over the last few years. The JDK 1.4 (a.k.a. Merlin) release
now comes bundled with many security-related packages, including the Java
Cryptography Extension (JCE), the Java Secure Socket Extension (JSSE),
and the Java Authentication and Authorization Service (JAAS). All of these
components are pieces of the Java Cryptography Architecture (JCA), as
illustrated in the figure below:
JCA
32
behind the scenes during the SSL communications. This utility can be used
from the command line as follows:
Prompt> java -Djavax.net.debug=option[debugSpecifiers] MySSLApp
If you use the help option, it will display a list of the debug options. The
current options in J2SE 1.4.1 are:
You must specify the option ssl or all, optionally followed by debug
specifiers. One or more debug specifiers can be used, and a separator such as
":" or "," is not needed but can help with readability. Here are some
examples:
Prompt> java -Djavax.net.debug=all MyApp
Prompt> java -Djavax.net.debug=ssl MyApp
Prompt> java -Djavax.net.debug=ssl:handshake:trustmanager MyApp
Key tool
key tool is a key and certificate management utility. It enables users to
administer their own public/private key pairs and associated certificates for
33
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.
key tool 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.
The jarsigner tool uses information from a keystore to generate or verify
digital signatures for Java ARchive (JAR) files. (A JAR file packages class
files, images, sounds, and/or other digital data in a single file). Jarsigner
verifies the digital signature of a JAR file, using the certificate that comes
with it (it is included in the signature block file of the JAR file), and then
checks whether or not the public key of that certificate is "trusted", i.e., is
contained in the specified keystore.
Please note: the key tool and jarsigner tools completely replace the java key
tool provided in JDK 1.1. These new tools provide more features than java
key, including the ability to protect the keystore and private keys with
passwords, and the ability to verify signatures in addition to generating
them. The new keystore architecture replaces the identity database that java
key created and managed. It is possible to import the information from an
identity database into a keystore, via the
-identitydb key tool command.
Keystore Entries
There are two different types of entries in a keystore:
key entries - each holds very sensitive cryptographic key information, which
is stored in a protected format to prevent unauthorized access. Typically, a
34
key stored in this type of entry is a secret key, or a private key accompanied
by the certificate "chain" for the corresponding public key. The keytool and
jarsigner tools only handle the latter type of entry that is private keys and
their associated certificate chains.
trusted certificate entries - each contains a single public key certificate
belonging to another party. It is called a "trusted certificate" because the
keystore owner trusts that the public key in the certificate indeed belongs to
the identity identified by the "subject" (owner) of the certificate. The issuer
of the certificate vouches for this, by signing the certificate.
Keystore Aliases
All keystore entries (key and trusted certificate entries) are accessed via
unique aliases. Aliases are case-insensitive; the aliases Hugo and hugo
would refer to the same keystore entry.
An alias is specified when you add an entity to the keystore using the
-genkey command to generate a key pair (public and private key) or the
-import command to add a certificate or certificate chain to the list of trusted
certificates. Subsequent keytool commands must use this same alias to refer
to the entity.
For example, suppose you use the alias duke to generate a new
public/private key pair and wrap the public key into a self-signed certificate
(see Certificate Chains) via the following command:
keytool -genkey -alias duke -keypass dukekeypasswd
This specifies an inital password of "dukekeypasswd" required by
subsequent commands to access the private key associated with the alias
duke. If you later want to change duke's private key password, you use a
command like the following:
35
keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass
This changes the password from "dukekeypasswd" to "newpass".
Please note: A password should not actually be specified on a command line
or in a script unless it is for testing purposes, or you are on a secure system.
If you don't specify a required password option on a command line, you will
be prompted for it. When typing in a password at the password prompt, the
password is currently echoed (displayed exactly as typed), so be careful not
to type it in front of anyone.
Keystore Location
Each keytool command has a -keystore option for specifying the name and
location of the persistent keystore file for the keystore managed by keytool.
The keystore is by default stored in a file named .keystore in the user's home
directory, as determined by the "user.home" system property. Given user
name uName, the "user.home" property value defaults to
C:\Winnt\Profiles\uName on multi-user Windows NT systems
C:\Windows\Profiles\uName on multi-user Windows 95 systems
C:\Windows on single-user Windows 95 systems
Thus, if the user name is "narayan", "user.home" defaults to
C:\Winnt\Profiles\narayan on multi-user Windows NT systems
C:\Windows\Profiles\narayan on multi-user Windows 95 systems
Keystore Creation
A keystore is created whenever you use a -genkey, -import, or -identitydb
command to add data to a keystore that doesn't yet exist.
More specifically, if you specify, in the -keystore option, a keystore that
doesn't yet exist, that keystore will be created.
36
If you don't specify a -keystore option, the default keystore is a file named
.keystore in your home directory. If that file does not yet exist, it will be
created.
Keystore Implementation
The KeyStore class provided in the java.security package supplies well-
defined interfaces to access and modify the information in a keystore. It is
possible for there to be multiple different concrete implementations, where
each implementation is that for a particular type of keystore.
Currently, two command-line tools (keytool and jarsigner) and a GUI-based
tool named ‘Policy Tool’ make use of keystore implementations. Since
KeyStore is publicly available, JDK users can write additional security
applications that use it.
There is a built-in default implementation, provided by Sun Microsystems. It
implements the keystore as a file, utilizing a proprietary keystore type
(format) named "JKS". It protects each private key with its individual
password, and also protects the integrity of the entire keystore with a
(possibly different) password.
Keystore implementations are provider-based. More specifically, the
application interfaces supplied by KeyStore are implemented in terms of a
"Service Provider Interface" (SPI). That is, there is a corresponding abstract
KeystoreSpi class, also in the java.security package, which defines the
Service Provider Interface methods that "providers" must implement. (The
term "provider" refers to a package or a set of packages that supply a
concrete implementation of a subset of services that can be accessed by the
Java Security API.) Thus, to provide a keystore implementation, clients must
implement a "provider" and supply a KeystoreSpi subclass implementation,
37
as described in How to Implement a Provider for the Java Cryptography
Architecture.
38
The KeyStore class defines a static method named getDefaultType that lets
applications and applets retrieve the value of the keystore.type property. The
following line of code creates an instance of the default keystore type (as
specified in the keystore.type property):
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
The default keystore type is "jks" (the proprietary type of the keystore
implementation provided by Sun). This is specified by the following line in
the security properties file:
keystore.type=jks
To have the tools utilize a keystore implementation other than the default,
you can change that line to specify a different keystore type.
For example, if you have a provider package that supplies a keystore
implementation for a keystore type called "pkcs12", change the line to
keystore.type=pkcs12
Note: case doesn't matter in keystore type designations. For example, "JKS"
would be considered the same as "jks".
39
When generating a DSA key pair, the key size must be in the range from 512
to 1024 bits, and must be a multiple of 64. The default key size for any
algorithm is 1024 bits. The table that follows explains each option in the
command.
40
What is your first and last name?
[Unknown]: vrsiddhartha
What is the name of your organizational unit?
[Unknown]: itdepartment
What is the name of your organization?
[Unknown]: students
What is the name of your City or Locality?
[Unknown]: vijayawada
What is the name of your State or Province?
[Unknown]: ap
What is the two-letter country code for this unit?
[Unknown]: in
Is CN=vrsiddhartha, OU=itdepartment,
O=students, L=vijayawada, ST=ap, C=in correct?
[yes/no]: yes <enter>
Enter key password for <qusay>
(RETURN if same as keystore password): hiagain
41
Fig 4.1 screen shot for generating a Server key
As you can see, the keytool prompted me to enter a password for the
keystore meaning that in order for the server to access the keystore it must
know that password. Also, the tool asked me to enter a password for the
alias. If you like, such password information can be related on the keytool
command line using the options -storepass and -keypass. Note that I used the
name "ultra.domain.com" for the first and last name. This name is the
hypothetical name of my machine. You should enter the hostname or the IP
address of the server's machine.
When you run the keytool command, it may take a few seconds to generate
the certificate depending on the speed of your machine.
Once a certificate for my server has been generated, I can revise my
HttpServer to make it secure. If you examine the HttpServer class, you'll
notice that the getServer method is used to return a server socket. This
means, the only method I need to modify is the getServer method so that it
returns a secure server socket. The changes are highlighted in bold in Code
Sample 2. Notice that I have changed the port number to 443. This is the
42
default port number for HTTPs. It is important to note that port numbers
between 0 and 1023 are reserved. If you run HttpsServer on a different port
number, the url should be: https://localhost:portnumber but if you run it on
443 then the URL is: https://localhost.
import java.io.*;
import java.net.*;
import javax.net.*;
import javax.net.ssl.*;
import java.security.*;
import java.util.StringTokenizer;
/**
* This class implements a multithreaded simple HTTPS server that supports
the GET
* request method. It listens on port 443, waits client requests and serves
documents.
*/
KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream(keystore), keystorepass);
KeyManagerFactory kmf = eyManagerFactory.getInstance("SunX509");
43
kmf.init(ks, keypassword);
SSLContext sslcontext = SSLContext.getInstance("SSLv3");
sslcontext.init (kmf.getKeyManagers(), null, null);
ServerSocketFactory ssf =sslcontext.getServerSocketFactory();
SSLServerSocket serversocket = (SSLServerSocket)
ssf.createServerSocket(HTTPS_PORT);
return serversocket;
}
// main program
public static void main(String argv[]) throws Exception {
HttpsServer https = new HttpsServer();
https.run();
}
}
44
public ProcessConnection(Socket s) {
client = s;
try {
is = new BufferedReader(new InputStreamReader client.getInputStream()));
os = new DataOutputStream(client.getOutputStream());
}
catch (IOException e) {
System.out.println("Exception: "+e.getMessage());
}
this.start(); // Thread starts here...this start() will call run()
}
45
}
/**
* Read the requested file and ships it to the browser if found. */
46
}
The lines:
String keystore = "serverkeys";
char keystorepass[] = "hellothere".toCharArray();
char keypassword[] = "hiagain".toCharArray();
specify the name of the keystore, its password, and the key password.
Hardcoding the passwords into the code is not a good idea for production
code, however. They can be specified on the command line when running
the server.
The rest of the JSSE related code is in the getServer method:
It access the serverkeys keystore. The JKS is the Java Key Store (a type of
keystore created by keytool).
The KeyManagerFactory is used to create an X.509 key manager for the
keystore.
An SSLContext is an environment for implementing JSSE. It is used to
create a ServerSocketFactory that in turn used to create a SSLServerSocket.
Although we specify SSL 3.0, the implementation that is returned will often
support other protocol versions, such as TLS 1.0. Older browsers, however,
use SSL 3.0 more widely.
47
Open a web browser and enter the request: https://localhost or
https://127.0.0.1. This assumes the server is running on port 443. If not, then
use: https://localhost:port
48
Save the exported certificate in a file called server.cert, which will be created
by the keytool
As you can see, I was asked to enter the password. Upon successful entry of
the password, the server's certificate got exported and saved in the file
server.cert.
Prompt> keytool -export -keystore serverkeys -alias qusay -file server.cert
Enter keystore password: hellothere
Certificate stored in file <server.cert>
Copy the server.cert file to the directory where ReadHttpsURL1 is located.
Use the keytool to create a new keystore and import the server's server.cert
certificate into it. Here is a sample command:
Prompt> keytool -import -keystore trustedcerts -alias qusay -file server.cert
This command produces the following output.
I was asked to enter a password. This is a new password for the trustedcerts
keystore. This keystore is created by the keytool. At the end of the output, I
got asked if I wish to trust this certificate. My answer was yes.
Enter keystore password: clientpass
Owner: CN=localhost, OU=Training and Consulting, O=javacourses.com,
L=Toronto, ST=Ontario, C=CA
Issuer: CN=localhost, OU=Training and Consulting, O=javacourses.com,
L=Toronto, ST=Ontario, C=CA
Serial number: 3dcf988a
Valid from: Mon Nov 11 06:46:18 EST 2002 until: Sun Feb 09 06:46:18
EST 2003
Certificate fingerprints:
MD5: 37:35:4D:3A:2B:7E:B5:09:A5:41:B3:FA:E4:3C:1D:C4
SHA1: CB:7C:77:36:79:A2:37:26:E2:98:61:C2:9D:10:50:69:
49
99:F9:B9:1B
Trust this certificate? [no]: yes
Certificate was added to keystore
Now run the ReadHttpsURL1 and inform it where to look for certificates
using the following command:
Prompt> java -Djavax.net.ssl.trustStore=trustedcerts ReadHttpsURL1
localhost
50
The javax.net.ssl.SSLSocketFactory class is an object factory for creating
secure sockets. An instance of SSLSocketFactory can be obtained in two
ways:
Get the default factory by calling SSLSocketFactory.getDefault. The default
factory is configured to enable server authentication only (no client
authentication). Note that most e-commerce web sites do not require client
authentication.
Once an instance of SSLSocketFactory has been created, you can create an
instance of SSLSocket by invoking a createSocket method on the
SSLSocketFactory instance. Here is an example that creates a socket
connection to Sun's WWW server through the SSL port 443, which is the
default port number for HTTPS.
// Get a Socket factory
SocketFactory factory = SSLSocketFactory.getDefault();
// Get Socket from factory
Socket socket = factory.createSocket("www.sun.com", 443);
Working with Low-level SSL Sockets
Now, let's see a complete code of opening an SSL socket connection to an
HTTPS server using low-level sockets. In this application, an SSL socket
connection will be opened to an HTTPS server, and then we read the content
of the default document. The instructions that open the SSL socket are
highlighted in bold. As you can see, the rest of the application is regular Java
code for input/output streams.
ReadHttpsURL1.java
import java.net.*;
import javax.net.*;
51
import javax.net.ssl.*;
52
}
}
53
Exception in thread "main" javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: Couldn't find trusted certificate
at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275)
It didn't work for a good reason. This was caused by the remote server
sending a certificate that is unknown to the client. As I mentioned in the first
part of the article, when a client connects to a server, the server sends its
certificate to the client for authentication. Well, in the first example, where
you entered www.sun.com, that server did send its certificate, but Java
checks the default certificate store and realized that the certificate was
generated by one of the trusted Certificate Authorities that Java trusts by
default. In the second example where you entered www.jam.ca, the
certificate for that site was either self-generated or generated by a
Certification Authority unknown to Java, and therefore it wasn't trusted.
Note: If the system clock is not set correctly, the perceived time may be
outside the validity period of the certificate, the server will assume the
certificate is invalid and therefore a CertificateException will be thrown.
In order to make that example work, you'd need to import the certificate of
the Web site www.jam.ca into the store of certificates trusted by Java.
54
• The browser receives an HTML reply.
• The browser parses the HTML and displays the rendered page.
The browser we create will support and handle any URLs such as HTTP,
HTTPS and ftp. Note that I parse the HTML using the kit in the class
javax.swing.text.html.HTMLEditorKit, which provides support for HTML
3.2. The code for the browser, SSLBrowser, is shown in Code Sample 3.
Note that the SSLBrowser is implementing the Runnable interface. I did this
because this browser doesn't provide a STOP button. Therefore, if a request
freezes for some reason, multiple downloads can still be instantiated
concurrently as you can see from the run method.
SSLBrowser.java
import java.io.*;
import java.net.*;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
55
buildBrowserInterface();
}
panel.add(controls, "North");
panel.add(new JScrollPane (content), "Center");
panel.add(statusLine, "South");
frame.pack();
56
frame.setVisible(true);
}
/** * You cannot stop a download with QBrowser
* The thread allows multiple downloads to start concurrently in case a
download freezes */
57
private void readURL(URL url) throws IOException {
statusLine.setText("Opening " + url.toExternalForm());
URLConnection connection = url.openConnection();
StringBuffer buffer = new StringBuffer();
BufferedReader in=null;
try {
in = new BufferedReader(new
InputStreamReader(connection.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
buffer.append(line).append('\n');
statusLine.setText("Read " + buffer.length () + " bytes...");
}
} finally {
if(in != null) in.close();
}
String type = connection.getContentType();
if(type == null) type = "text/plain";
statusLine.setText("Content type " + type);
content.setContentType(type);
content.setText(buffer.toString());
statusLine.setText("Done");
}
58
The QBrowser handles both HTTP and HTTPS requests since it uses the
URL class. You can test the QBrowser using both HTTP and HTTPS URLs.
59
Fig 4.8 Screen shot of SSL enabled browser
60
Looking To The Future
In the present day world, VPN or remote access is used by many companies
on a large scale. So for them, the question is not whether to add SSL remote
access, but when. Is this the right time to get into SSLVPN? The decision
making depends upon each company’s circumstances and remote access
requirements.
The future demands that each and every browser has to be enabled with this
SSL technology, and transform every bit of data securely, through this vast
Internet. Because, Security is the concept, that Internet Designers had
neglected, in the early stages of (DARPA) Defense Advanced Research
Projects Administration net, the first version of an IP based network, funded
by the US Department of Defense in 1969.
61
Appendices A “Basics of Tunneling Technology”
As you learned in the previous chapter, tunneling lies at the core of VPN
technology. While the cost effectiveness of VPNs is attributed to the use of
the Internet, the safety and security that VPNs offer are the direct result of
tunneling.
In this chapter, you'll learn about the basics of tunneling technology and the
role it plays to ensure the safety of transactions across a widely
heterogeneous internetwork, such as the Internet. You'll learn about the
components of tunneling, the working of tunneling technology, and the
format of a tunneled packet. You'll also learn about the different types of
tunnels and tunneling protocols.
The most important aspect of tunneling is that the original data packet, also
referred to as the payload, can belong to an unsupported protocol. Instead of
62
transferring the original packet, which might not be routable across the
intermediate infrastructure, the underlying tunneling protocol appends its
header to the tunneled packet. This header provides the requisite routing
information so that the packet can be successfully delivered across the
internetwork.
Tunneling is analogous to sending a letter. After you write a letter, you place
it in an envelope. This envelope displays the address of the recipient. When
you post this letter, it is delivered to the recipient according to the address on
the envelope. The recipient then needs to open the envelope to read the
letter. In tunneling technology, the letter is equivalent to the original payload
and the envelope represents the packet of the routable protocol in which the
payload is encapsulated. The address on the envelope represents the routing
information that is appended to the packet.
Advantages of Tunneling
63
tunneling a viable and lucrative solution for largeas well as
mediumscale organizations.
• Security. An organization's tunnel access is prohibited to
unauthorized users. As a result, data traveling through the tunnels is
relatively safe—despite the fact that the data is being transmitted
across an unsafe and public medium, such as the Internet.
• Cost-effectiveness. Tunneling uses public networks as the
intermediate internet-works to transfer data to a destination. This
makes tunneling an extremely cost-effective solution, especially when
you compare it to the cost of implementing private intranets that span
the globe or long-distance leased lines. In addition, an organization
can save the considerable amount of money that it would have to
spend annually on the administration and maintenance of these
expensive solutions.
• Protocol indifference. Data belonging to non-routable protocols, such
as Network Basic Input/Output System (NetBIOS), and NetBIOS
Enhanced User Interface (NetBEUI) is not compatible with the
Internet protocols TCP and IP. Therefore, these data packets cannot be
routed as-is across the Internet. However, tunneling allows you to
route such non-IP packets successfully to the destination by
"enveloping" them within IP packets.
• IP address savings. As mentioned earlier, tunneling allows protocols
with non-routable non-IP addresses to be inserted within a packet that
uses a globally unique public IP address. As a result, instead of having
to buy and assign a globally unique IP address (also known as a public
IP address) for each node within the network, the network can buy a
small block of globally unique IP addresses. When a node within this
64
private network establishes a VPN connection, any of the available IP
addresses from the block can be appended to the non-IP data packets.
Thus, the private network can reduce an organization's need for
globally unique IP addresses.
Now that you have the basic ideas of tunneling technology, you're ready to
move to a discussion of tunneling components.
Components of Tunneling
• Target network. The network that contains the resources that needs
to be accessed by the remote client, which initiated the VPN session
request. (The target network is also referred to as home network in
some VPN-related documentations.)
• Initiator node. The remote client or server that initiates the VPN
session. The initiator node can be a part of a local network or can be a
mobile user using a laptop.
• HA (Home Agent). The software interface that generally resides at the
network access node (router) in the target network. However, a
destination node, such as a dial-up access server, can also host the
HA. The HA receives and authenticates the incoming requests to
verify that they are from trusted hosts. Upon successful initiator
authentication, the HA allows the establishment of a tunnel.
• FA (Foreign Agent). The software interface that resides either at the
initiator node or at the network access node (router) of the network to
65
which the initiator node belongs. The initiator node uses the FA to
request a VPN session from the HA at the target network.
66
• Payload. The original packet sent by the initiator to the FA. It also
contains the original header.
Tunneling Protocols
67
REFERENCES
Aventail corporation, “Now an SSL VPN can replace IPSec for Remote
Access, A vendor white paper.
Charlie Scott, Paul Wolfe, and Mike Erwin, “Virtual Private Networks“,
Publisher: O'Reilly, Second Edition, ISBN: 1-56592-529-7, pp.6-40.
VPN
68
http://compnetworking.about.com/od/vpn/a/what_is_a_vpn.htm
http://www.consumer-research-
guide.com/vpn.htm?gclid=CM7ewZyW7IcCFSGTYAodx3RXfQ
http://www.infosec.gov.hk/english/itpro/sectips/VPN_eng.pdf
http://www.pcnetworkadvisor.com
VPN forums
http://www.tek-tips.com/threadminder.cfm?pid=463
http://www.vpnc.org/vpn-technologies.html
Tcp/Ip guide
http://www.tcpipguide.com/free/t_toc.htm
IPSec
http://send2press.com/newswire/2006-11-1130-004.shtml
http://www.vpnlabs.com/
SSL / TLS
http://info.ssl.com/
http://www.cse.wustl.edu/~jain/cse473-05/ftp/i_isec/sld008.htm
http://www.PacktPub.com/book/ssl_vpn
http://www.ietf.org/html.charters/tls-charter.html
http://www.cs.bris.ac.uk/~bradley/publish/SSLP/chapter4.html
http://www.csi.uottawa.ca/~istvan/ecomm/SSL.html
http://www.codeproject.com/cs/internet/socketsincs.asp
http://home.comcast.net/~fjhirsch/SSL/tlstut_html/sld017.htm
Ipsec vs.ssl
http://www.unixwiz.net/techtips/iguide-ipsec.html
http://www.cisco.com/en/US/netsol/ns340/ns394/ns50/ns140/networking
_solutions_white_paper09186a0080136858.shtml
http://docs.sun.com/source/816-6156-10/contents.htm
Security Issues
http://e-docs.bea.com/wle/security/concepts.htm
69
http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci343029,00.ht
ml
http://www.openssl.org/docs/ssl/ssl.html
http://home.comcast.net/~fjhirsch/SSL/tlstut_html/index.htm
http://www.musicahead.com/manual/mod/mod_ssl/ssl_intro.html
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html
http://tldp.org/HOWTO/SSL-Certificates-HOWTO/index.html
JSSE
http://www.onjava.com/pub/a/onjava/2001/05/03/java_security.html?pag
e=1
http://java.sun.com/developer/JDCTechTips/2004/tt0817.html#1
http://java.sun.com/j2se/1.4.2/docs/guide/security/jsse/JSSERefGuide.ht
ml
http://builder.com.com/5100-6370-1050055.html
Client-Server communications
http://www.codeproject.com/cs/internet/AsyncSocketServerandClien.asp
Rfc’s of protocols
http://tools.ietf.org/html/rfc2764
tls http://www.ietf.org/rfc/rfc2246.txt
Implementation:
http://java.sun.com/developer/technicalArticles/Security/secureinternet/
http://java.sun.com/developer/technicalArticles/Security/secureinternet2/
70