The Illustrated Network- P62 ppt

Table 22.4 HTTP Response Headers and Their Uses Accept-Ranges Tells client if server accepts partial content requests using Range request header.. Server Server version of User-Agent re

Entity Headers

Finally, entity headers describe the resource carried in the body of the HTTP message They usually appear in responses, but can appear in PUT and POST requests Many of the entity headers have the same names as the MIME types they are based on, but with important differences The entity headers are outlined in Table 22.5

Table 22.4 HTTP Response Headers and Their Uses

Accept-Ranges Tells client if server accepts partial content requests using Range

request header Typical values are in bytes, or “none” for no support

ETag Gives the entity tag for the entity in the response

Location Gives client a new URL to use instead of one requested

Proxy-Authenticate Tells client how the proxy requires authentication, both method and

parameters needed.

Retry-After Tells client to try the request again later, seconds or by date/time.

Server Server version of User-Agent request header, used for server details.

WWW-Authenticate Tells client how the Web site requires authentication, both method and

parameters needed.

Table 22.5 HTTP Entity Headers and Their Uses

Content-Encoding Describes optional encoding method, usually the compression algorithm

used so that the client can decompress the entity.

Content-Language Specifi es the human language used by the entity It is optional and can

specify multiple languages

Content-Length Size of the entity in bytes (octets) Not used in chunked transfers.

Content-Location Resource location as URL Optional, but used if entity is in multiple places Content-MD5 Used for message integrity checking with Message Digest 5.

Content-Range Used for entities that are part of the complete resource

Content-Type Similar to MIME type and subtype, but not exactly the same.

Expires Data and time after which entity is considered stale.

Last-Modifi ed Date and time server “believes” entity last changed.

CHAPTER 22 Hypertext Transfer Protocol 579

Use of the Last-Modifi ed header is complicated by the fact that the server might not know when an entity was last modifi ed, especially if the resource is “virtual.” For dynamic content, this header should be the same as the time the message was generated

Cookies

A Web server gets a request, processes a request, and returns a response in a completely stateless manner Every request, even from the same client a moment later, looks brand new to the server

Stateless servers are the easiest to operate If they fail, just start them up again No one cares where they left off You can even transfer processing to another host and everything runs just fi ne, as long as the resources are there Stateless servers are best for simple resource-retrieval systems

That’s how the Web started out, but unfortunately this is not how the Web is used today Web sites have shopping carts that remember content and billing systems that remember credit card information They also remember log-in information that would otherwise have to be entered every time an HTTP request was made

How should the state information necessary for the Web today be stored? For

bet-ter or worse, the answer today is in cookies The term seems to have originated in older programs that required users to supply a “magic cookie” to make the program do something out of the ordinary (“Easter eggs” seem to be the GUI equivalent) Accord-ing to others, an old computer virus put the image onscreen of Cookie Monster (of

Sesame Street fame) announcing, “Want cookie!” The user had to type the word cookie

to continue The cookie term is also used in BOOTP/DHCP.

Cookies were initially developed by Netscape and were formalized as a Web state management system in RFC 2965, which replaced RFC 2109 Cookies are not actually part of HTTP, and remain an option, but few Web browsers can afford to reject all cook-ies out of hand (so to speak)

The idea behind cookies as a method of server state management is simple If the server can’t hold state information about the user and the session, let the client do

it When the server has a function that needs a state to be maintained over time, the server sends a small amount of data to the client (a cookie)

Cookies are presented when the server asks for them, and are updated as the ses-sion progresses Cookies are just text strings and have no standard formats, in that only a particular server has to understand and parse them In Windows XP, cookies are stored in the cookies.txt fi le under the user’s Documents and Settings directory

Cookies just accumulate there until users clear them out (few do) If deleted, the fi le is built again from scratch Looking at someone’s cookies is a quick and dirty way to see where the browser (not necessarily the user) has gone recently

Cookies, as indispensable as they are on the Web today, tend to have a somewhat unsavory reputation They aren’t perfect: If a cookie is established to allow access to a book-shop Web site at home, the cookie is not present on the user’s offi ce computer and the Web site has no idea who the user is because there is no cookie to give to the

580 PART IV Application Level

server A lot of users assume they’ve done something wrong, but that’s just the way cookies work

Most browsers can be set to screen or reject cookies, mainly because cookies are a barely tolerated security risk to many people (many think the browser default should

be to reject all cookies instead of accepting them) In particular, there are three big

issues with cookies

Sending of sensitive information— Banks routinely store user ID and password

in a cookie Even if it is encrypted when sent, the information is typically sit-ting on your computer in plain text (waisit-ting for anyone to look at it)

User tracking abuse—Servers can set cookies for any reason, including tracking the sites a user visits rather than storing useful parameters This is often seen

as a violation of the right to privacy, and some Web browsers are silent when

a cookie is set

Third-party cookies—If a Web page contains a link (perhaps to a small image) to

another Web site, the second site can set a cookie (called a third-party cookie)

on your machine even though you’ve never visited (or intend to visit) the site

So, that must be how all those porn-site cookies got there

Some people regard cookies as much ado about nothing, whereas others busily turn off all cookie support whenever they go on-line But most people should at least con-sider disabling third-party cookies, which really have no legitimate use when it comes

to HTTP state management

CHAPTER 22 Hypertext Transfer Protocol 581

This page intentionally left blank

QUESTIONS FOR READERS

Figure 22.10 shows some of the concepts discussed in this chapter and can be used to answer the following questions

FIGURE 22.10

The Apache server capture.

1 Which version of Apache is the server using?

2 Which ports are the client and server using?

3 Completely parse the following URL: http://www.examplebooks.com:8888/ cgi-bin/ebook.php?HTTPforChimps#page345.

