CHAPTER 1

History Behind Internet Security

Computers have become ubiquitous and indispensable today. Internet usage has multiplied
and is a vital global tool in technology.

1.1 What is Internet Security?

This subject came into being with the advent of the Internet. There are three basic issues -
confidentiality, integrity and availability. When an unauthorized person reads or copies
information, it is known as loss of confidentiality. When the information is modified in an
irregular manner, it is known as loss of integrity. When the information is erased or becomes
inaccessible, it is known as loss of availability. Authentication and authorization are the
processes of the Internet security system by which numerous organizations make
information available to those who need it and who can be trusted with it. When the means
of authentication cannot be refuted later, it is known as non-repudiation. Internet security
can be achieved through use of antivirus software, which quarantines or removes malicious
software programs. Firewalls can determine which particular websites can be viewed and
block deleterious content.

1.2 History of the Internet

In the beginning, the Internet did not exist. There were no computer networks to be found.
There was no e-mail facility, and people used postal mail or the telephone to communicate.
The extremely busy sent telegrams. Few people used ugly names as a euphemism for others
whom they had never met. The Internet has dramatically changed all this. The Internet,
started as the Advanced Research Projects Agency Network (ARPANET). It was a tiny,
isolated and restricted community.
By 1996, the Internet connected an estimated 13 million computers in 195
countries on every continent, even Antarctica. The Internet is not a single network, but a
worldwide collection of connected networks that are accessible by individual computer
hosts by Internet service providers, gateways, routers and dial-up connections. The Internet
is accessible to anyone with a computer and a network connection. Individuals and
1
organizations worldwide can reach any point on the network without regard to national or
international boundaries or time. Today a local problem can become a global incident within
a short span of time.

1.3 History of Internet Security

In 1987, the ‘Vienna’ virus emerged. Ralph Burger got a copy of it, disassembled it, and
published the result in his book ‘Computer Viruses: a High-tech Disease’. This particular
book made the idea of writing viruses popular, explained how to do it, and resulted in
creating up hundreds and in thousands of computer viruses implementing concepts from it.
On November 2, 1988, Peter Yee at the NASA Ames Research Center sent a note out to the
TCP/IP Internet mailing list that said, ‘We are currently under attack from an Internet
VIRUS! It has hit Berkeley, UC San Diego, Lawrence Livermore, Stanford, and NASA
Ames.’ Of course, this report was the first evidence of what was to be later known as The
Morris Worm. Roberts, a 23-year-old Cornell University student, wrote some software code
as part of a research project aimed at determining the size of the Internet. The worm was
meant to infect computers, in order to see how many connections to the Internet existed.

2
Because of a flaw in the software code, however, it ended up exploiting vulnerabilities in
Unix and spread rapidly, infecting multiple machines multiple times and rendering them
unusable.
In 1994, Russian hacker Vladimir Levin broke into Citibank's cash
management system and embezzled $10 million into his own accounts. The stolen accounts
were unencrypted and all but $400,000 of the stolen cash was recovered and Levin was
arrested He pled guilty to conspiracy to commit computer, wire and bank fraud. On April 11,
1994, a full-scale epidemic broke out, caused by file and boot polymorphic virus called
'Tequila'. In September 1994, the same thing happened with the ‘Amoeba’ virus.
In 1996, the ‘Boza’ virus emerged, which was the first virus designed
specifically for Windows 95 files. In 1998, the first Java virus ‘Strange Brew’ affected
computers.
In 2005, the Bropia Worm affected the Internet. It targeted MSN messenger for
spreading.
The 2007 Storm Worm was a Trojan horse. It included an executable file as an
attachment. When the e-mail recipient opened the attachment, he or she unknowingly
became part of a botnet (a collection of infected computers) to spread viruses and Spam.
Once infected, a computer is called as a bot. It is an instance of adaptive malware. It has
been used in different kinds of criminal activities. The authors and the controllers, of the
Storm Worm, have not yet been identified.

1.4 General ways of providing security

The concept of cryptography helps a lot in the security perspect. There are a lot of
Encryption methods (Algorithms) are also using such as RSA. Although these applications
need the security:-
• E-mail Encryption
• Web-site Encryption
• Application Encryption
• Remote user communiaction security by id and password
• Digital Signatures
• Using secure version of http (HTTPS) by SSL/TLS connection etc.

3
 CHAPTER 2

Introduction

2.1 What is SSL ?

Secure Socket Layer (SSL) denotes the predominant security protocol of the Internet for
World Wide Web (WWW) services relating to electronic commerce or home banking.
The majority of web servers and browsers support SSL as the de-facto standard for secure
client-server communication. The Secure Socket Layer protocol builds up point-to-point
connections that allow private and unimpaired message exchange between strongly
authenticated parties.
In the ISO/OSI reference model [ISO7498], SSL resides in the session layer between the
transport layer (4) and the application layer (7); with respect to the Internet family of
protocols this corresponds to the range between TCP/IP and application protocols such as
HTTP, FTP, Telnet, etc. SSL provides no intrinsic synchronization mechanism; it relies
on the data link layer below.
The SSL protocol allows mutual authentication between a client and server and the
establishment of an authenticated and encrypted connection. SSL runs above TCP/IP and
below HTTP, LDAP, IMAP, NNTP, and other high-level network protocols.

In general :
SSL – Secure Socket Layer
• It provides a secure transport connection between applications (e.g., a web

server and a browser),

• SSL was developed by Netscape,

