SSL Secure socket layer

0
2nd Assignment of Comm. Sys. & Computer N.W
Department of Information Technology,
Institute of Graduate Studies and Research,
University of Alexandria, Egypt.
Presented by:
Ahmed Atef Elnaggar
Supervisor:
Prof . Shawkat K.Guirguis

1
Abstract:
The Secure Socket Layer (SSL) and Transport Layer Security (TLS) is the most
widely deployed security protocol used today. It is essentially a protocol that
provides a secure channel between two machines operating over the Internet or
an internal network. In today’s Internet focused world, the SSL protocol is
typically used when a web browser needs to securely connect to a web server
over the inherently insecure Internet.
Contents
1- Introduction
1.1- Objectives and Scope…………………………..…..2
1.2- Basic overview………………………………….….2
1.3- Technical overview …………………….................2
1.4- Brief history…………………………….................3
1.5- Family tree of SSL……………………………..…3
1.6- SSL v2 vs. v3……………………………….….….3
2- SSL protocol structure………………………….…….…4
3-How Does SSL Work with My Browser?..........................5
4- Handshake procedures……………………….................6
5- SSL applications……………………………….….….....8
6-SSL Goals………………………………………..…….…9
7- Report advices…………………………………...……..10
8- Conclusion……………………………………………..10
9- Future scope…………………………………………...10
10- References……………………………………………11
11- Glossary ………………………………………..........12
Kindly find the attached softcopy.

2
1- Introduction
SSL (Secure Sockets Layer) is a protocol that provides a secure channel
between two machines, and facilities for protecting data in transit and
identifying the machine with which you are communicating.
1.1- Objectives and Scope
This report is intended to serve as a primer for learning the basic concepts of
how SSL operates. Overview information on how SSL termination devices are
deployed in a Web server environment also is included.
Because this report is intended for a technical audience, a basic understanding
of network infrastructure and security concepts is assumed.
The SSL protocol is intended primarily for readers who will be studying
network security and those doing cryptographic analysis of the protocol. The
spec has been written with this in mind, and it is intended to reflect the needs of
those two groups. For that reason, this document is intended to supply some
details of service definition and interface definition which are included in the
body of the report.
1.2- Basic Overview
Secure Socket Layer (SSL) is an effective method of protecting data which is
sent over a local or wide area network. It works by encrypting data sent over a
network,
It can be configured on both wired and wireless networks and will work with
other forms of security such as WPA keys and firewalls.
1.3- Technical Overview
The primary goal of the SSL protocol is to provide privacy and reliability
between two communicating applications. The protocol is composed of two
layers. At the lowest level, layered on top of some reliable transport protocol
(e.g., TCP [RFC0793]), is the SSL record protocol. The SSL record protocol is
used for encapsulation of various higher level protocols. One such encapsulated
protocol, the SSL handshake protocol, allows the server and client to
authenticate each other and to negotiate an encryption algorithm and
cryptographic keys before the application protocol transmits or receives its first
byte of data. One advantage of SSL is that it is application protocol
independent. A higher level protocol can layer on top of the SSL protocol
transparently.

3
1.4- Brief history
We present a brief history of the development of SSL protocol.
Brief History:
1. SSLv1 (1994), all the pre-IETF versions of SSL was designed by engineers
at Netscape Communications.
2. SSLv2 started in 1994. The initial design goal is to provide confidentiality
between client and servers. Then further provide:
(a) Encryption of a session.
(b) Authentication of a server, and optionally a client.
(c) Message authentication.
3. SSLv3 [RFC 6101 2011], designed in 1995, targets at fixing the problems
from SSLv2.Led by the Internet Engineering Task Force (IETF),
Transportation Layer Security (TLS) was designed between 1997 and 1999
by IETF [RFC 2246 1999]. (Most commonly deployed protocol).
4. The Microsoft version of Private Communication Technology (PCT 1995)
and Secure Transport Layer Protocol (STLP 1996) were originated from the
SSLv2 and SSLv3.
5. The wireless version of TLS is called WTLS (1998).
1.5- Family tree of SSL: As shown in Fig1
1.6- SSL v2 vs. v3
 Downgrade Attack: Crypto choices not protected in V2. Finished
message in v3 contains digest of all previous messages
 Truncation Attack: V2 closes SSL on TCP connection close ⇒ not
