0% found this document useful (0 votes)
5 views59 pages

Unit-V: WWW, HTTP and Digital Signature

The document discusses the World Wide Web (WWW), its architecture including clients (browsers) and servers, and the protocols used for data transfer like HTTP. It explains the concepts of static, dynamic, and active documents, as well as the role of cookies and digital signatures in web interactions. Additionally, it details the differences between conventional and digital signatures, including their verification methods and the use of asymmetric keys.

Uploaded by

Jayaprasanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views59 pages

Unit-V: WWW, HTTP and Digital Signature

The document discusses the World Wide Web (WWW), its architecture including clients (browsers) and servers, and the protocols used for data transfer like HTTP. It explains the concepts of static, dynamic, and active documents, as well as the role of cookies and digital signatures in web interactions. Additionally, it details the differences between conventional and digital signatures, including their verification methods and the use of asymmetric keys.

Uploaded by

Jayaprasanna
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 59

UNIT-V

WWW,HTTP AND DIGITAL SIGNATURE


WWW (World Wide Web)
• The WWW today is a distributed client-server service, in which a client
using a browser can access a service using a server.
• However, the service provided is distributed over many locations called
sites.
• Each site holds one or more documents, referred to as Web pages. Each
Web page can contain a link to other pages in the same site or at other
sites. The pages can be retrieved and viewed by using browsers.
Client (Browser)
• Each browser usually consists of three parts: a controller, client protocol, and
interpreters.
• The controller receives input from the keyboard or the mouse and uses the
client programs to access the document.
• After the document has been accessed, the controller uses one of the
interpreters to display the document on the screen.
• The client protocol can be one of the protocols such as FTP or HTTP.
• The interpreter can be HTML, Java, or JavaScript, depending on the type of
document.

Fig. Browser
Server
• The Web page is stored at the server. Each time a client request arrives,
the corresponding document is sent to the client. To improve efficiency,
servers normally store requested files in a cache in memory; memory is
faster to access than disk.
• A server can also become more efficient through multithreading or
multiprocessing. In this case, a server can answer more than one request
at a time.
Uniform Resource Locator (URL)
• A client that wants to access a Web page needs the address. To facilitate
the access of documents distributed throughout the world, HTTP uses
locators.
• The uniform resource locator (URL) is a standard for specifying any kind of
information on the Internet. The URL defines four things: protocol, host
computer, port, and path
• The protocol is the client/server program used to retrieve the
document.
• Many different protocols can retrieve a document; among them is
FTP or HTTP. The most common today is HTTP.
• Web pages are usually stored in computers, and computers are given
alias names that usually begin with the characters "www".
• The URL can optionally contain the port number of the server.
• If the port is included, it is inserted between the host and the path,
and it is separated from the host by a colon.
• Path is the pathname of the file where the information is located.
• Note that the path can itself contain slashes that, in the UNIX
operating system, separate the directories from the subdirectories
and files.
Cookies
• A cookie, also known as an HTTP cookie, web cookie, or browser
cookie, is a small piece of data sent from a website and stored in
a user's web browser while the user is browsing that website.
• Every time the user loads the website, the browser sends the
cookie back to the server to notify the website of the user's
previous activity.
• Cookies were designed to be a reliable mechanism for websites
to remember stateful information (such as items in a shopping
cart) or to record the user's browsing activity (including clicking
particular buttons, logging in, or recording which pages were
visited by the user as far back as months or years ago).
• The main purpose of cookies is to identify users and possibly
prepare customized web pages for them.
• When you enter a web site using cookies, you may be asked to
fill out a form providing such information as your name and
interests. This information is packaged into a cookie and sent to
your Web browser which stores it for later use.
• The next time you go to the same Web site, your browser will
send the cookie to the Web server.
• The server can use this information to present you with custom
Web pages. So, for example, instead of seeing just a generic
welcome page you might see a welcome page with your name
on it.
Web Documents
• The documents in the WWW can be grouped into three broad categories:

Fig. Categories of web documents

• The category is based on the time at which the contents of the document
are determined.
Static Documents
• Static documents are fixed-content documents that are created and stored in a
server.
• The client can get only a copy of the document.
• In other words, the contents of the file are determined when the file is created,
not when it is used. When a client accesses the document, a copy of the document
is sent. The user can then use a browsing program to display the document.

Fig. Static document


HTML

• Hypertext Markup Language (HTML) is a


language for creating Web pages.
• The two tags <B> and </B> are instructions for
the browser.

Fig. Boldface tags


