Network Security Protocol

SS-2014 Uni-Konstanz (4-July-2014)

Network Security Protocol

Waleed Abrar
Uni-Konstanz

Message should be encrypted when passing

through the unsecure channel and even if
eavesdropper get the cypher text, he could not
recover partial or complete plain text.

ABSTRACT
SSL stands for secure socket layer and is introduced to
make the communication between the client and server
machine as secure as possible. SSL create a secure tunnel
over the socket, which is basically and end point on a
network communication, The communication can be
done in such a way that even if some body get the cypher
text he does not predict anything about the original
message . Before public and private key cryptography the
communication over the network could easily be tapped
because someone have to pass the password to the other
side, and person having the file can do a brute force
attack to unlock the secret.
Later Netscape introduced some standards to follow
when starting a communication over an unsecure
connection. In this report I will explain briefly about SSL
and some flaws in SSL V2 and how SSL 3 fixed those
flaws.

C) Message Integrity:The message send for a particular endpoint

reach there without any interference or
tempering from any 3rd party sources.
D) Non repudiation:The message can be tracked back to its source
e.g. sender cannot deny that he is one who
actually have sent the message.

Keywords
Protocols,
SSL
2,
Sessions,MAC,SHA1,Hand
Netscape.

SSL
3,Connections
and
Shake
,Premaster
secret,

Fig.1: Explaining communication from client to server and

motivation for SSL

1) INTRODUCTION:In the early 1990 lot of research is done to create some

methods to securely transmit the data to its destination
without being interfered by someone. SSL was
developed by Netscape. The original SSL version 2
specification was released in 1994, and deployed on
Netscape Navigator v1.1 in March 1995. Netscape
released SSL version 3 in late 1995 to fill the security
flaws in SSLv2. SSL 1 was never publically released (W,
2003).

3) Digital Certificates, Message Digest and

MACS:-

A) Authentication:Authentication proves the identity of the person

whom communication should be started. Its
really important to make sure that you are
communicating with the right person not a third
person acting as your target person.

In public key cryptography which uses pair of keys and

KE != KD (key for encryption is different from key for Decryption).
If there is a person in between that intercept all messages
and replace cypher text by his own key. Both sender and
receiver are unaware of this middle man. So Digital
Certificates are used. The certificate contains the name of
the person (or the organization), together with the public
key. A Certificate Authority (CA) signs (i.e., encrypts) the
certificate using its private key. Consequently, the
certificate can only be decrypted using CA's public key. (W,
2003)
Message Digest is a hashed function (H) whose sole purpose
is to take an input Stream (M) and out put the stream to a
fixed length string and the main Characteristics that it should
have are irreversible and collision resistant.
MAC is a special method to involve a key into computing
the digest. MAC depend upon both the message and the key.

B) Message Confidentiality:-

4)

2) MOTIVATION:Some of the key motivations to introduce SSL are to

somehow ensure following properties when having
communication over an unsecure channel. (W, 2003)

SSL WORKING:-

To understand the working of SSL Two important

concept session and connection should be understood
first. Connection are basically transports that provide
service for SSL and basically transient in nature. Every
connection is associated to one session. Sessions create
and association between client and server and mostly
created during the handshake process, they mostly define
security parameters to be shared across the connections.

Fig.3: Record protocol working flow.

(W, 2003)

Fig.2: Shows the SSL 3 block and where it works on the

OSI Layer. (W, 2003)

There are two phases is a SSL session Hand shake and

data transfer. Hand shake should be done before the data
transfer. The Hand shake involves two steps as well
Cipher suite negotiation and key exchange.
Below Figure explain the cypher suite negation from
client and server response. (Hock-Chuan, 2009)

(Hock-Chuan, 2009)
The complete picture of SSL for typical client and server
session.

(W, 2003)

The above diagram explain the working at record

protocol. The data that should be transmitted
(Application data big block) is Divided into fragments
after wards those fragments are compressed using SHA
or MD5 in case of SSL2 after wards MAC is attached to
the compressed block that compressed block is than
encrypted and appended with the record header (the Last
block before transferring the message).

5) Major Flaws is SSL V2