protected. V3 added session finished message to close SSL session.
Figure 1

4
Figure 2: SSL protocol structure
2-SSL protocol structure
SSL is designed on top of TCP. In Figure 2, the SSL protocol structure is
presented. The Record Layer support four types of sub-layer protocols:
Application data, Alert protocol, Handshake protocol, and Change Cipher
Specification protocol.
Our discussion is focused on SSLv2. The SSL message transmission sequence
is presented in Figure 2.
 SSL Handshake Protocol
 negotiation of security algorithms and parameters
 key exchange
 server authentication and optionally client authentication
 SSL Record Protocol
 fragmentation
 compression
 message authentication and integrity protection
 encryption
 SSL Alert Protocol
 error messages (fatal alerts and warnings)
 SSL Change Cipher Spec Protocol
 a single message that indicates the end of the SSL handshake

5
3-How does SSL work with my browser?
Technically, SSL is a transparent protocol which requires little interaction from
the end user when establishing a secure session. In the case of a browser for
instance, users are alerted to the presence of SSL when the browser displays a
padlock, or, in the case of Extended Validation SSL, when the address bar
displays both a padlock and a green bar. This is the key to the success of SSL –
it is an incredibly simple experience for end users.
Standard SSL Certificates (such as Global Sign Domain SSL and Organization
SSL) display: As shown in Figure 3
As opposed to unsecured HTTP URLs which begin with "http://" and use port
80 by default, secure HTTPS URLs begin with "https://" and use port 443 by
default.
HTTP is insecure and is subject to eavesdropping attacks which, if critical
information like credit card details and account logins is transmitted and picked
up, can let attackers gain access to online accounts and sensitive information.
Ensuring data is either sent or posted through the browser using HTTPS is
ensuring that such information is encrypted and secure.
Behind the scenes, the browser retrieves the SSL certificate whenever it
connects to a secure site. The browser check to make sure that the certificate has
not expired, whether or not the issuing authority is one that the browser trusts,
and that the certificate is being used by the same website to which it was issued.
If either safety check fails, the browser will let the user know that the site is not
secured by SSL through a warning message. The user has the choice of trusting
the site or leaving.
Figure 3:
SSL Standard

6
4- Handshake procedures
The steps involved in the SSL handshake are as follows (note that the following
steps assume the use of the cipher suites listed in Cipher Suites with RSA Key
Exchange: Triple DES, RC4, RC2, DES) As shown in Figure 4:
1) The client sends the server the client's SSL version number, cipher settings,
session-specific data, and other information that the server needs to
communicate with the client using SSL.
2) The server sends the client the server's SSL version number, cipher settings,
session-specific data, and other information that the client needs to
communicate with the server over SSL. The server also sends its own
certificate, and if the client is requesting a server resource that requires client
authentication, the server requests the client's certificate.
3) The client uses the information sent by the server to authenticate the server
(see Server Authentication for details). If the server cannot be authenticated,
the user is warned of the problem and informed that an encrypted and
authenticated connection cannot be established. If the server can be
successfully authenticated, the client proceeds to step 4.
4) Using all data generated in the handshake thus far, the client (with the
cooperation of the server, depending on the cipher being used) creates the
pre-master secret for the session, encrypts it with the server's public key
(obtained from the server's certificate, sent in step 2), and then sends the
encrypted pre-master secret to the server.
5) If the server has requested client authentication (an optional step in the
handshake), the client also signs another piece of data that is unique to this
handshake and known by both the client and server. In this case, the client
sends both the signed data and the client's own certificate to the server along
with the encrypted pre-master secret.
6) If the server has requested client authentication, the server attempts to
authenticate the client (see Client Authentication for details). If the client
cannot be authenticated, the session ends. If the client can be successfully
authenticated, the server uses its private key to decrypt the pre-master secret,
and then performs a series of steps (which the client also performs, starting
from the same pre-master secret) to generate the master secret.
7) Both the client and the server use the master secret to generate the session
keys, which are symmetric keys used to encrypt and decrypt information
exchanged during the SSL session and to verify its integrity (that is, to detect
any changes in the data between the time it was sent and the time it is
received over the SSL connection).
8) The client sends a message to the server informing it that future messages
from the client will be encrypted with the session key. It then sends a
separate (encrypted) message indicating that the client portion of the
handshake is finished.