– V2 1994 netscape
– V3 1996 netscape
• SSL version 3.0 has been implemented in many web browsers (e.g., Netscape
Navigator and MS Internet Explorer) and web servers and widely used on the
Internet.
• A protocol widely used on the Web
– Operates between the application and transport layers.

4
 HTTP, FTP,SMTP

SSL TCP IP

Data Link

Physical

• Operations of SSL
– Negotiation for PKI
Server and browser negotiate to select cryptographic algorithm and
create a session secret key.
– Communications.
Encrypted by using the key that was negotiated.

2.2 Evolution of SSL ?

Netscape developed the first specification of SSL in 1994, but only publicly released and
deployed the next version, SSLv2, in the same year [SSL2]. With respect to public key
cryptography, it relies mainly on RSA encryption (RSA cryptosystem) and X.509-
compliant certificates. Block ciphers, such as DES, Triple DES (3DES), and RC4, along
with hash functions like MD5 and SHA, complement the suite of algorithms. SSLv3

5
followed in 1995, adding cryptographic methods such as Diffie-Hellman key agreement
(DH), support for the FORTEZZA key token, and the Digital Signature Standard (DSS)
scheme [SSL3].
The most recent draft of the SSL 3.0 specification was published in November of
1996 by Netscape. The intent was to be a “security protocol that provides communications
privacy over the Internet. The protocol allows client/server applications to communicate in
a way that is designed to prevent eavesdropping, tampering, or message forgery.” The goals
included cryptographic security, interoperability, extensibility, and relative efficiency.
Interoperability was a goal so that applications could be written to the standard and
expected to work with any other applications written to the standard. Interoperability, it was
noted, does not imply that two programs will always be able to connect. One might not have
the correct algorithm support or credentials necessary for the connection to the other.
Extensibility was descried as providing “a framework into which new public key and
bulk encryption methods can be incorporated as necessary.” It was noted that this should
prevent the need to implement a new security protocol entirely should a weakness be found
in one of the current encryption methods.
Cryptography, obviously, causes a higher CPU load than sending the data unencrypted. Still,
they made some effort to minimize the network traffic and allow for session caching.

2.2.1 SSL v2.0

Released by Netscape Communications in 1994. The main goal of this protocol was to
provide security for transactions over the World Wide Web. Unfortunately, very quickly a
number of security weaknesses were found in this initial version of the SSL protocol, thus
making it less reliable for commercial use:

o weak MAC construction

o possibility of forcing parties to use weaker encryption
o no protection for handshakes

possibility of an attacker performing truncation attacks.

2.2.2 PCT v1.0

6
Developed in 1995 by Microsoft. Privacy Communication Technology (PCT) v1.0
addressed some weaknesses of SSL v2.0, and was aimed to replace SSL. However, this
protocol has never gained as much popularity as SSL v3.0.

2.2.3 SSL v3.0

Released in 1996 by Netscape Communications. SSL v3.0 solved most of the SSL v2.0
problems, and incorporated many of the features of PCT. Pretty quickly become the most
popular protocol for securing communication over WWW.

2.2.4 TLS v1.0 (also known as SSL v3.1)

Published by IETF in 1999 (RFC 2246). This protocol is based on SSL v3.0 and PCT and
harmonizes both Netscape's and Microsoft's approaches. It is important to note that although
TLS is based on SSL, it is not a 100% backward compatible with its predecessor. IETF did
some security improvements, such as using HMAC instead of MAC, using a different
calculation of the master secret and key material, adding additional alert codes, no support
for Fortezza cipher suites, and so on. The end result of these improvements is that these
protocols don't fully interoperate. Fortunately enough, TLS has also got a mode to fall back
to SSL v3.0.

re version numbers: Both SSL2 and SSL3 have 16-bit (two-byte) version number fields.
SSL2 interprets this as a single 16-bit integer, and the official number is 2, e.g. 0x0002.
SSL3 interprets two-byte version numbers as a one byte "major" number and a one byte
"minor" (or fractional) number. So the value 0x0002 is interpret by SSL3 as version 0.2, not
2.0.

2.3 What is TLS ?

SSL 3.0 was the basis for the TLS 1.0 (RFC 2246) specification published by the
Internet Engineering Task force (IETF) in 1999.
In actual TLS was just a minor modification in SSL.

7
In general :
TLS – Transport Layer Security
• TLS can be viewed as SSL v3.1,
• SSL v3.0 was specified in an Internet Draft (1996), it evolved into RFC 2246 and
was renamed to TLS (Transport Layer Security),
• V1.0 1999 RFC2246 IETF minor update from SSL v3.0,

• V1.1 April 2006 RFC4346 updates to prevent specific security

attacks.

2.4 Evolution of TLS ?

SSL v3.0 was actually renamed into TLS. SSL version 3.0 and its designated successor
protocol Transport Layer Security (TLS) 1.0, which the Internet Engineering Task Force
(IETF) published for the first time in 1999 [RFC2246]. The IETF published the most recent
Internet-Draft for TLS 1.1 in Oct. 2002 [TLS].
The TLS 1.0 specification described itself as being similar to but not backwards compatible
with the SSL 3.0 specification. It did include a fallback mechanism for SSL 3.0 if TLS was
not available. The IETF made some small changes and clarifications and published
RFC4346 in 2006 detailing TLS 1.1. There is currently a working draft for TLS 1.2 (RFC
Draft 4346) which expired in September 2007.