• A Web page is made up of two parts: the head and the body. The head is
the first part of a Web page. The head contains the title of the page and
other parameters that the browser will use.
• The actual contents of a page are in the body, which includes the text and
the tags. Whereas the text is the actual information contained in a page,
the tags define the appearance of the document.
• Every HTML tag is a name followed by an optional list of attributes, all
enclosed between less-than and greater-than symbols (« and >).
• The beginning tag can have attributes and values and starts with the name
of the tag. The ending tag cannot have attributes or values but must have
a slash before the name of the tag.
Example: 1
This example shows how tags are used to let the browser format the appearance of the text.
<HTML>
<HEAD>
<TITLE> First Sample Document </TITLE>
</HEAD>
<BODY>
<CENTER>
<H1><B> ATTENTION </B></H1>
</CENTER>
You can get a copy of this document by:
<UL>
<LI> Writing to the publisher
<LI> Ordering online
<LI> Ordering through a bookstore
</UL>
</BODY>
</HTML>
Dynamic Documents
• A dynamic document is created by a Web server whenever a
browser requests the document.
• Dynamic documents are sometimes referred to as server-site
dynamic documents.
• When a request arrives, the Web server runs an application
program or a script that creates the dynamic document.
• A very simple example of a dynamic document is the retrieval of
the time and date from a server.
Common Gateway Interface (CGI)
• The Common Gateway Interface (CGI) is a technology that creates
and handles dynamic documents.
• CGI is a set of standards that defines how a dynamic document is
written, how data are input to the program, and how the output
result is used.
Dynamic document

A few technologies have been involved in creating dynamic documents


using scripts.
Among the most common are Hypertext Preprocessor (PHP), which uses
the Perl language; Java Server Pages (JSP), which uses the Java language for
scripting; Active Server Pages (ASP), a Microsoft product which uses Visual Basic
language for scripting; and ColdFusion, which embeds SQL database queries in the
HTML document.
Dynamic pages, web applications
(a) Client-side scripting with JavaScript.
(b) Server-side scripting with PHP.
Fig. Various technologies used to generate dynamic pages.
Active Documents
• For many applications, we need a program or a script to be run at the
client site. These are called active documents.
• For example, suppose we want to run a program that creates animated
graphics on the screen or a program that interacts with the user.
• The program definitely needs to be run at the client site where the
animation or interaction takes place.
• When a browser requests an active document, the server sends a copy of
the document or a script. The document is then run at the client (browser)
site.
Java Applets
• One way to create an a high-level programming language, a
run-time environment, and a class library active document is
to use Java applets.
• An applet is a program written in Java on the server. It is
compiled and ready to be run.
• The document is in byte-code (binary) format. The client
process (browser) creates an instance of this applet and
runs it.
• A Java applet can be run by the browser in two ways.
– In the first method, the browser can directly request the Java
applet program in the URL and receive the applet in binary form.
– In the second method, the browser can retrieve and run an HTML
file that has embedded the address of the applet as a tag.
HTTP
• The Hypertext Transfer Protocol (HTTP) is a protocol used mainly to access data on the
World Wide Web. It is similar to FTP because it transfers files and uses the services of TCP.
• HTTP is like SMTP because the data transferred between the client and the server look like
SMTP messages. SMTP messages are stored and forwarded, but HTTP messages are
delivered immediately.
• HTTP uses the services of TCP on well-known port 80.
HTTP Transaction
• Although HTTP uses the services of TCP, HTTP itself is a stateless protocol. The client
initializes the transaction by sending a request message. The server replies by sending a
response.
Request & response messages

Request Message
A request message consists of a request line, a header, and sometimes a body.

Fig. Request line


• Request type: This field is used in the request
message.
• In version 1.1 of HTTP, several request types
are defined. The request type is categorized
into methods as defined in Table
Fig.URL format

Fig. Status line


Response Message
• A response message consists of a status line, a header, and
sometimes a body.
• Version: The most current version of HTTP is 1.1.
• Status code: This field is used in the response message. The status
code field is similar to those in the FTP and the SMTP protocols. It
consists of three digits. Whereas the codes in the 100 range are only
informational, the codes in the 200 range indicate a successful
request. The codes in the 300 range redirect the client to another
URL, and the codes in the 400 range indicate an error at the client
site.
• Finally, the codes in the 500 range indicate an error at the server
site. We list the most common codes in Table.
• Status phrase: This field is used in the response message. It explains
the status code in text form.
• Header: The header exchanges additional information between the
client and the server. For example, the client can request that the
document be sent in a special format, or the server can send extra
information about the document. The header can consist of one or
more header lines. Each header line has a header name, a colon, a
space, and a header value.
• A header line belongs to one of four categories: general header,
request header, response header, and entity header. A request
message can contain only general, request, and entity headers. A
response message, on the other hand, can contain only general,
response, and entity headers.
• General header: The general header gives general information about the
message and can be present in both a request and a response.
• Request header: The request header can be present only in a request
message. It specifies the client's configuration and the client's preferred
document format.
• Response header: The response header can be present only in a response
message. It specifies the server's configuration and special information
about the request.
• Entity header: The entity header gives information about the body of the
document. Although it is mostly present in response messages, some
request messages, such as POST or PUT methods, that contain a body also
use this type of header.
• Body: The body can be present in a request or response message. Usually,
it contains the document to be sent or received.
HTTP supports proxy servers. A proxy server is a computer that keeps copies of responses to recent
requests.
DIGITAL SIGNATURE
• A digital signature can use a pair of asymmetric keys (a public
one and a private one).
• The signature is proof to the recipient that the document
comes from the correct entity.
• When a customer signs a check to himself, the bank needs to
be sure that the check is issued by that customer and nobody
else.
• A signature on a document, when verified, is a sign of
authentication; the document is authentic.
• When Alice sends a message to Bob, Bob needs to check the
authenticity of the sender; he needs to be sure that the
message comes from Alice and not Eve. Bob can ask Alice to
sign the message electronically.
Digital signature process