7
9) The server sends a message to the client informing it that future messages
from the server will be encrypted with the session key.
It then sends a separate (encrypted) message indicating that the server
portion of the handshake is finished.
10) The SSL handshake is now complete and the session begins. The client
and the server use the session keys to encrypt and decrypt the data they send
to each other and to validate its integrity.
11) This is the normal operation condition of the secure channel. At any time,
due to internal or external stimulus (either automation or user intervention),
either side may renegotiate the connection, in which case, the process repeats
itself
Figure 4: Handshake procedures

8
5- SSL applications
SSL was originally created to secure web traffic information, in particular data
sent between web browsers and servers. For example, when you use Internet
Banking and you see https:// and the little padlock in bottom right hand corner
of the web browser, you are using SSL. It then grew to work with other
applications such as telnet, printers and FTP software in order to become a
universal solution for online security. Its original design intentions are still
being used today by many online retailers and banks to secure sensitive data,
such as credit card numbers, customer records etc.
SSL uses extremely high levels of encryption and is trusted by banks all over
the world since it is unlikely that it will be broken. According to VeriSign™, a
leading online SSL Certificate Authority (CA) 1, it would take a hacker ‘well
over a lifetime’ to hack through a standard SSL encrypted document.
In practice, how is SSL used in today’s modern e-commerce
enabled / online workflow and service society?
 To secure online credit card transactions.
 To secure system logins and any sensitive information exchanged online.
 To secure webmail and applications like Outlook Web Access, Exchange
and Office Communications Server.
 To secure workflow and virtualization applications like Citrix Delivery
Platforms or cloud-based computing platforms.
 To secure the connection between an email client such as Microsoft
Outlook and an email server such as Microsoft Exchange.
 To secure the transfer of files over https and FTP(s) services such as
website owners updating new pages to their websites or transferring large
files.
 To secure hosting control panel logins and activity like Parallels, cPanel.
 To secure intranet based traffic such as internal networks, file sharing,
extranets, and database connections.
 To secure network logins and other network traffic with SSL VPNs such
as VPN Access Servers or applications like the Citrix Access Gateway.

9
6-SSL goals
All mentioned applications have a number of shared themes:
 Confidentiality
The data being transmitted over the Internet or network needs confidentiality. In
other words, people do not want their credit card number, account login,
passwords or personal information to be exposed over the Internet.
 Integrity Protection
The data needs to remain integral, which means that once credit card details and
the amount to be charged to the credit card have been sent, a hacker sitting in
the middle cannot change the amount to be charged and where the funds should
go.
 Authentication
Your organization needs identity assurance to authenticate itself to customers /
extranet users and ensure them they are dealing with the right organization.
Your organization needs to comply with regional, national or international
regulations on data privacy, security and integrity
Some additional goals of SSL protocol, in order of their priority are:
I. Cryptographic security
SSL should be used to establish a secure connection between two parties.
II. Interoperability
Independent programmers should be able to develop applications utilizing
SSL that will then be able to successfully exchange cryptographic
parameters without knowledge of one another’s code.
III. Extensibility
SSL seeks to provide a framework into which new public key and bulk
encryption methods can be incorporated as necessary.
This will also accomplish two sub-goals: to prevent the need to create a
new protocol (and risking the introduction of possible new weaknesses)
and to avoid the need to implement an entire new security library.
IV. Relative efficiency
Cryptographic operations tend to be highly CPU intensive, particularly
public key operations. For this reason, the SSL protocol has incorporated
an optional session caching scheme to reduce the number of connections
that need to be established from scratch. Additionally, care has been taken
to reduce network activity.

10
7- Report advices for defending against web application
session-tracking attacks
 Digitally sign or hash session-tracking information using a cryptographic
algorithm.
 Encrypt the information in the URL, hidden form element, or cookie; don’t
just rely on SSL.
 Make sure your session IDs are long enough to prevent accidental collision.
 Consider making your session IDs dynamic, changing from page to page
throughout your web application.
 Apply a time stamp within the session ID variable and encrypt it.