4 Completely parse the following URL:

ftp://ftp.freestuff.com/Is%20This%20Really%20Free%3F.

5 What is a cookie used for? Examine your cookies.txt fi le

583

What You Will Learn

In this chapter, you will learn about the secure sockets layer (SSL) and how it is used on Web sites We investigate the layers and operation of the SSL protocol and discuss the SSL’s use of certifi cates

You will learn about the public key infrastructure (PKI) and how public keys are used for encryption We present a simple example of public key encryption and decryption using only a pocket calculator and no advanced mathematics

Securing Sockets

Web site security and user authentication were not much of a concern in the HTTP chapter But the popularity of the Web for e-commerce is based on trusting that the transactions sent over the Internet are secure To most users, this means two things:

Server authentication—The identity of the server is vouched for in some way

(such as a certificate), so that users have confidence that the Web site is not

run by a bunch of hackers collecting credit card or password information

Safe passage—Data that passes back and forth between client and server cannot

be read (decrypted) by hackers sniffing odd interfaces here and there

In this chapter, we explore the SSL, the most widely deployed security protocol on the Web (and in the world) today Many users notice the little yellow lock that appears

in the lower right-hand corner of most Web browsers, and a large percentage of those realize that this means the browser has deemed this site “secure,” but few bother to investigate just what that means

SSL AND WEB SITES

In the last chapter, we confi gured the hosts bsdserver and winsvr1 to act as a Web site using Apache In this chapter, we’ll explore the security aspects of the Web software We’ll be using the same equipment as in the previous chapter, as shown in Figure 23.1

lo0: 192.168.0.1

fe-1/3/0: 10.10.11.1 MAC: 00:05:85:88:cc:db (Juniper_88:cc:db) IPv6: fe80:205:85ff:fe88:ccdb

P9

lo0: 192.168.9.1

PE5

lo0: 192.168.5.1

P4

lo0: 192.168.4.1

so-0/0/1 79.2

so-0/0/1 24.2

so-0/0/0 47.1

so-0/0/2 29.2 so-0/0/3

49.2

so-0/0/3 49.1

so-0/0/059.2

so-0/0/2 45.1

so-0/0 /2 45.2 so-0/0/059.1

ge-0/0/3 50.2

ge-0/0/350.1

DSL Link

Ethernet LAN Switch with Twisted-Pair Wiring

em0: 10.10.11.177

MAC: 00:0e:0c:3b:8f:94

(Intel_3b:8f:94)

IPv6: fe80::20e:

cff:fe3b:8f94

eth0: 10.10.11.66 MAC: 00:d0:b7:1f:fe:e6 (Intel_1f:fe:e6) IPv6: fe80::2d0:

b7ff:fe1f:fee6

LAN2: 10.10.11.51 MAC: 00:0e:0c:3b:88:3c (Intel_3b:88:3c) IPv6: fe80::20e:

cff:fe3b:883c

winsvr1

LAN1

Los Angeles

Office

Ace ISP

AS 65459

Wireless

in Home

IIS with ASP Installed

Solid rules ⫽ SONET/SDH

Dashed rules ⫽ Gig Ethernet

Note: All links use 10.0.x.y

addressing only the last

two octets are shown.

FIGURE 23.1

Web sites on the Illustrated Network showing that the Apache Web server supports SSL.

586 PART IV Application Level

lo0: 192.168.6.1

fe-1/3/0: 10.10.12.1 MAC: 0:05:85:8b:bc:db (Juniper_8b:bc:db) IPv6: fe80:205:85ff:fe8b:bcdb Ethernet LAN Switch with Twisted-Pair Wiring

eth0: 10.10.12.166 MAC: 00:b0:d0:45:34:64 (Dell_45:34:64) IPv6: fe80::2b0:

d0ff:fe45:3464

LAN2: 10.10.12.52 MAC: 00:0e:0c:3b:88:56 (Intel_3b:88:56) IPv6: fe80::20e:

cff:fe3b:8856

LAN2: 10.10.12.222 MAC: 00:02:b3:27:fa:8c IPv6: fe80::202: b3ff:fe27:fa8c

LAN2

New York

Office

P7

lo0: 192.168.7.1

PE1

lo0: 192.168.1.1

P2

lo0: 192.168.2.1

so-0/0/1

79.1

so-0/0/1

24.1

so-0/0/0

47.2

so-0/0/2

29.1

so-0/0/3 27.2

so-0/0/3 27.1

so-0/0/2 17.2

so-0/0/2 17.1

so-0/0/0 12.2

so-0/0/0 12.1

ge-0/0/3 16.2

ge-0/0/3 16.

1

Best ISP

AS 65127

Global Public Internet

Apache Web

with SSL

Installed

CHAPTER 23 Securing Sockets with SSL 587

The Apache Web server software uses a type of SSL called OpenSSL What happens when we use the Apache Web server with the OpenSSL module on bsdserver? Let’s try it from wincli2 and see what happens In the HTTP chapter, when we accessed the default Apache Web page (index.html) at http://bsdserver.booklab.englab.jnpr.net, the

page mentioned SSL but did not display a security lock

When we type in a request for the secure part of the bsdserver by using https,

as in https://bsdserver.booklab.englab.jnpr.net, we get a default security alert right away from IE (as shown in Figure 23.2) It seems odd to warn about a secure connection, but that’s what it does

FIGURE 23.2

A security alert in IE, oddly “alerting” the user that the information cannot be viewed by others

Note that these warnings can be disabled.

FIGURE 23.3

A certifi cate security warning Often the certifi cate has expired and has not yet been renewed.

588 PART IV Application Level