A digital signature needs a public-key system.


The signer signs with her private key; the verifier verifies with the signer’s public
key.
Comparison
There are two types of signatures: conventional and digital.
Inclusion
• A conventional signature is included in the document; it is part of the document. When we
write a check, the signature is on the check; it is not a separate document.
• On the other hand, when we sign a document digitally, we send the signature as a separate
document.
• The sender sends two documents: the message and the signature. The recipient receives
both documents and verifies that the signature belongs to the supposed sender. If this is
proved, the message is kept; otherwise, it is rejected.
Verification Method
• The second difference between the two types of documents is the method of verifying the
signature.
• In conventional signature, when the recipient receives a document, she compares the
signature on the document with the signature on file.
• If they are the same, the document is authentic. The recipient needs to have a copy of this
signature on file for comparison.
• In digital signature, the recipient receives the message and the signature.
• A copy of the signature is not stored anywhere. The recipient needs to apply a verification
technique to the combination of the message and the signature to verify the authenticity.
Relationship
• In conventional signature, there is normally a one-to-many relationship between a
signature and documents. A person, for example, has a signature that is used to sign
many checks, many documents, etc.
• In digital signature, there is a one-to-one relationship between a signature and a
message. Each message has its own signature. The signature of one message cannot
be used in another message.
• If Bob receives two messages, one after another, from Alice, he cannot use the
signature of the first message to verify the second. Each message needs a new
signature.
Duplicity
• Another difference between the two types of signatures is a quality called duplicity.
• In conventional signature, a copy of the signed document can be distinguished from
the original one on file.
• In digital signature, there is no such distinction unless there is a factor of time
(such as a timestamp) on the document.
• For example, suppose Alice sends a document instructing Bob to pay Eve. If Eve
intercepts the document and the signature, she can resend it later to get money
again from Bob.
Need for Keys
• In conventional signature a signature is like a private "key" belonging to the
signer of the document.
• The signer uses it to sign a document; no one else has this signature. The copy of
the signature is on file like a public key; anyone can use it to verify a document,
to compare it to the original signature.
• In digital signature, the signer uses her private key, applied to a signing
algorithm, to sign the document.
• The verifier, on the other hand, uses the public key of the signer, applied to the
verifying algorithm, to verify the document.
Process
• Digital signature can be achieved in two ways: signing the document or signing a
digest of the document.
Signing the Document
• Signing a document is encrypting it with the private key of the sender; verifying
the document is decrypting it with the public key of the sender.
• In a cryptosystem, we use the private and
public keys of the receiver; in digital signature,
we use the private and public key of the
sender.

Fig. Signing the message itself in digital signature


Signing the Digest
• We mentioned that the public key is very inefficient in a cryptosystem if we are
dealing with long messages.
• In a digital signature system, our messages are normally long, but we have to
use public keys. The solution is not to sign the message itself; instead, we sign
a digest of the message.
• Hash function is just a method of compressing strings
– E.g., H : {0,1}*  {0,1}160
– Input is called “message”, output is “digest”
• A carefully selected message digest has a one-to-one relationship with the
message.
• The sender can sign the message digest, and the receiver can verify the
message digest. The effect is the same.
• A digest is made out of the message at Alice's site.
• The digest then goes through the signing process using Alice's private key.
• Alice then sends the message and the signature to Bob. In some systems, the
signature is a set of values.
Digital signature process
Fig. Signing the digest in a digital signature
Services