2.5 SSL/TLS Architecture :

SSL/TLS has 4 underlying protocols: Handshake, Record, Change Cipher Spec, and Alert.

All other SSL/TLS protocols reside inside of the Record protocol. This is laid out as:

8
Protocol Architecture :

9
 CHAPTER 3

SSL/TLS working and description

3.1 SSL layers and working?

SSL splits into distinct layers and message types.SSL/TLS has 4 underlying protocols:
Handshake, Record, Change Cipher Spec, and Alert.

The working of these layers as follows:-

3.1.1 SSL Handshake protocol :-

The handshake message sequence initiates the communication, establishes a set of common
parameters like the protocol version, applicable cryptographic algorithms (cipher suites),
and assures the validity of the message sequence. During the handshake, the participants
accomplish the negotiated authentication and derive the session key material.
In this way Handshake protocol does :-
• Negotiation of security algorithms and parameters,
• Key exchange,
• Server authentication and optionally client authentication.

TLS connections begin with a 6-way handshake. The handshake protocol structure is:

The allowed values for type are as follows:

10
 0 HelloRequest
1 ClientHello
2 ServerHello
11 Certificate
12 ServerKeyExchange
13 CertificateRequest
14 ServerHelloDone
15 CertificateVerify
16 ClientKeyExchange
20 Finished

3.1.2 SSL Record protocol :-

The record layer fragments the full data stream into records with a maximum size of 214
bytes and envelopes them cryptographically under the current session keys. Records contain
a keyed message authentication code (HMAC). The initial handshake presupposes a NULL
cipher suite applying no encryption and no HMAC. The record layer fully provides the use
of compression. However, for patent reasons the core specifications name no method
explicitly, except for the mandatory NULL algorithm, which practically makes compression
an incompatible, implementation-dependent feature.

The basic layer structre and message is as follows:

11
 Application Layer

SSL / TLS Protocol

Application Messages Handshake Messages

ChangeCipherSpec
Message

Alert Messages

Record Layer

Transport Layer

 SSL Layer and Message Structure

In this way the Record protocol does:-

• Fragmentation,
• Compression,
• Message authentication and integrity protection,
• Encryption.

3.1.3 SSL Change Cipher Spec Protocol:-

It is a single message that indicates the end of the SSL handshake. The change cipher can
understood as follows:

12
 State Changes

Here
Operating state
– currently used state.
Pending state
– state to be used,
– built using the current state.

3.1.4 SSL Alert Protocol:-

Alert messages inform on exceptional protocol conditions (fatal alerts and warnings) or on a
participant’s request to end the communication (closure alert).
Each alert message consists of 2 fields (bytes)
1. first field (byte): “warning” or “fatal”

2. second field (byte):

– fatal
• unexpected_message
• bad_record_MAC
• decompression_failure
• handshake_failure
• illegal_parameter
– warning

13
 • close_notify
• no_certificate
• bad_certificate
• unsupported_certificate
• certificate_revoked
• certificate_expired
• certificate_unknown
• In case of a fatal alert
– connection is terminated,
– session ID is invalidated,
– no new connection can be established within this session.

3.2 SSL Encryption and Header ?

SSL can use following Encrption and Header types:-
3.2.1 Encryption:-
It supports following algorithms:-
– block ciphers (in CBC mode)
• RC2_40
• DES_40
• DES_56
• 3DES_168
• IDEA_128
• Fortezza_80
– stream ciphers
• RC4_40
• RC4_128
If a block cipher is used, than padding is applied, last byte of the padding is the padding
length.
3.2.2 Header :-
It supports following header types:-
• change_cipher_spec
• alert
14
 • handshake
• application_data
The higher level protocol used to process the enclosed fragment. Length (in bytes) of the

enclosed fragment or compressed fragment max value is 214+ 2048.

3.3 SSL Working ?

The working of SSL can be show as following:-
The SSL handshake accomplishes three goals. Firstly, both parties agree on a cipher suite,
i.e. the set of cryptographic algorithms that they intend to use for application data protection.
Secondly, they establish a common master_ secret in order to derive their session key
material. Thirdly, the participant’s identities are authenticated. Although the SSL
specification permits anonymous, server-only and mutual authentication, it is customary to
only assert the server’s identity.

This Figure gives an overview of the SSL protocol variants. It comprises four different
handshake sequences, each identified by a capital letter:
S,C,E,R which denotes:-
• S denotes the server-authenticated message flow.
• C marks the sequence with additional client authentication.
• E shows the handshake variant with ephemeral Diffie-Hellman key agreement.
• R stands for the handshake of resumed sessions. Note, that the message pairs.
ChangeCipherSpec / Finished of client and server are drawn in reverse order; the
server message pair follows ServerHello immediately.

Process :-
First the client sends the Client Hello message which includes a 32-bit Unix format
timestamp and a 28-byte random number. The client may also specify a session identifier of
a current or previous session. Doing this allows for multiple secure connections without
going through the entire handshake process each time, although both Hello, the Change
Cipher Spec, and both Finished messages must still be exchanged and be valid.

15
 SSL Protocol Sequence

The client then includes a list of acceptable Cipher Suites and Compression Methods.
Each cipher suite defines the algorithm for key exchange, the bulk encryption algorithm
with secret key and length, and the message authentication code (MAC).
The server then responds to this with the Server Hello message. The server hello
message will have the following data:
• The version number being used: the lower of the server’s highest supported
version and the version in the client hello.
• A random number generated by the server.
• The session identifier: if the Session ID is recognized, then a short
handshake is used and the following fields are filled in with the values from
the previous connection. Otherwise, the Server Hello generates a new
Session ID.
• The cipher suite chosen by the server, and

