Escolar Documentos
Profissional Documentos
Cultura Documentos
net/publication/283297122
CITATIONS READS
0 1,148
1 author:
Ahmed Elnaggar
Information Technology Institute
24 PUBLICATIONS 2 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Ahmed Elnaggar on 28 October 2015.
Presented by:
Ahmed Atef Elnaggar
Supervisor:
Prof . Shawkat K.Guirguis
0
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
1
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.
2
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).
Figure 1
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.
3
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.
4
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
Figure 3:
SSL Standard
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.
5
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.
6
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
7
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.
8
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
9
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.
10
10- References
Websites:-
1. www.scribd.com
2. http://en.wikipedia.org/wiki/Ssl
4. www.VeriSign.com
Books:-
11
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
12