Following are some majors flaws in SSL 2
(LorenWeith, 2006)
1) Short key length:In export-weakened modes, SSL 2.0
unnecessarily weakens the authentication keys
to 40 bits.
2) Weak MAC construction:SSL 2.0 has a weak MAC construction that uses
the MD5 hash function with a secret prefix,
making it vulnerable to length extension attacks
3) Message integrity vulnerability:
SSL 2.0 does not have any protection for the
handshake, meaning a man-in-the-middle
downgrade attack can go undetected.
4) Cipher suite rollback attack:
During a cipher suite rollback attack, an active
attacker edits the list of cipher suite preferences
in the hello messages to force both endpoints to
use a weaker form of encryption than they
would choose.
5) Message authentication uses MD5:There are collisions found in MD5 so using
only MD5 is a big problem in SSl 2
6) Same keys are used for encryption and
message authentication.
7) Truncation attacks are possible:SSL 2.0 uses the TCP connection close to
indicate the end of data. This means that
truncation attacks are possible: the attacker
simply forges a TCP FIN, leaving the recipient
unaware of an illegitimate end of data message
8) No compression
SSl 2 passes the data without compression and
could enhance the chances of forging with the
message when message is sent across the
network.

6) SSL 3 Fixing the loop holes:1)

Minimizing impact of random padding:

It minimize the effects of random padding and
padding length is also authenticated.
2) support for anonymous connections:
Anonymous connections are introduced to
reduce the expansive process of doing
handshake again and starting a session
3) Protection against outside manipulation of
hand shake.
As added protection is inserted by authentication
every request so now handshakes are more
secure in ssl3.
4) Truncation attacks are not possible in
SSLv3:
Closure alerts are added so that the connection
only closes without error if a closure message
has been received.
5) Compression is required by SSLv3:
As explained in the previous section
compression is mandatory to compress the
fragments into smaller chunks.
6) Diffie-Hellman key exchange:
More flexibility is added to the key exchange so
that the vulnerabilities in the old ones are taken
care off.
7) SHA -1 is introduced
SHA one hash function is introduced which is
much more secure than MD5 and until now zero
collisions are detected in SHA.
8) Increased key length:SSL 3.0 use 128 bits authentication keys.

7) VERSION ROLL BACK ATTACK AND

ITS PREVENTION IN SSL3:When implementing SSL v3 they needed to keep in
mind the requirement that since SSL 3 is new and
not many servers can incorporate it, and if they
force the use of SSL 3 they might lose a big market
share. (WagnerandB.Schneier, 1996)
They decided to make SSLv3
compatible with SSL v2 as well. So a simple attack
could be to alter the client hello and ask to
communicate in SSL v2 even the client and server
both are SSL 3 compatible.

Paul Kocher designed an excellent strategy to

detect the attack in different version (kocher, 1996).
He makes the client that supports SSL 3.0 embed
several fixed redundancy in the RSA PKCS
padding bytes. In the server side, if RSA encryption
includes the RSA PKCS padding bytes, the server
will not permit RSA-encrypted key-exchange over
version 2.0. This makes the endpoints which
support SSL version 3.0 to have the ability to detect
version rollback attacks. Furthermore, old SSL 2.0
clients will be using random PKCS padding, so they
will still work with servers that support SSL 2.0
(WagnerandB.Schneier, 1996).

8) SUMMARY:SSL 3 was a major enhancement to SSL 2 it add

more protection and more security as compared to
version 2. Now a days version 2 support is almost
obsolete and browsers dont allow communication
in SSL v2. The reason for a new version is because
of the vulnerabilities in the old one. Increasing the
key length and securing the key with pre master
secret allows in to be more tolerant to the attacks
and versioning increases the confidentiality aspect
of version 3 as if some part is manipulated by an
Eavesdropper the change is version would reflect
that.

9) LESSON LEARNED:Random padding is not the solution to add security

to the already existing cypher text. MD5 usage in a
protocol make it more suspect able to the collisions
attacks so use SHA instead of MD5. SSL 3 has an
excellent security measures against active attacks
but is weak against the passive attacks.

Works Cited
Hock-Chuan, C. (2009, october 20). HTTp
security with SSl. Retrieved from
programming
notes:
http://www3.ntu.edu.sg/home/ehchu
a/programming/webprogramming/HT
TP_SSL.html
kocher, P. (1996). Personal communication.
LorenWeith. (2006, July 3). Differences Betwe
en SSLv2, SSLv3, and TLS. Retrieved
from
Baidu:
http://wenku.baidu.com/view/b01097
4e2b160b4e767fcf57.html
RH, I. (1999, 2 10). How DigiCash Blew
Everything. Retrieved from Next!
Magazine:
http://cryptome.org/jya/digicrash.htm

Fig.4: Explaining the rollback to v2 even when

both are v3 capable

W, S. (2003). Cryptography and Network

Security, Principles and Practices. In S.

W, Cryptography and Network Security,

Principles and Practices (p. 3rd edition).
Prentice Hall.
WagnerandB.Schneier. (1996, November).
Analysis of the SSL 3.0 Protocol. The
Second USENIX Workshop on Electronic
Commerce Proceedings, pp. 29-40.