Tải bản đầy đủ
5 Client–Server Model and Cookies

5 Client–Server Model and Cookies

Tải bản đầy đủ

260

7. Electronic Mail and Internet Security

request on its own power to find the requested data rather than transferring all
the information back to the client to find its own data.
Client-Server and HTTP: On page 225, we were introduced to HTTP
and shown its application in protocol layers studied in Section 7.3. Here is how
HTTP fits into the client-server model. When Alice opens her WWW browser (a
client software program used for locating and viewing different types of Internet
resources such as data on a WWW site), she indirectly makes use of HTTP.
Each WWW server contains an HTTP daemon denoted by HTTPD, which is
a continuously running program (by itself under the operating system) whose
sole purpose is to (wait for and) handle requests that a given computer system
receives periodically. The etymology of daemon is from the Greek meaning
an attendant supernatural being, on a hierarchy between gods and humans
(pronounced dee-muhn).
Now we need to look at another Internet notion. A URL is the acronym
for Uniform Resource Locator, which is the global address associated with given
data. The first part of the URL specifies which protocol to use, and the second
part indicates the domain name. For example, http://www.math.ucalgary.ca/˜
ramollin/ indicates that this is a WWW page and the HTTP protocol should
be used. The second part is the domain name where my homepage is located.
Alice’s browser is an HTTP client that makes requests to a server by, say,
opening a WWW file via the typing in of a Uniform Resource Locator (URL).
By so doing, her browser formulates an HTTP request and sends it to the IP
address indicated by the URL. The HTTP daemon at the server site receives the
request and sends back a response in the form of requested files. Unfortunately,
HTTP is what is known as a stateless protocol, which means that each time
Alice visits a WWW site (or even when she just clicks to another location from
that site), the server sees this as her first visit. In other words, the server forgets
all that has transpired after each request unless there is a means to somehow
“stamp” Alice so that the server will remember the details of her last visit. The
following is a mechanism for accomplishing this task.
◆ Cookies
The origin of the term “cookie” is uncertain, although its inventor, Netscape,
claims it was a name chosen at random. Some claim that it was derived from a
similar Unix operating system transaction called a “token.” On MAC computers,
the cookies are kept in a list called “magic cookie,” whereas on IBM CPUs they
are in a file called “cookies.txt.”
What is a cookie and how does it fit into the client-server model? In simplest
terms, a cookie is data (for future use) that are stored by a server on the
client side of a client-server model. For instance, a cookie might record Alice’s
preferences when visiting, QQQ.com. The cookie is a means by which the server
can store its own data about Alice on Alice’s own computer.
Analogy: An analogy is a voucher Alice gets when she brings her shoes
to a cobbler, Corbett, for example. If she returns for her shoes without that
voucher, Corbett will not be able to locate her shoes. To him, she could be

© 2007 by Taylor & Francis Group, LLC

7.5. Client–Server Model and Cookies

261