• A digital signature can provide three out of the five services we mentioned for a
security system: message integrity, message authentication, and
nonrepudiation.
• Note that a digital signature scheme does not provide confidential
communication.
• If confidentiality is required, the message and the signature must be encrypted
using either a secret-key or public-key cryptosystem.
Message Integrity
• The integrity of the message is preserved even if we sign the whole message
because we cannot get the same signature if the message is changed.
• The signature schemes today use a hash function in the signing and verifying
algorithms that preserve the integrity of the message.
Message Authentication
• A secure signature scheme, like a secure conventional signature (one that
cannot be easily copied), can provide message authentication.
• Bob can verify that the message is sent by Alice because Alice's public key is
used in verification. Alice's public key cannot create the same signature as Eve's
private key.
Message Nonrepudiation
• If Alice signs a message and then denies it, can Bob later prove that Alice
actually signed it? For example, if Alice sends a message to a bank (Bob)
and asks to transfer $10,000 from her account to Ted's account, can Alice
later deny that she sent this message?
• With the scheme we have presented so far, Bob might have a problem.
• Bob must keep the signature on file and later use Alice's public key to
create the original message to prove the message in the file and the newly
created message are the same.
• This is not feasible because Alice may have changed her private/public key
during this time; she may also claim that the file containing the signature is
not authentic.
• One solution is a trusted third party. People can create a trusted party
among themselves.
Fig. using a trusted center for non rupudiation
Signature Schemes
• Several signature schemes have evolved
during the last few decades. Some of them
have been implemented. Such as RSA and DSS
(Digital Signature Standard) schemes.
Authentication Protocols
• Authentication Based on a Shared Secret Key
• Establishing a Shared Key: Diffie-Hellman
• Authentication Using a Key Distribution Center
• Authentication Using Kerberos
• Authentication Using Public-Key Cryptography
Authentication Based on a Shared Secret
Key

Two-way authentication using a challenge-response protocol.


Authentication Based on a Shared Secret Key (2)

A shortened two-way authentication protocol.


Authentication Based on a Shared Secret Key (3)

The reflection attack.


Authentication Based on a Shared Secret Key (4)

A reflection attack on the protocol of Fig. 8-32.


Authentication Based on a Shared Secret Key (5)

Authentication using HMACs.


Establishing a Shared Key:
The Diffie-Hellman Key Exchange
The Diffie-Hellman key exchange.
Establishing a Shared Key:
The Diffie-Hellman Key Exchange
The bucket brigade or man-in-the-middle attack.
Authentication Using a Key Distribution
Center
A first attempt at an authentication protocol
using a KDC.
Authentication Using a Key Distribution Center
(2)
The Needham-Schroeder authentication
protocol.
Authentication Using a Key Distribution Center
(3)
The Otway-Rees authentication protocol (slightly
simplified).
Authentication Using Kerberos
The operation of Kerberos V4.
Authentication Using Public-Key
Cryptography
Mutual authentication using public-key
cryptography.
State Transition Diagram (TCP)
• In state transition diagram, the states involved in opening and
closing a connection is shown above and below ESTABLISHED
state respectively.
• The operation of sliding window (i.e., retransmission) is not
shown.
• The two events that trigger a state transition is:
a. Segment arrives from its peer(e.g. the event on the arc
from LISTEN to SYN_RCVD)
b. The local application process invokes an operation on TCP
(e.g. the active open event on the arc from CLOSE to
SYN_SENT).
CLOSED
Active open/SYN
Passive close close
Open
Client
LISTEN
Server
SYN/SYN+ACK
Send/SYN
SYN_SEN
SYN_RCVD SYN /SYN+ACK Unusual event
T
SYN+ACK/ACK
ACK
Close
/FIN ESTABLISHED
Close/ FIN FIN/ACK
CLOSE_WAIT
FIN_WAIT-1
Close/FIN
FIN/ACK
ACK LAST_ACK
CLOSING
ACK
Timeout after two
FIN_WAIT-2 ACK
segment lifetime CLOSED
FIN/ACK TIME_
WAIT
Fig.TCP connection management finite state machine
The state transition involved in opening a connection is as follows:
1. The server first invokes a passive open on TCP, which causes TCP to move to
LISTEN state
2. Later, the client does an active open, which causes its end of the
connection to send a SYN segment to the server and to move to the
SYN_SENT state.
3. When the SYN segment arrives at the server, it moves to SYN_RCVD state
and responds with a SYN + ACK segment.
4. The arrival of this segment causes the client to move to the ESTABLISHED
state and to send an ACK back to the server.
5. When this ACK arrives, the server finally moves to the ESTABLISHED state.
6. Even if the client's ACK gets lost, sever will move to ESTABLISHED state
when the first data segment from client arrives.
State Transition Diagram

7. In TCP, the application process on both sides of the connection can independently
close its half of the connection.
8. The combinations of transitions from the ESTABLISHED state to CLOSED state are:
ESTABLISHED FIN_WAIT_1 FIN_WAIT_2 TIME_WAIT CLOSED (this side
closes first)
ESTABLISHED CLOSE_WAIT LAST_ACK CLOSED (other side closes first)
ESTABLISHED FIN_WAIT_1 CLOSING TIME_WAIT CLOSED (both side close
simultaneously)

You might also like