16
 • The compression method chosen by the server.
If the server can not find an acceptable cipher suite and compression method, it will
respond with a handshake failure alert.
Unless the key exchange method is anonymous, the server will send out a Certificate
immediately after sending the Server Hello. The certificate is generally a X.509v3 certificate
public key and unless otherwise specified uses the same key exchange method and signing
algorithm previously decided on. After the server’s certificate, certificates from all the up
line servers necessary to get to one that the client trusts must be included. The order of these
should be such that each certificate validates the one before it.
If the server Certificate does not contain enough data for a premaster secret, then a
Server Key Exchange is sent with either a RSA public, or a Diffie-Hellman public key.
(This is the case for DHE_DSS, DHE_RSA, and DH_anon; but not for RSA, DH_DSS, and
DH_RSA key exchange methods.)
If it is appropriate, the server may request a certificate from the client with a
Certificate Request. This would immediately follow the Server Certificate, or if present the
Server Key Exchange. The Certificate request would specify the types of certificates the
server will accept and the Certificate Authorities the server trusts. The client, after receiving
the Server Hello Done would respond with a message identical in format to the Server
Certificate.
The Server Hello Done indicates to the client that server is done sending data and the
client should now verify the certificates and whatnot it has received.
If a Certificate Request was received, the client would now send the Certificate.
If RSA is used, the Client Key Exchange message includes an encrypted pre-master
secret which consists of a 48-bit number that is encrypted with the server’s public key.
If Diffie-Hellman is used, but not Fixed Diffie-Hellman, then the public key
parameters are sent here.
If the client sent a certificate, then it would send a Certificate Verify message hat this
point, in most cases. This would include a signature in the same format as defined for the
Server Key Message as well as an md5 sum of all of the previous messages and a SHA hash
of all of the previous messages.

17
 The Client sends the Change Cipher Spec message indicating that all future traffic
will be computed with the Master Secret. The random numbers and the pre master secret are
used by both systems in a pseudorandom function to calculate the master secret.
The change cipher spec protocol is a single byte that will always have a value of 1. It
is encrypted and compressed under the current cipher (the pre master secret) and
compression method.
The client now sends the Finished Message. This consists of the master secret, the
finished label, an md5 of all previous messages and an SHA of all previous messages. All of
this is encrypted with the master secret. If the server can read all of this, then the server
knows that the key generation was successful.
The server responds with its own Change Cipher Spec and Finished messages which
verify to the client that the key generation was successful.
If any warning or fatal errors occur, an alert is sent. Alerts consist of a byte that
defines whether it’s a warning (1) or a fatal (2) alert, and a byte that indicates the specific
alert.

The following alerts (with their values in parenthesis) are fatal:

• unexpected_message(10),
• bad_record_mac(20),
• decryption_failed(21),
• record_overflow(22),
• decompression_failure(30),
• handshake_failure(40),
• illegal_parameter(47),
• unknown_ca(48),
• access_denied(49),
• decode_error(50),
• export_restriction_RESERVED(60),
• protocol_version(70),
• insufficient_security(71),

18
 • internal_error(80),
• user_canceled(90),

These messages may not be fatal:

• close_notify(0),
• no_certificate_RESERVED (41), - this is SSL 3.0 only
• bad_certificate(42),
• unsupported_certificate(43),
• certificate_revoked(44),
• certificate_expired(45),
• certificate_unknown(46),
• decrypt_error(51),
• no_renegotiation(100)
When the master secret is computed, data may be sent encapsulated inside of record
protocol. This data will be encrypted and compressed in the agreed upon methods and can
be reliably read by the other end but not likely anyone in-between.

19
 CHAPTER 4

SSL/TLS Certificates and Practical Implementation