a new customer. Alice’s voucher is necessary for Corbett to maintain record
keeping, and it establishes a formal relationship (which we will call a state)
between him and Alice.
Cookies and HTTP: In Internet terms, a server, when returning an HTTP
object to Alice, includes a cookie that has a description of the range of URLs for
which that cookie is valid. Any future HTTP requests made by Alice that fall
in that range will include the current value of the cookie from Alice sent back
to the server. This means that she can shop online and store information about
the currently selected items, and it frees Alice from retyping her user ID for each
visit. The sites at which she shops can store preferences on her computer and
have Alice supply those preferences every time she visits that site. For instance,
the QQQ.com server provides the cookie to Alice’s browser, which stores it in
its memory as a text file. Each time her browser sends a request to QQQ.com
(when she types in its URL for example), the cookie is sent back to the server.
Types of Cookies: There are different types of cookies. For instance,
a session cookie (or transient cookie) is one that is erased when Alice closes
her browser, because the session cookie is stored in temporary memory and
discarded after the browser is closed. These transient cookies do not obtain
information from Alice’s computer. Rather, they store data in a session ID
format, which does not explicitly identify Alice. Another type of cookie is the
persistent cookie (also called permanent or stored cookie), which is a cookie set
with an expiration date and is stored on Alice’s hard drive until it expires (or
else Alice, herself, deletes it). (A hard disk, also called a disk drive, is part of a
unit that stores [and provides efficient access to] large blocks of data on one or
more electromagnetically charged surfaces.) Persistent cookies gather information about Alice, including her WWW surfing behaviour or her preferences at
QQQ.com. The QQQ.com server may use this information to present Alice with
a customized welcome page with, say, “Hello Alice” the next time she visits.
Alice’s browser automatically updates her cookies every time she revisits a
site, since once the browser is closed, the cookies are resaved to disk.
Effect of Cookies: In the final analysis, a cookie is simply a piece of text,
not a program, and only Alice’s browser can store cookies on her hard drive, if
it is a persistent cookie. The data are stored in a special file called a cookie list
and is done without the knowledge or consent of Alice. However, it cannot be
used for, say, a virus, so it is harmless in that regard. Moreover, the number of
cookies allowed for storage on Alice’s hard drive is also restricted. Most browsers
conform to RFC 2109 (see [76] and page 240), which puts a limitation of 300
cookies that may be stored on a given hard drive (with a 4096 byte-per-cookie
maximum). This involves a limit of twenty cookies per WWW site, so if fifteen
sites maximize the cookies on Alice’s hard drive, then the next time a cookie is
to be set, Alice’s browser will discard her least-used cookie to free space for the
new cookie.
When Alice returns to QQQ.com, her browser will automatically and, again
without her knowledge or consent, transmit the cookie containing her personal
data to QQQ.com’s server.

© 2007 by Taylor & Francis Group, LLC

262

7. Electronic Mail and Internet Security

Cookie Ingredients: Cookies transport between server and client as an
HTTP header, and the formal specifics of this header as defined in RFC 2109.
There are six parameters that can be assigned to a cookie. The first two are
mandatory and are set by pairing them together. The others (set optionally),
configured manually or automatically, typically are separated by semicolons.
1. Name: This is any alphanumeric value (excluding semicolons, commas,
and white space) used to identify the cookie.
2. Value: This cookie value may be any scalar.
3. Expiration Date: This determines the valid lifetime of the cookie and,
if not explicitly set, defaults to the end of the session as long as Alice’s
browser is open.
4. Path: This sets the subset of URL paths on a domain for which the cookie
is valid. If a path is not specified, the default is the path of the document
that created the cookie.
5. Domain: This is the textual equivalent of a numerical IP address. When
searching a cookie list, a comparison is made between the tail of the valid
host domain name (such as QQQ.com) and the tail of the cookies on the
list. For instance, it might be shopping.QQQ.com, which indeed satisfies
the tail matching for the domain QQQ.com. Because of this tailmatching,
no domain is allowed to set a cookie with fewer than two dots, in order
to distinguish among tails such as those containing .com, .ca, .gov, and
so on. Thus, for instance, QQQ.com would not be an allowed cookie on
the list. Moreover, the server setting the cookie must be a member of
that domain. For instance, WWW.QQQ.com cannot set a cookie for the
domain WWW.RRR.com, since the security breaches would be severe.
6. Secure Label: If this label is set to TRUE, then the cookie may be sent
only over a secure channel, typically HTTPS (see page 243). The default
is FALSE, since most WWW sites do not need secure connections.
Basically cookies are pieces of textual data generated by a WWW server
for storage on a client’s computer for future access. Cookies are embedded in
HTML information that flows between the client browser and the server. Most
often both the storage of, and access to, cookies goes unnoticed by the client.
However, any client, concerned about privacy issues can set his or her computer
to notify of any attempt to set a cookie and will ask permission. Of course,
this may become a headache since there will be a lot of “alerts.” The crucial
issue is for the client to be “aware” of the issues, which this section addresses.
Cookies cannot damage your computer or give out private data on you without
your giving it out at a WWW site in the first place. The bottom line is that
cookies were meant as a mechanism to make it easier for you to access your
favourite WWW sites by storing information, so you do not have to login each
time you visit, a process that was impossible before the advent of cookies due
to the stateless nature of HTTP.

© 2007 by Taylor & Francis Group, LLC

Chapter 8

Leading-Edge Applications
8.1

Login and Network Security