8- Conclusions
The Secure Sockets Layer (SSL) protocol uses a combination of public-key and
symmetric-key encryption. Symmetric-key encryption is much faster than
public-key encryption; however, public-key encryption provides better
authentication techniques. An SSL session always begins with an exchange of
messages called the SSL handshake. The handshake allows the server to
authenticate itself to the client by using public-key techniques, and then allows
the client and the server to cooperate in the creation of symmetric keys used for
rapid encryption, decryption, and tamper detection during the session that
follows. Optionally, the handshake also allows the client to authenticate itself to
the server.
9- Future scope
SSL is vital to Web security. It provides a strong sense of confidentiality,
message integrity, and server authentication to users. Presently, SSL/TLS
become backbone of not only in E-commerce but in any secured information
exchange across Internet which is tied closely to consumer confidence in the
operation of SSL across the net. In the future, SSL termination devices will be
able to handle more transactions at a faster rate. The encryption of key lengths
and the cipher suites used will also continue to evolve in order to ensure the
security of sensitive information over the Web. This way, e-commerce will be
able to continue to grow in popularity as users grow more confidants in
shopping and banking online, and embracing new online applications.

11
10- References
Websites:-
1. www.scribd.com
2. http://en.wikipedia.org/wiki/Ssl
3. www.open ssl .org /
4. www.VeriSign.com
Books:-
1. M. Bellare, R. Canetti, and H. Krawczyk, Keying Hash Functions for
Message Authentication," Advances in Cryptology|CRYPTO '96
Proceedings, Springer-Verlag, 1996, pp. 1{15.
2. S. Bellovin, Problem Areas for the IP Security Protocols", Proceedings of
the Sixth USENIX Security Symposium, Usenix Association, 1996, pp.
3. A. Freier, P. Karlton, and P. Kocher, The SSL Protocol Version 3.0",
March 4 1996, Internet Draft, work in progress. [Koc96] P. Kocher, personal
communication, 1996.
4. V. Voydock and S. Kent, Security Mechanisms in High-Level Network
Protocols", ACM Computing Surveys, v. 5, n. 2, June 1983, pp. 135{171.
5. Benaloh, B. Lampson, D. Simon, T. Spies, and B. Yee, Microsoft
Corporation's
6. SSL & TLS Essentials-by Stephen A. Thomas
7. Network Security with Open SSL-by John Viega, et al
8. SSL and TLS-by Eric Rescorla (Author)
9. T. Dierks, E. Rescorla (August 2008). "The Transport Layer Security (TLS)
Protocol, Version 1.2".
10. A. Freier, P. Karlton, P. Kocher (August 2011). "The Secure Sockets Layer
(SSL) Protocol Version 3.0".
11. "SSL/TLS in Detail". Microsoft TechNet. Updated July 31, 2003.
12. "Description of the Secure Sockets Layer (SSL) Handshake". Support.
Microsoft.com. 2008-07-07. Retrieved 2012-05-17

12
11- Glossary
Certificate A digitally signed statement from one entity (a company or person)
that says that the public key and other information from another
entity have a certain value. When data is digitally signed, its
authenticity and integrity can be validated by the signature.
HTTP Hypertext Transfer Protocol
HTTPs Hypertext Transfer Protocol secure
3DES Triple Data Encryption Standard
DES Data Encryption Standard
IP Internet Protocol
MAC Message Authentication Code
MTU Maximum Transfer Unit
NIC Network Interface Card
OSI Open Systems Interconnection
Private key a number that is known only to its owner. The owner uses the
private key to read (decrypt) an encrypted message.
RC2, RC4 A series of encryption algorithms published by RSA Security; all
developed by cryptography pioneer Ron Rivest. (Rivest Cipher 2,
or Ron’s Code 2 = RC2) All of them are important commercial
implementations of symmetric key cryptography where the entity
that encrypts and the entity that decrypts both must know the same
key.
RFC Request for Comment
RSA Rivest-Shamir-Adleman
RTO Retransmission Timeout
ID Identifier
Session ID After a user authenticates to a web application (by providing a user
ID and password, or through a client-side certificate on an HTTPS
session), most web applications generate a session ID to track the
user’s session.
SSL Secure Socket Layer
SSN Stream Sequence Number
TCP Transmission Control Protocol
TLS Transport Layer Security
TSN Transmission Sequence Number
UDP User Datagram Protocol
ULP Upper Layer Protocol
Thanks for reading

SSL Secure socket layer

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to SSL Secure socket layer (20)

More from Ahmed Elnaggar (9)

Recently uploaded (20)

SSL Secure socket layer