4.1 What is SSL and what are Certificates?

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions
between web servers and browsers. The protocol uses a third party, a Certificate Authority
(CA), to identify one end or both end of the transactions. This is in short how it works.
1. A browser requests a secure page (usually https://).
2. The web server sends its public key with its certificate.
3. The browser checks that the certificate was issued by a trusted party (usually a trusted
root CA), that the certificate is still valid and that the certificate is related to the site
contacted.
4. The browser then uses the public key, to encrypt a random symmetric encryption key
and sends it to the server with the encrypted URL required as well as other encrypted
http data.
5. The web server decrypts the symmetric encryption key using its private key and uses
the symmetric key to decrypt the URL and http data.
6. The web server sends back the requested html document and http data encrypted with
the symmetric key.
7. The browser decrypts the http data and html document using the symmetric key and
displays the information.

4.1.1 What is https?

Hyper Text Transfer Protocol Secure (HTTPS) is a secure version of the Hyper Text
Transfer Protocol (http). HTTPS allows secure ecommerce transactions, such as online
banking.

20
Web browsers such as Internet Explorer and Firefox display a padlock icon to indicate that
the website is secure, as it also displays https:// in the address bar.

When a user connects to a website via HTTPS, the website encrypts the session with a
digital certificate. A user can tell if they are connected to a secure website if the website
URL begins with https:// instead of http://.

HTTPS is effectively HTTP using SSL (Secure Sockets Layer). SSL merely encrypts the
content of the packets before being sent from the server to client.

4.1.2 Concepts behind Certificates?

Following concepts are used in identification and validation of SSL certificates:-

4.1.2.1 Private Key/Public Key:

The encryption using a private key/public key pair ensures that the data can be encrypted by
one key but can only be decrypted by the other key pair. This is sometime hard to
understand, but believe me it works. The keys are similar in nature and can be used
alternatively: what one key emcrypts, the other key pair can decrypt. The key pair is based
on prime numbers and their length in terms of bits ensures the difficulty of being able to
decrypt the message without the key pairs. The trick in a key pair is to keep one key secret
(the private key) and to distribute the other key (the public key) to everybody. Anybody can
send you an encrypted message, that only you will be able to decrypt. You are the only one
to have the other key pair, right? In the opposite , you can certify that a message is only
coming from you, because you have encrypted it with you private key, and only the
associated public key will decrypt it correctly. Beware, in this case the message is not
secured you have only signed it. Everybody has the public key, remember!

One of the problem left is to know the public key of your correspondent. Usually you will
ask him to send you a non confidential signed message that will contains his publick key as
well as a certificate.

Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message

4.1.2.2 The Certificate:

21
A SSL certificate does following tasks:-

1. An SSL Certificate enables encryption of sensitive information during online

transactions.
2. Each SSL Certificate contains unique, authenticated information about the certificate

owner.
3. A Certificate Authority verifies the identity of the certificate owner when it is issued.

4.1.2.2.1 who need SSL certificate ?:

SSL should be used by any organization wishing to:

• Secure online creditcard transactions

• Secure online systemlogins, web forms, web mail, control panels or protected areas of
web sites
• Secure the transfer of files over https and FTP services such as web site owners
updating new pages to their web sites
• Secure the connection between an email client such as Microsoft Outlook and an
email server such as Microsoft Exchange
• Secure intranet basedtraffic such as intranets, extranets and database connections

The e-commerce business is all about making money and then finding ways to
make more money. Of course, it's hard to make (more) money, when consumers
don't feel safe executing a transaction on your Web site. That's where SSL
(Secure Socket Layer) comes into play.

4.1.2.2.2 working of certificate ?:

SSL is all about encryption. SSL encrypts data, like credit cards numbers (as well other
personally identifiable information), which prevents the "bad guys" from stealing your
information for malicious intent. You know that you're on an SSL protected page when the
address begins with "https" and there is a padlock icon at the bottom of the page (and in the
Mozilla Firefox in the address bar as well).
The browser encrypts the data and sends to the receiving Web site using either 40-bit or 128-
22
bit encryption. Your browser alone cannot secure the whole transaction and that's why it's
incumbent upon e-commerce site builders to do their part.

At the other end of the equation, and of greatest importance to e-commerce site builders, is
the SSL certificate. The SSL certificate sits on a secure server and is used to encrypt the data
and to identify the Web site. The SSL certificate helps to prove the site belongs to who it
says it belongs to and contains information about the certificate holder, the domain that the
certificate was issued to, the name of the Certificate Authority who issued the certificate, the
root and the country it was issued in.
SSL certificates come in 40-bit and 128-bit varieties, though 40-bit encryption has been
hacked. As such, you definitely should be looking at getting a 128-bit certificate.
Though there a wide variety of ways in which you could potentially acquire a 128-bit
certificate, there is one key element that is often overlooked in order for full two-way 128-
bit encryption to occur. According to SSL certificate vendor VeriSign, in order to have 128-
bit encryption you need a certificate that has SGC (server grade cryptography) capabilities.

How Encryption Works :-

Imagine sending mail through the postal system in a clear envelope. Anyone with access to
it can see the data. If it looks valuable, they might take it or change it. An SSL Certificate
establishes a private communication channel enabling encryption of the data during
transmission. Encryption scrambles the data, essentially creating an envelope for message
privacy.

Each SSL Certificate consists of a public key and a private key. The public key is used to
encrypt information and the private key is used to decipher it. When a Web browser points
to a secured domain, a Secure Sockets Layer handshake authenticates the server (Web site)
and the client (Web browser). An encryption method is established with a unique session
key and secure transmission can begin. True 128-bit SSL Certificates enable every site
visitor to experience the strongest SSL encryption available to them.

How Authentication Works :-

Imagine receiving an envelope with no return address and a form asking for your bank
account number. Every VeriSign SSL Certificate is created for a particular server in a
specific domain for a verified business entity. When the SSL handshake occurs, the browser

23
requires authentication information from the server. By clicking the closed padlock in the
browser window or certain SSL trust marks (such as the VeriSign Secured Seal), the Web
site visitor sees the authenticated organization name. In high-security browsers, the
authenticated organization name is prominently displayed and the address bar turns green
when an Extended Validation SSL Certificate is detected. If the information does not match
or the certificate has expired, the browser displays an error message or warning.

Why Authentication Matters :-

Like a passport or a driver’s license, an SSL Certificate is issued by a trusted source, known
as the Certificate Authority (CA). Many CAs simply verify the domain name and issue the
certificate. VeriSign verifies the existence of your business, the ownership of your domain
name, and your authority to apply for the certificate, a higher standard of authentication.

VeriSign Extended Validation (EV) SSL Certificates meet the highest standard in the
Internet security industry for Web site authentication as required by CA/Browser Forum. EV
SSL Certificates give high-security Web browsers information to clearly display a Web site’s
organizational identity. The high-security Web browser’s address bar turns green and reveals
the name of the organization that owns the SSL Certificate and the SSL Certificate Authority
that issued it. Because VeriSign is the most recognized name in online security, VeriSign
SSL Certificates with Extended Validation will give Web site visitors an easy and reliable
way to establish trust online.

4.1.2.2.3 Who can issue SSL Certificates?:

SSL Certificates can be issued by anybody using freely available software such as Open
SSL or Microsoft's Certificate Services manager. Such SSL Certificates are known as "self-
signed" Certificates. However, self-signed SSL Certificates are not inherently trusted by
customer's browsers and whilst they can still be used for encryption they will cause
browsers to display "warning messages" - informing the user that the Certificate has not
been issued by an entity the user has chosen to trust.

Such warnings are undesirable for commercial sites - they will drive away customers. In
order to avoid such warnings the SSL Certificate must be issued by a "trusted certifying
authority" - trusted third party Certification Authorities that utilize their trusted position to
make available "trusted" SSL Certificates.

24
 Warning message IE users will see from a self-signed SSL Certificate

Warning message Netscape users will see from a self-signed SSL Certificate

4.1.2.2.4 What is a Certification Authority?

Browsers and Operating Systems come with a pre-installed list of trusted Certification
Authorities, known as the Trusted Root CA store. As Microsoft and Netscape provide the
major operating systems and browsers, they have elected whether to include the
Certification Authority into the Trusted Root CA store, thereby giving trusted status.

Microsoft and Netscape determine which organizations are Certification Authorities.

25
 The Microsoft trusted root CA store

The Netscape trusted root CA store

SSL certificates issued by trusted Certification Authorities do not display a warning and
establish a secure link between website and browser transparently. In such circumstances,
the padlock signifies the user has an encrypted link with a company who has been issued a
trusted SSL Certificate from a trusted Certificate Authority.

Microsoft and Netscape have therefore determined the role of the Certification Authority -
to use their trusted status to "pass trust" to websites whom ordinarily would not be trusted
by a customer.
The key issue must now be addressed - before passing such trust, how does the CA know the
website can be trusted?

All SSL Certificates are not equal!

The value of SSL is protected by the strength of a standard two-point validation process:

Step 1: Verify that the applicant owns, or has legal right to use, the domain

26
Name featured in the application.
Step 2: Verify that the applicant is a legitimate and legally accountable entity.

The compromise of either step endangers the message of trust and legitimacy provided to
the end consumer.

Companies such as GeoTrust, through its QuickSSL and FreeSSL products, and IPSCA, the
Spanish SSL Provider, perform only the first stage of the two-step validation process (as
employed by all other SSL Providers) by only verifying that the applicant owns the domain
name provided during Certificate application. This validation step relies on the use of
Domain Name Registrar details to validate ownership of a domain name and then a
challenge email is sent to the listed administrator of the domain name. If the challenge is
met with a successful reply, the Certificate will be issued.

4.1.2.2 The Symmetric key:

Well, Private Key/Public Key encryption algorithms are great, but they are not usually
practical. It is asymmetric because you need the other key pair to decrypt. You can't use the
same key to encrypt and decrypt. An algorithm using the same key to decrypt and encrypt is
deemed to have a symmetric key. A symmetric algorithm is much faster in doing its job than
an asymmetric algorithm. But a symmetric key is potentially highly insecure. If the enemy
gets hold of the key then you have no more secret information. You must therefore transmit
the key to the other party without the enemy getting its hands on it. As you know, nothing is
secure on the Internet. The solution is to encapsulate the symmetric key inside a message
encrypted with an asymmetric algorithm. You have never transmitted your private key to
anybody, then the message encrypted with the public key is secure (relatively secure,
nothing is certain except death and taxes). The symmetric key is also chosen randomly, so
that if the symmetric secret key is discovered then the next transaction will be totally
different.

Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key

4.1.2.3 Encryption algorithm:

27
There are several encryption algorithms available, using symmetric or asymmetric methods,
with keys of various lengths. Usually, algorithms cannot be patented, if Henri Poincare had
patented his algorithms, then he would have been able to sue Albert Einstein... So
algorithms cannot be patented except mainly in USA. OpenSSL is developed in a country
where algorithms cannot be patented and where encryption technology is not reserved to
state agencies like military and secret services. During the negotiation between browser and
web server, the applications will indicate to each other a list of algorithms that can be
understood ranked by order of preference. The common preferred algorithm is then chosen.
OpenSSL can be compiled with or without certain algorithms, so that it can be used in many
countries where restrictions apply.

4.1.2.4 The Hash:

A hash is a number given by a hash function from a message. This is a one way function, it
means that it is impossible to get the original message knowing the hash. However the
hash will drastically change even for the slightest modification in the message. It is
therefore extremely difficult to modify a message while keeping its original hash. It is also
called a message digest. Hash functions are used in password mechanisms, in certifying
that applications are original (MD5 sum), and in general in ensuring that any message has
not been tampered with. It seems that the Internet Enginering Task Force (IETF) prefers
SHA1 over MD5 for a number of technical reasons.

4.1.2.5 Signing:

Signing a message, means authentifying that you have yourself assured the authenticity of
the message (most of the time it means you are the author, but not neccesarily). The message
can be a text message, or someone else's certificate. To sign a message, you create its hash,
and then encrypt the hash with your private key, you then add the encrypted hash and your
signed certificate with the message. The recipient will recreate the message hash, decrypts
the encrypted hash using your well known public key stored in your signed certificate,
check that both hash are equals and finally check the certificate.

28
The other advantage of signing your messages is that you transmit your public key and
certificate automatically to all your recipients.

There are usually 2 ways to sign, encapsulating the text message inside the signature (with
delimiters), or encoding the message altogether with the signature. This later form is a very
simple encryption form as any software can decrypt it if it can read the embedded public
key. The advantage of the first form is that the message is human readable allowing any non
complaint client to pass the message as is for the user to read, while the second form does
not even allow to read part of the message if it has been tampered with.

4.1.2.6 PassPhrase:
“A passprase is like a password except it is longer”. In the early days passwords on Unix
system were limited to 8 characters, so the term passphrase for longer passwords. Longer
is the password harder it is to guess. Nowadays Unix systems use MD5 hashes which have
no limitation in length of the password.

4.1.2.7 Public Key Infrastructure :

The Public Key Infrastructure (PKI) is the software management system and database
system that allows to sign certifcate, keep a list of revoked certificates, distribute public
key,... You can usually access it via a website and/or ldap server. There will be also some
people checking that you are who you are... For securing individual applications, you can
use any well known commercial PKI as their root CA certificate is most likely to be inside
your browser/application. The problem is for securing e-mail, either you get a generic type
certificate for your e-mail or you must pay about USD100 a year per certificate/e-mail
address. There is also no way to find someone's public key if you have never received a
prior e-mail with his certificate (including his public key).

4.2 SSL Softwares

These are most useful SSL software:-

• OpenSSL: a free implementation (BSD license with some extensions).

• GnuTLS: a free implementation (LGPL licensed).
• JSSE: a Java implementation included in the Java Runtime Environment.
• Network Security Services (NSS): FIPS 140 validated open source library.
29
Openssl is a very popular SSL software.It is described as :-
Openssl :-

OpenSSL is an open source implementation of the SSL and TLS protocols. The core library
(written in the C programming language) implements the basic cryptographic functions and
provides various utility functions. Wrappers allowing the use of the OpenSSL library in a
variety of computer languages are available.

Versions are available for most Unix-like operating systems (including Solaris, Linux,
Mac OS X and the four open source BSD operating systems), OpenVMS and Microsoft
Windows. IBM provides a port for the System i (iSeries/AS400). OpenSSL is based on
SSLeay by Eric A. Young and Tim Hudson, development of which unofficially ended
around December 1998, when Tim and Eric both moved to work for RSA Security.

Algorithms :-

OpenSSL supports a number of different cryptographic algorithms:

1. Ciphers

• Blowfish, Camellia, DES, RC2, RC4, RC5, IDEA, AES

2. Cryptographic hash functions

• MD5, MD2, SHA, MDC-2

3. Public-key cryptography

• RSA, DSA, Diffie-Hellman key exchange, Elliptic curve

4.3 SSL Practical Implementation

The practically SSL is implemented for Apache 2.0 in this way :-

4.3.1 Installing Apache with SSL/TLS support :-

The first step in order to install Apache with SSL/TLS support is to configure and install
the Apache 2 web server, and create a user and group named "apache". A secure way of
installing Apache's 2.0 has already been published on SecurityFocus in the article Securing
Apache 2.0: Step-by-Step. The only difference to that process is to enable mod_ssl and
mod_setenvif, which is required to provide compatibility with some versions of MS
Internet Explorer, as follows (changes shown in bold):
30
./configure \
--prefix=/usr/local/apache2 \
--with-mpm=prefork \
--enable-ssl \
--disable-charset-lite \
--disable-include \
--disable-env \
--enable-setenvif \
--disable-status \
--disable-autoindex \
--disable-asis \
--disable-cgi \
--disable-negotiation \
--disable-imap \
--disable-actions \
--disable-userdir \
--disable-alias \
--disable-so

After configuring, we can install Apache into the destination directory:

make
su
umask 022
make install
chown -R root:sys /usr/local/apache2

4.3.2 Configuring SSL/TLS :-

Basically SSL default port number is 443. Before running Apache for a first time, we need
also to provide an initial configuration and prepare some sample web content. As a
minimum, we need to go through the following steps (as root):

1. Create some sample web content, which will be served up via TLS/SSL:
2. Replace the default Apache configuration file (normally found in
/usr/local/apache2/conf/httpd.conf) with the new one, using the following content
(optimized with respect to security and performance).
3. Prepare the directory structure for web server's private keys, certificates and
certification revocation lists (CRLs):

31
 4. Create a self-signed server certificate (it should be used only for test purposes -- your
real certificate should come from a valid CA such as Verisign):

4.3.3 Testing the installation :-

At this point we can start Apache with SSL/TLS support, as follows:

/usr/local/apache2/bin/apachectl startssl
Apache/2.0.52 mod_ssl/2.0.52 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.

Server 127.0.0.1:443 (RSA)

Enter pass phrase:*************

Ok: Pass Phrase Dialog successful.

After the server starts, we can try to connect to it by pointing the web browser to the URL of
the form: https://name.of.the.web.server.In few moments, we should see a warning message
saying that there is problem with verifying the authentication of the web server we want to
access.

The occurrence of the above warning is perfectly correct. We should receive this message
because of two reasons:

• The web browser does not know the Certificate Authority which issued the web
server's certificate (and cannot know, because we are using self-signed certificate)
• The CN (Common Name) attribute of the certificate does not match the name of the
website - at the moment it is "Test-Only Certificate", and it should be the fully
qualified domain name of the web server

there is a yellow lock at the bottom of the web browsers, which means that the SSL
connection has been successfully established. The value "128-bit" says that the symmetric
key that that is being used to encrypt the communication has the length of 128 bits, which is
strong enough (at least for the moment) to protect the traffic from unauthorized access.

If we double click the lock icon, we will see the properties of website's certificate.

32
4.4 SSL Standards

The current approved version is 1.2, which is specified in:

• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.

The current standard obsoletes these former versions:

• RFC 2246: “The TLS Protocol Version 1.0”.

• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.

Other RFCs subsequently extended TLS, including:

• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the
IMAP, POP3 and ACAP services that allow the server and client to use transport-layer
security to provide private, authenticated communication over the Internet.
• RFC 2712: “Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)”.
The 40-bit ciphersuites defined in this memo appear only for the purpose of
documenting the fact that those ciphersuite codes have already been assigned.
• RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade
mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing
TCP connection. This allows unsecured and secured HTTP traffic to share the same
well known port (in this case, http: at 80 rather than https: at 443).
• RFC 2818: “HTTP Over TLS”, distinguishes secured traffic from insecure traffic by
the use of a different 'server port'.
33
• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer
Security”. Specifies an extension to the SMTP service that allows an SMTP server
and client to use transport-layer security to provide private, authenticated
communication over the Internet.
• RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced Encryption Standard (AES)
ciphersuites to the previously existing symmetric ciphers.
• RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for
negotiating protocol extensions during session initialisation and defines some
extensions. Made obsolete by RFC 4366.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the
framework for compression methods and the DEFLATE compression method.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-
Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.
• RFC 4279: “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds
three sets of new ciphersuites for the TLS protocol to support authentication based on
pre-shared keys.
• RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works
over datagram protocols (such as UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of
specific extensions, and a generic extension mechanism.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side
State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
Transport Layer Security (TLS)”.

34
 CHAPTER 5

CONCLUSIONS & FUTURE SCOPE

Presently, SSL/TLS become backbone of not only in E-commerce but in any secured
information exchange across Internet. Although the working advance TLS protocol provides
a better security mechnism then ssl but it still has some limitation which needs to overcome.

The limitations of using TLS/SSL:-

5.1 Increased processor load

This is the most significant limitation to implementing TLS/SSL. Cryptography, specifically

public key operations, is CPU-intensive. As a result, performance varies when you are using
SSL. Unfortunately, there is no way to know how much performance you will lose. The
performance varies, depending on how often connections are established and how long they
last. TLS uses the greatest resources while it is setting up connections.

5.2 Administrative overhead

A TLS/SSL environment is complex and requires maintenance; the system administrator

must configure the system and manage certificates.

5.3 Limitation of SSL/TLS with REBOL/Command 2.0

REBOL/Command 2.0 and higher support client-side data encryption across a TCP channel
using the Secure Socket Layer (SSL) and Transport Layer Security (TLS) standards.

REBOL provides two ways of using this feature: The HTTPS protocol (SSL for HTTP)
exists as a predefined scheme. Other schemes (e.g. SMTP across SSL/TLS or POP3 across
SSL/TLS) can be implemented based on the ssl:// and tls:// schemes, which implement SSL
and TLS on top of TCP sockets.

In its current version the REBOL SSL/TLS implementation has the following limitations.
Future versions of REBOL may add support for these features.

• SSL/TLS server mode is not supported.

35
 • Certificate handling is not supported. REBOL does check the validity of server
certificates internally, but no mechanism exists to access the certificate chain from
REBOL scripts, and client certificates cannot be defined.

5.4 Limitations of SSL/TLS with FTP

• The FTP server must support SSL.

• FTP cannot be eliminated from the enterprise environment.
• Administration is more complex because the required authentication uses certificates.
• By default, FTP with SSL/TLS does not provides user authentication, only host
authentication.

5.5 Limitations in TLS authentication

The following are limitations to authenticating strangers on the Internet using TLS
client/server authentication:
• Certificates are exchanged in plain text during the initial TLS handshake.
• The client and the server are limited to disclosing a single certificate chain to
each other. containing those attributes.
• The server specifies a list of distinguished names of certifying authorities that
the server trusts when it requests a client certificate. In contrast, the client has
no such opportunity.
5.6 Limitations in Software prospective
• The software used for testing is of course available for others to use,under a BSD
licence [sslperf].
• Find out why the Apache server refuses to reuse sessions.And whether it can shut
down SSL properly (bugfix).
• Integrate with Globus GSI libraries.
• Use different public key algorithms (e.g., DSA, elliptic curves).
• Investigate other types of authentication or message confidentiality,c.f., [Message
level vs SSL layer].

5.7 Other future directions

Improved Certificate Management
36
 • Certificate chains
• Longer RSA keys for server certificates
• PKCS #7, PEM certificate formats

In the next version above mentioned limitation needs to be corrected sothat secure
transmission of information can be gurrented.

37
 REFERENCES

Websites:-

1. www.google.com
2. www.scribd.com
3. http://en.wikipedia.org/wiki/Ssl
4. www.openssl.org/
5. www.VeriSign.com

Books:-

1. SSL & TLS Essentials- by Stephen A. Thomas

2. HTTP Essentials- by Stephen Thomas
3. Network Security with OpenSSL- by John Viega, et al
4. SSL and TLS- by Eric Rescorla (Author)

38