This chapter is adapted from [64] to suit this text. The following describes
mechanisms for securely logging in to a computer.
▼ Login Security
To login (also called signing in) to a computer, we must provide a passphrase,
which may be as simple as a single word, called a password, or a sequence
of words used to identify us uniquely for secure access to the system. The
encrypted passphrase will be accompanied by our plaintext username ID. A
user ID, authenticated by its associated passphrase, determines the privileges
allotted to the user, which may vary from personal e-mail access to superuser
status, where actions may be executed that are protected by the operating
system.
If we are trying to login from home, or a hotel when on a trip, to gain
access to a computer at work, for instance, this is called remote login. In this
case, passwords may travel over unsecured channels, making them susceptible to
eavesdropping by Eve or interception by Mallory. Mechanisms exist for dealing
with these situations. E-mail security via PGP and S/MIME were described
in Chapter 7.2. Secure session-based communication via SSL was explored in
Section 7.3. Now we delve further into password protection.
On page 168, we described the use of one-way functions in the role of password security. Also, we have already been introduced to the concept of a
“salted” message (see Footnote 2.2 on page 125).
▼ Why Use Salt?
The purposes behind salting a passphrase are threefold.
1. Eliminating the visibility of duplicate passphrases on a user’s file.
2. Increasing the bitlength of the passphrase to thwart password guessing.
263
© 2007 by Taylor & Francis Group, LLC

264

8. Leading-Edge Applications

3. Helping thwart attacks such as the dictionary attack (see see page 128).
▼ Proactive Password Selection
Since the average person is notoriously lazy about choosing proper passwords, instead selecting easy-to-remember words and neglecting security, there
needs to be a mechanism for ensuring that user-chosen passwords are acceptable. This is where a proactive password checker comes into play. This built-in
checker will determine if a user-selected password is acceptable and reject it if
not, prompting the user to try again. System enforcement may contain some of
the following criteria.
Passphrase Selection Criteria
Parts 1–4 below refer to the criteria for a proactive checker itself, whereas
the remainder are more for a given user to consider when choosing a passphrase.
1. All passphrases must have at least ten symbols.
2. There must be at least three of: lower case letters; upper case letters;
numeric; and characters such as !,#,),&,*,❅, and so on.
3. No symbols should be repeated.
4. No actual words should be used.
5. No personal data such as birthdays or telephone numbers should be used.
6. Memorize the passphrase. Never write it down and do not store it on your
computer as a file.
If properly implemented, the above criteria ensure that a brute-force attack
is made less likely to succeed. There exist methods for creating effective and
efficient passphrase checkers that do not require lots of space and time as would,
say, a list of stored “unacceptable” phrases.
Attacks on Passwords
The following list encompasses some current password attacks.
1. Password sniffing: This is an attack in which Eve listens to data traffic
that includes secret passwords in order to capture and use them at a later
time.
2. The birthday attack : This attack is described on page 128.
3. Spoofing: This type of attack is described on page 252.
4. The dictionary attack : This attack is described on page 128.
5. Password-cracking software is available over the Internet.

© 2007 by Taylor & Francis Group, LLC

8.1. Login and Network Security

265

6. Social engineering attacks: This refers to a group of attacks that exploit human weakness or gullibility. These techniques consist of employing nondigital mechanisms to gain digital data from the victim. One of the most
common is for the criminal to masquerade as a bank official to get the
victim’s PIN usually based on a claim that it is required to fix something
with the account. These attacks, therefore, require that the victim’s trust
is obtained so that the victim will disclose information to the criminal.
7. Packet sniffers: These are programs that monitor, capture, or analyze network traffic, or databases. For instance, a database might be scrutinized
by Mallory to detect passwords. If he is successful at gaining access to a
system-level password, Mallory can create a new account that can be used
at will as a back door to get into the network and its resources, including the altering of core system files, such as the password for the system
administrator account, the list of server services and permissions, and the
login information for other machines, containing critically confidential information. This could create chaos since the daily workings of the network
are up for grabs, and Mallory’s network packet sniffer can be modified to
include his information or change system information in a network packet,
forcing network connections to behave erratically, at best.

Item 7 above also has legitimate uses as follows. A snoop server is a server
that uses a packet sniffer to capture network traffic for analysis. For example, an
employer might want to use a snoop server to monitor the WWW sites visited
by the employees. Snoop servers typically operate in promiscuous mode, which
is a networking mode allowing a network device (a unit of removable hardware)
to access all packets, irrespective of their target addresses. In this manner, a
snoop server, for instance, can seize any data packet, copy, and store it to a
file for later analysis and reporting. For example, the Sun operating system,
Solaris, has a feature called the snoop command, permitting administrators to
capture packets with an attendant packet description or summary. However,
this also permits intruders (running the Solaris OS) to scrutinize the traffic over
the network.
In general, a promiscuous mode is used for legitimate monitoring of network activity. This might involve the performance of diagnostic testing to try
to resolve such problems as bottlenecks in the flow of traffic or general troubleshooting to identify a variety of performance problems. Modern sniffers can
be configured to automatically alert administrators when a performance problem is triggered by some preset standard that they set as a local bound.
For the following discussion, we should expand our understanding of the
notion of a hard drive, the basic definition of which was given on page 261. We
extend it here to get a better idea of how it functions. A hard disk is essentially
a collection of stacked disks, each storing data electromagnetically recorded in
concentric circles called tracks. Two heads, one located on each side of a disk,
read or write the information on these tracks as the disk spins. The spin speed is

© 2007 by Taylor & Francis Group, LLC

266

8. Leading-Edge Applications

anywhere from 4500 to 7200 rpms. Think of the comparison with a phonograph
record and its player having a phonograph arm (“head”) to “read” the music.
Now we look at packet sniffers more closely.
A packet sniffer can be configured to store copies of packets in memory or
hard drive, which might be done via temporary storage in a buffer for later
analysis. Employers might want to monitor any number of employee activities
such as who visits the employee’s site; what an employee downloads, including
streaming audio and video; contents of incoming and outgoing e-mail messages;
which sites the employee visits; and the contents of what the employee views at
a given site. The amount of traffic scanned by a given packet sniffer will depend
upon the location of the computer in the network. If it is located in a relatively
secluded area of the network, then the sniffer will be able to scan only a tiny
portion of traffic over the network, but if it is the principal domain server, for
instance, the packet sniffer will be able to scan virtually all of the traffic.
The above being said, Mallory still likes packet sniffers, since if successful,
he can use them to seize passwords from data packets traversing the network
and wreak havoc as described above. One method of thwarting Mallory is to
encipher the headers of packets using SSL in browser-based traffic (see Section
7.3).
Before going into a deeper discussion of ethernet and promiscuous mode, we
look at the organization that developed the standards.
IEEE
IEEE, pronounced I-Triple E, is the Institute of Electrical and Electronics
Engineers Incorporated. The AIEE, American Institute of Electrical Engineers,
which was founded in 1884, merged with the IRE, Institute of Radio Engineers, in 1963 to form IEEE. The primary function of IEEE, for our interest, is
the development of standards for communications security, the most famous of
which are the IEEE 802 standards for (LAN)s Local Area Networks and WANs,
Wide Area Networks. A LAN is a collection of computers and their attendant
mechanisms sharing a common communications channel or wireless linkage and
(usually) a shared server. The common server has applications and data storage,
which may be accessed by the LAN users who may vary in number from a couple
to several thousand. A WAN differs from a LAN in that it is a geographically
more dispersed network, which usually includes shared user networks. In size
between a LAN and a WAN is a MAN or Metropolitan Area Network, typically
meaning the interconnection of networks in a city into a single large network. A
MAN, of course, provides a more efficient connection to a WAN. For more information on IEEE and its standards, visit http://www.ieee.org/portal/index.jsp.
Ethernet and Promiscuous Mode
Ethernet (as specified in IEEE 802.3) is the most commonly employed Local Area Network (LAN). Ethernet evolved from a framework called Alohanet,
named for the Palo Alto Research Center Aloha Network, which was developed
into Ethernet by XEROX then further expanded later by DEC, Intel, and XEROX. There exist Ethernet configurations that provide transmission speeds up

© 2007 by Taylor & Francis Group, LLC

8.1. Login and Network Security

267

to 10 billion bits per second, called Ten-Gigabit Ethernet, which is specified in
IEEE 802.3a. The future of all interconnections of LANs, WANs, and MANs is
generally predicted to be via the Ten-Gigabit Ethernet.
Now that we know the basics of Ethernet, we describe the use of packet
sniffers in this context. Ethernet was designed to filter out all data traffic not
belonging to it. When a packet sniffer is installed in Ethernet hardware, that
filter is turned off and the hardware goes into promiscuous mode. Thus, if Alice
and Bob are communicating over an Ethernet channel with a packet sniffer
attached, Mallory can read all the traffic between them. Packet sniffers on an
Ethernet consist of the following parts.
Packet Sniffer Components
1. Hardware: In promiscuous mode, every packet is received and read by a
network adapter (sometimes called a network interface) which is a physical
device such as a card (and its software driver); which connects a host
computer to network traffic, allowing the host to send and receive packets.
2. Capture Driver: This type of driver captures the network traffic and
stores it to a buffer, for instance. A driver, in general, is a program that
controls a particular device, such as a printer or disk drive. Either the
driver will come with the operating system or will have to be loaded when
the device is added. Think of a driver as a translator between the device
and the programs using the device.
A device driver is a program that controls a specific device such as a
printer. Thus, we may (informally) think of a capture driver as a program
that controls the capture of information packets for the packet sniffer.
3. Buffer: The captured data from the network are stored in a buffer until
they can be analyzed.
4. Protocol Analyser: This aspect of the packet sniffer strips off any encoding and analyzes the data (see Appendix G).
The antithesis of promiscuous mode is nonpromiscuous mode wherein packets are scanned and passed on if those data packets are not theirs. Only the
target site device receives and reads the data in this mode.
Now we return to the issue of login security. We have addressed the issue
of password selection and checking, remote logins, and attacks that may obtain
passwords. We turn to a modern secure method for password storage.
◆ Security Tokens
A security token is a special device (a physical object usually ranging in
size from that of a housekey to that of a credit card) that a user carries for
the purpose of authorized access to a network. For example, the device may
be embedded in a key fob, which has the physical appearance of a key but has
built-in authentication mechanisms consisting of the following:

© 2007 by Taylor & Francis Group, LLC

268

8. Leading-Edge Applications

1. The user’s PIN, authenticating, say Alice, as the fob’s owner.
2. A login ID, which is displayed after Alice correctly enters her PIN, allowing
her to login to the network.
Token Applications
1. A token may be embedded in a smart card, which has the physical appearance of a credit card but has the above authorization mechanisms
embedded. (We will study smart cards in detail in Section 8.3.) The login
ID is not static and may actually change every few minutes for security
reasons, so if a security token is lost, and Mallory finds it, he cannot access the network without Alice’s PIN. Furthermore, an additional security
measure against the possibility that Mallory might launch a brute-force
attack to recover Alice’s PIN is that the device would be disabled after
a small number of attempts to enter the PIN, say, three or four. Hence,
security tokens provide one of the foremost, modern, practical methods
for the storing of secret keys.
2. Since employees of, say, a corporation need to insert their security token
into their computers for network access, the corporate administrators must
guard against human laziness. For instance, a user, such as Alice, might
decide to leave her office to get a coffee and not remove the token from her
computer, which is a security risk. To guard against this, the employers
may require that the token is needed for access to her office, the coffee
machine, the filing cabinets, the department office, the rest room, and so
on. In this fashion, the token cannot be left unattended in any reasonable
scenario. This makes such a system foolproof but not idiot-proof. (An
adage is that genius knows its limitations, but stupidity is unbounded.)
We will learn about other security options such as biometrics in Section 8.4.
For now, we turn to a remote login protocol that is considered to be the industry
standard.
◆ The Secure Shell Remote Login Protocol (SSH)
We describe the latest version, SSH2, which corrects failings of the original,
including susceptibility to certain attacks. Although the protocols in SSH2
described below may have many differing formats, we do not delve into that
detail. Instead, suitable references will be provided for the interested reader.
We concentrate upon the description of the main protocols and focus upon
SSH2 as a development that is on an approach to becoming the new standard
for remote login.
Before going into further explanation, we need to discuss the system upon
which SSH is based. Unix (pronounced you-niks) originated in 1969 at AT&T
Bell Labs to provide an interactive time-sharing system. In 1974, Unix attained

© 2007 by Taylor & Francis Group, LLC

8.1. Login and Network Security

269

the status of the first operating system to be written in the C programming
language. Being a nonproprietary operating system, it evolved as freeware and
eventually became the first standard operating system that could be openly
developed by virtually anybody. We may rightfully view both the client-server
model and Unix as vital developments in the evolution of the Internet, with a
focus toward computing networks and away from independent computers.
What is SSH?
Secure Shell or SSH (sometimes called Secure Socket Shell — not be be
confused with SSL — see Section 7.3) is essentially a Unix-based command
interface using PKC-oriented, secure remote login protocols. It allows a user to
execute commands on a remote computer, as well as securely move files from one
host to another. It provides strong authentication and secure communication
over an insecure channel. SSH was designed to replace insecure applications
such as Telnet and FTP (see page 224).
Basically, How Does SSH work?
The SSH mode of operation is quite simple on the surface. The host computer first authenticates itself to the client, establishing a unilateral server-toclient secure channel. Then a user, Alice, say, on a client computer employing
unilateral public-key and/or password-based protocols authenticates herself to
the server. Once the link is secure, not only can files between hosts be transported, but also other TCP/IP connections may be forwarded over that secure
link. All algorithms used to ensure security are negotiated, so if some algorithm
is cryptanalyzed, it is a simple matter to eliminate it and switch to another in
the cipher suite.
The following is a detailed description of SSH2, starting with an overview of
SSH in general.
◆ SSH Protocol Architecture
We will assume that Alice is the user on the client computer and she wishes
to establish secure communications with the (remote) host computer.
▼ Overview of SSH Protocols
1. Transport Layer Protocol: This protocol provides strong host authentication, confidentiality via strong encryption, and integrity protection from
the server to the client computer. This layer also thwarts the man-in-themiddle attack. Moreover, it optionally supports compression. Although
there are other possible data streams over which this transport layer may
run, we assume that it does so over the canonical one, TCP/IP. The other
layers of the SSH protocol run on top of the secure tunnel provided by the
transport layer — see pages 241–242.
2. User Authentication Protocol: This protocol runs over the transport
layer protocol for the purpose of authenticating Alice to the server. The

© 2007 by Taylor & Francis Group, LLC

270

8. Leading-Edge Applications
DSA cipher is used for authentication (see page 187). Once this protocol
is completed, there is a mutually authenticated secure channel between
Alice and the host.

3. Connection Protocol: This protocol runs over the encrypted tunnel
estabilised above. It multiplexes (where multiplexing means the use of a
transmission channel to carry two or more signals at the same time) that
tunnel into numerous logical channels that may be used for a rich variety of
application-support services, including remote program execution, signal
propagation, and connection forwarding.
▼ SSH Protocols in Detail
SSH Transport Layer: The purpose of this layer is to ensure secure communication between Alice, as the client user, and the remote server, as the host.
Once Alice contacts the server, key data must be exchanged in order to construct the tunnel. With SSH2, it is mandated that DSS be used (see page 187).
The host sends its public key, called the host key eS , as identification. In order
for Alice to be certain that she is communicating with the correct server, she
must have prior knowledge of eS , for which two trust models are available.
Key Exchange Protocol
It is mandated in [95]–[96] that the Diffie-Hellman key-exchange protocol
(see page 167) be used to arrive at key agreement as follows.
We assume that p is a large safe prime; α is a primitive root modulo p; h
is a hash cryptographic hash function; and that identification data have been
exchanged in advance such as both Alice’s and the server’s ID, IA and IS , as
well as Alice’s and the server’s protocol versions VA and VS , respectively.
1. Alice generates a random number r with 1 < r < p − 1, then she calculates
cA ≡ αr (mod p), which she sends to the server.
2. The server generates a random number s with 1 < s < p − 1 and computes
each of the following:
(a) cS ≡ αs (mod p).
(b) K ≡ csA (mod p).
(c) HS = h(VA , VS , IA , IS , eS , cA , cS , K).
(d) DS (HS ), the server’s digital signature.
Then the server sends DS (HS ) to Alice.
3. Alice certifies eS as described in the above discussion preceding the key
exchange protocol. Once done, she computes
K ≡ crS (mod p)
and
HS = h(VA , VS , IA , IS , eS , cA , cS , K).

© 2007 by Taylor & Francis Group, LLC