SSL and TLS: Designing and Building Secure Systems / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $8.98
Usually ships in 1-2 business days
(Save 83%)
Other sellers (Paperback)
  • All (11) from $8.98   
  • New (5) from $42.98   
  • Used (6) from $8.96   

Overview

"This is the best book on SSL/TLS. Rescorla knows SSL/TLS as well as anyone and presents it both clearly and completely.... At times, I felt like he's been looking over my shoulder when I designed SSL v3. If network security matters to you, buy this book."
Paul Kocher, Cryptography Research, Inc.
Co-Designer of SSL v3

"Having the right crypto is necessary but not sufficient to having secure communications. If you're using SSL/TLS, you should have SSL and TLS sitting on your shelf right next to Applied Cryptography."
Bruce Schneier, Counterpane Internet Security, Inc.
Author of Applied Cryptography

"Everything you wanted to know about SSL/TLS in one place. It covers the protocols down to the level of packet traces. It covers how to write software that uses SSL/TLS. And it contrasts SSL with other approaches. All this while being technically sound and readable!"
Radia Perlman, Sun Microsystems, Inc.
Author of Interconnections

Secure Sockets Layer (SSL) and its IETF successor, Transport Layer Security (TLS), are the leading Internet security protocols, providing security for e-commerce, web services, and many other network functions. Using SSL/TLS effectively requires a firm grasp of its role in network communications, its security properties, and its performance characteristics. SSL and TLS provides total coverage of the protocols from the bits on the wire up to application programming.

This comprehensive book not only describes how SSL/TLS is supposed to behave but also uses the author's free ssldump diagnostic tool to show the protocols in action. The author covers each protocol feature, first explaining how it works and then illustrating it in a live implementation. This unique presentation bridges the difficult gap between specification and implementation that is a common source of confusion and incompatibility.

In addition to describing the protocols, SSL and TLS delivers the essential details required by security architects, application designers, and software engineers. Use the practical design rules in this book to quickly design fast and secure systems using SSL/TLS. These design rules are illustrated with chapters covering the new IETF standards for HTTP and SMTP over TLS.

Written by an experienced SSL implementor, SSL and TLS contains detailed information on programming SSL applications. The author discusses the common problems faced by implementors and provides complete sample programs illustrating the solutions in both C and Java. The sample programs use the free OpenSSL and PureTLS toolkits so the reader can immediately run the examples.

0201615983B04062001

Read More Show Less

Editorial Reviews

From Barnes & Noble
"This is the best book on SSL/TLS. Rescorla knows SSL/TLS as well as anyone and presents it both clearly and completely.... At times, I felt like he's been looking over my shoulder when I designed SSL v3. If network security matters to you, buy this book."
Paul Kocher, Cryptography Research, Inc.

Co-Designer of SSL v3
"Having the right crypto is necessary but not sufficient to having secure communications. If you're using SSL/TLS, you should have SSL and TLS sitting on your shelf right next to Applied Cryptography."
Bruce Schneier, Counterpane Internet Security, Inc. Author of Applied Cryptography

"Everything you wanted to know about SSL/TLS in one place. It covers the protocols down to the level of packet traces. It covers how to write software that uses SSL/TLS. And it contrasts SSL with other approaches. All this while being technically sound and readable!"
Radia Perlman, Sun Microsystems, Inc. Author of Interconnections

Danny Yee
Covering, as it does, pretty much everything about the Secure Sockets Layer in some depth, Eric Rescorla's SSL and TLS: Designing and Building Secure Systems is not for those who only want to get a secure web site up and running quickly. However, the layout makes it easy to browse just those portions that interest you, and to skip unwanted detail, so it can profitably be used by those who are simply curious, as well as by protocol designers, application programmers, and SSL/TLS implementors. (It was nice that Rescorla recognized the "just curious" in the preface.) A basic understanding of TCP/IP is all that's absolutely necessary to get something from SSL and TLS, but following the details requires a solid understanding.

Rescorla begins with a rapid introduction to security and cryptography and a brief history of SSL protocols (TLS or Transport Layer Security is the IETF-endorsed version). Two chapters then describe SSL itself, the first covering server authentication using RSA (the original motivation for SSL and still by far its most common use) and the second covering other algorithms (Kerberos, FORTEZZA) and modes such as client authentication and session resumption.

The remaining chapters cover specialized topics. A chapter on security looks at protecting keys, random-number generation, certificate chain verification, and some of the known attacks on SSL, such as timing cryptanalysis and the "million message attack." A chapter on performance explains the basic problem (cryptography is expensive), then goes into the details of variations with algorithm and mode (and language, with C recommended over Java) and the use of hardware acceleration. There is also a chapter on designing with SSL and one on coding (and Appendix A has 40-odd pages of sample code).

Two chapters consider special issues with running HTTP over SSL (HTTPS) and SMTP over TLS. Issues with HTTP include reference integrity (ensuring the client is talking to server it thinks it's talking to), virtual hosts, proxies, and downgrade attacks. With SMTP, relaying introduces major complications. A final chapter looks at some alternative approaches, most importantly IPsec, Secure HTTP, and S/MIME. This material provides some interesting examples of interaction between complex protocols.
Electronic Review of Computer Books

Booknews
A specialist in Internet security, Rescorla explains secure sockets layer and its IETF successor, transport layer security, which are leading Internet security protocols. He discusses their role in network communications, their security properties, and their performance characteristics. He warns that they cannot be treated as a black box to plug systems into, but must be understood quite thoroughly to be used effectively. The bibliography is lightly annotated. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780201615982
  • Publisher: Addison-Wesley
  • Publication date: 10/17/2000
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 528
  • Sales rank: 1,291,129
  • Product dimensions: 7.20 (w) x 9.00 (h) x 1.10 (d)

Meet the Author

Eric Rescorla is an Internet security consultant and author of several commercial SSL implementations, including the freely available Java PureTLS toolkit. He is also the author of HTTP over TLS and Secure HTTP IETF RFCs.

0201615983AB04062001

Read More Show Less

Read an Excerpt

Chapter 1: Security Concepts

Introduction

This chapter is intended to provide a basic introduction to communications security and cryptography. Communications security is a complicated topic and many fine books have been written about it. Our intent here is not to provide an exhaustive discussion of the topic but rather to teach you enough to understand the concepts and terminology that will be used throughout the rest of the book. Readers who are already familiar with cryptography and communications security should feel free to skip this chapter entirely.

We start by explaining the sorts of threats we're concerned about and the various sorts of security services we can provide. Next we provide a broad overview of cryptographic algorithms and how to put them together to provide these security services. Finally, we discuss some details of the various algorithms which will be relevant when we discuss their use in SSL/TLS.

The Internet Threat Model

The first thing that we need to do is define our threat model. A threat model describes what resources we expect the attacker to have available and what attacks the attacker can be expected to mount. Nearly every security system is vulnerable to some threat or another. To see this, imagine that you keep your papers in a completely unbreakable safe. That's all well and good, but if someone has planted a video camera in your office they can see your confidential information whenever you take it out to use it, so the safe hasn't bought you that much.

Therefore, when we define a threat model, we're concerned not only with defining what attacks we are going to worry about but also those we're not going to worry about. Failure to take this important step typically leads to complete deadlock as designers try to figure out how to counter every possible threat. What's important is to figure out which threats are realistic and which ones we can hope to counter with the tools available to us.

Designers of Internet security protocols typically share a more or less common threat model. First, it's assumed that the actual end systems that the protocol is being executed on are secure. Protecting against attacks where one of the end systems is under the control of the attacker is extraordinarily difficult, if not impossible. This assumption comes with two caveats. First, compromise of any single end system shouldn't break security for everyone. There should be no single point of' failure. For instance, if an attacker breaks system A, then all communications between B and A may be compromised, but communications between B and C should be safe. If we must have a single point of failure it must be possible to harden it against attack. Second, attackers may control systems that attempt to pose as legitimate end systems. All we're assuming is that users can expect that their own machines haven't been compromised.

Other than that, we assume that the attacker has more or less complete control of the communications channel between any two machines. He can certainly inject packets into the network with arbitrary address information, both for the sender and the receiver, and can read any packet that is on the network and remove any packet packet he chooses. Any packet you receive must be assumed to potentially come from the attacker and any packet you send might be modified in transit. An attack that depends on the attacker writing data to the network is known as an active attack. An attack that merely involves reading data off the network is known as a passive attack.

An obvious corollary of the assumption that the attacker can modify traffic is that the attacker can shut down all communication between any pair of machines simply by removing all relevant packets. This is one form of denial-of-service attack. Another form would be to force you to use up enormous CPU resources responding to connections. Conventionally, protocol designers don't worry about denial-of-service attacks, not because these attacks aren't important but because they're extraordinarily difficult to prevent.

One of the most important functions of a threat model is to arrange that security doesn't become more expensive than it is worth. Security measures should be employed only up to the point where the cost to implement them doesn't exceed the expected risk. Failure to make this judgment correctly can easily lead to a situation where no risk is judged acceptable and thus no acceptable system can be designed.

Part of the risk calculation is the effort required by the attacker to mount a given attack, and cost generally increases with each attack prevented. No security system is resistant to every attack. The function of a security model is to allow designers to determine which attacks are worthwhile to prevent. However, accurately estimating how much security you need requires accurately estimating the attacker's capabilities. If an attack that was originally considered impractical is discovered to be simple, then there will be a window of vulnerability while people adjust their security models and implementations to compensate.

The Players

To make it easier to understand the various examples we'll be discussing in this chapter, we'll use the same names repeatedly for the various parties. By convention, the two communicating parties are referred to as Alice and Bob, after the names used in the original RSA paper [Rivest1979]. The attacker is known merely as "the attacker...

Read More Show Less

Table of Contents

Preface.

1. Security Concepts.

Introduction.

The Internet Threat Model.

The Players.

The Goals of Security.

Tools of the Trade.

Putting It All Together.

A Simple Secure Messaging System.

A Simple Secure Channel.

The Export Situation.

Real Cryptographic Algorithms.

Symmetric Encryption: Stream Ciphers.

Symmetric Encryption: Block Ciphers.

Digest Algorithms.

Key Establishment.

Digital Signature.

MACs.

Key Length.

Summary.

2. Introduction to SSL.

Introduction.

Standards and Standards Bodies.

SSL Over view.

SSL/TLS Design Goals.

SSL and the TCP/IP Suite.

SSL History.

SSL for the Web.

Everything over SSL.

Getting SSL.

Summary.

3. Basic SSL.

Introduction.

SSL Over view.

Handshake.

SSL Record Protocol.

Putting the Pieces Together.

A Real Connection.

Some More Connection Details.

SSL Specification Language.

Handshake Message Structure.

Handshake Messages.

Key Derivation.

Record Protocol.

Alerts and Closure.

Summary.

4. Advanced SSL.

Introduction.

Session Resumption.

Client Authentication.

Ephemeral RSA.

Rehandshake.

Server Gated Cryptography.

DSS and DH.

Elliptic Curve Cipher Suites.

Kerberos.

FORTEZZA.

The Story So Far.

Session Resumption Details.

Client Authentication Details.

Ephemeral RSA Details.

SGC Details.

DH/DSS Details.

FORTEZZA Details.

Error Alerts.

SSLv2 Backward Compatibility.

Summary.

5. SSL Security.

Introduction.

What SSL Provides.

Protect the master_secret.

Protect the Server's Private Key.

Use Good Randomness.

Check the Certificate Chain.

Algorithm Selection.

The Story So Far.

Compromise of the master_secret.

Protecting Secrets in Memory.

Securing the Server's Private Key.

Random Number Generation.

Certificate Chain Verification.

Partial Compromise.

Known Attacks.

Timing Cryptanalysis.

Million Message Attack.

Small-Subgroup Attack.

Downgrade to Export.

Summary.

6. SSL Performance.

Introduction.

SSL Is Slow.

Performance Principles.

Cryptography Is Expensive.

Session Resumption.

Handshake Algorithm and Key Choice.

Bulk Data Transfer.

Basic SSL Performance Rules.

The Story So Far.

Handshake Time Allocation.

Normal RSA Mode.

RSA with Client Authentication.

Ephemeral RSA.

DSS/DHE.

DSS/DHE with Client Authentication.

Performance Improvements with DH.

Record Processing.

Java.

SSL Servers under Load.

Hardware Acceleration.

Inline Hardware Accelerators.

Network Latency.

The Nagle Algorithm.

Handshake Buffering.

Advanced SSL Performance Rules.

Summary.

7. Designing with SSL.

Introduction.

Know What You Want to Secure.

Client Authentication Options.

Reference Integrity.

Inappropriate Tasks.

Protocol Selection.

Reducing Handshake Overhead.

Design Strategy.

The Story So Far.

Separate Ports.

Upward Negotiation.

Downgrade Attacks.

Reference Integrity.

Username/Password Authentication.

SSL Client Authentication.

Mutual Username/Password Authentication.

Rehandshake.

Secondary Channels.

Closure.

Summary.

8. Coding with SSL.

Introduction.

SSL Implementations.

Sample Programs.

Context Initialization.

Client Connect.

Server Accept.

Simple I/O Handling.

Multiplexed I/O Using Threads.

Multiplexed I/O with select().

Closure.

Session Resumption.

What's Missing?

Summary.

9. HTTP over SSL.

Introduction.

Securing the Web.

HTTP.

HTML.

URLs.

HTTP Connection Behavior.

Proxies.

Virtual Hosts.

Protocol Selection.

Client Authentication.

Reference Integrity.

HTTPS.

HTTPS Overview.

URLs and Reference Integrity.

Connection Closure.

Proxies.

Virtual Hosts.

Client Authentication.

Referrer.

Substitution Attacks.

Upgrade.

Programming Issues.

Proxy CONNECT.

Handling Multiple Clients.

Summary.

10. SMTP over TLS.

Introduction.

Internet Mail Security.

Internet Messaging Overview.

SMTP.

RFC 822 and MIME.

E-Mail Addresses.

Mail Relaying.

Virtual Hosts.

MX Records.

Client Mail Access.

Protocol Selection.

Client Authentication.

Reference Integrity.

Connection Semantics.

STARTTLS.

STARTTLS Overview.

Connection Closure.

Requiring TLS.

Virtual Hosts.

Security Indicators.

Authenticated Relaying.

Originator Authentication.

Reference Integrity Details.

Why Not CONNECT?

What's STARTTLS Good For?

Programming Issues.

Implementing STARTTLS.

Server Startup.

Summary.

11. Contrasting Approaches.

Introduction.

The End-to-End Argument.

The End-to-End Argument and SMTP.

Other Protocols.

IPsec.

Security Associations.

ISAKMP and IKE.

AH and ESP.

Putting It All Together: IPsec.

IPsec versus SSL.

Secure HTTP.

CMS.

Message Format.

Cryptographic Options.

Putting It All Together: S-HTTP.

S-HTTP versus HTTPS.

S/MIME.

Basic S/MIME Formatting.

Signing Only.

Algorithm Choice.

Putting It All Together: S/MIME.

Implementation Barriers.

S/MIME versus SMTP/TLS.

Choosing the Appropriate Solution.

Summary.

Appendix A: Example Code.

Chapter 8.

Examples.

Java Examples.

Chapter 9.

HTTPS Examples.

mod_ssl Session Caching.

Appendix B: SSLv2.

Introduction.

SSLv2 Overview.

Missing Features.

Security Problems.

PCT.

What about SSLv1?

Bibliography.

Index. 0201615983T04062001

Read More Show Less

Preface

The Secure Sockets Layer (SSL) is by far the most widely deployed security protocol in the world. Essentially every commercial Web browser and server supports secure Web transactions using SSL. When you buy online using "secure" Web pages an estimated 20 billion dollars' worth of such transactions will occur in 2000), you're almost certainly using SSL.

Although its most common use is for securing Web traffic, SSL is actually quite a general protocol suitable for securing a wide variety of kinds of traffic. File transfer (FTP), remote object access (RMI, CORBA IIOP), e-mail transmission (SMTP), remote terminal service (Telnet) and directory access (LDAP) are just some of the applications that have already been secured with SSL or its successor, Transport Layer Security (TLS).

The effort to secure all these protocols has taught us a number of significant lessons. First, doing a good job of using SSL/TLS to secure a protocol requires having a fairly deep knowledge of how it works. It is not possible to simply treat SSL/TLS as a black box that somehow magically provides security when used.

Second, although each application is slightly different, there seems to be a set of security problems that are common to every application you wish to secure. For instance, we usually need to figure out some way for the insecure and secure versions of an application protocol to coexist. Although there aren't cookie-cutter solutions to these problems, the security community is starting to develop a common set of techniques for solving these problems using SSL/TLS.

These techniques can often be applied to a new application protocol with minimal modification. In essence, we've developed a set of design patterns for securing protocols. Much of the work of securing a system is in recognizing which pattern most closely matches the system you're working with and then using the appropriate techniques.

The purpose of this book, then, is to address both of these needs. After reading this book, you should know most if not all of what you need to know in order to design secure systems using SSL/TLS. You'll know enough about SSL/TLS to understand what security features it can deliver and what it can't deliver. Further, you'll be familiar with the common design patterns for using SSL/TLS and be ready to apply them to new situations.

What This Book Provides

This book is intended for anyone who wants to understand and use SSL/TLS.
  • For designers, it provides information on designing systems that use SSL/TLS as well as a library of the techniques that have already been used.
  • For programmers who program with SSL/TLS, it provides information on what your libraries are doing under the covers and what those functions you're calling are really doing. Understanding these details is critical for obtaining acceptable and predictable application performance.
  • For SSL/TLS implementors it acts as an adjunct to the standard, explaining obscure sections and describing both common practice and why things are the way they are.

Intended Audience

This book assumes a basic familiarity with how the TCP/IP protocols work. Readers who are unfamiliar with TCP/IP would be best served to consult one of the many fine books describing TCP/IP. TCP/IP Illustrated, Volume 1 Stevens1994a is a good choice. Postel1991a, Postel1991b, and Postel1991c provide the definitive reference for TCP/IP. Although some of this book will be understandable without a deep understanding of TCP/IP, much of the discussion of performance will be difficult to follow without an understanding of TCP behavior.

Because SSL/TLS is a cryptographic protocol, properly understanding it requires at least basic familiarity with cryptographic algorithms, including public key cryptography, symmetric cryptography, and digest algorithms. Chapter 1 provides an introduction to cryptography and communications, but space is too limited to do a complete job. We attempt to cover the requisite cryptographic details for understanding SSL/TLS; however, readers interested in a broader understanding of the cryptographic issues should consult a cryptography text such as Schneier1996a or Kaufman1995a

Organization of the Book

This book is written in two halves, matching the two primary goals described previously: understanding the protocol and understanding how to use it. The first half, Chapters 1-6, is devoted to describing SSL and TLS. We concern ourselves with the technical details of how they work and their security and performance properties in isolation.

The second half of the book, Chapters 7-11, covers the design of application protocols and systems that use SSL/TLS for security. First we describe general guidelines for using SSL/TLS and then we discuss several protocols that have already been secured using SSL/TLS.

Chapter 1 - Security Concepts provides an introduction to cryptography and communications security, with an eye towards its use in SSL/TLS. If you're already familiar with communications security, you may want to skip this chapter. If, on the other hand, you're not familiar with security, you'll want to read this chapter carefully so you don't get lost later.

Chapter 2 - Introduction to SSL is a broad overview of the history of SSL/TLS and what sorts of security features it provides. We also provide a snapshot of the status of SSL/TLS-secured protocols as of the time of this writing.

Chapter 3 - Basic SSL covers the most common SSL/TLS operational mode. We describe an entire SSL/TLS connection from start to finish. This chapter should give you a very good idea of how SSL/TLS works in practice. All the other operational modes can be easily understood once you understand this chapter.

Chapter 4 - Advanced SSL covers the rest of the major operational modes. We cover session resumption, client authentication, and a number of algorithms that are only now seeing deployment with SSL/TLS, such as DH/DSS and Kerberos.

Chapter 5 - SSL Security describes the security benefits that SSL offers as well as (even more important) those it doesn't offer. Whereas previous chapters mostly focused on describing how things work, this chapter focuses on what you need to do to make a system that uses SSL/TLS secure.

Chapter 6 - SSL Performance describes the performance profile of TLS-based systems. It's been widely observed that security imposes significant performance demands on systems, but it's not widely understood that this impact is limited to certain parts of the protocol. We'll discuss these issues with an eye to getting better performance while preserving good security.

Chapter 7 - Designing with SSL is a guide to using SSL/TLS to secure application layer protocols. We focus on identifying the required security properties and on well-understood design techniques for satisfying these properties.

Chapter 8 - Coding with SSL discusses the common program- ming idioms required to write software that uses SSL/TLS. We provide complete sample programs in C and Java using the OpenSSL and PureTLS toolkits.

Chapter 9 - HTTP over SSL describes the application that started it all. SSL was originally designed by Netscape to work with HTTP and we cover both the traditional way of doing things and the replacement that's currently being proposed.

Chapter 10 - SMTP over TLS describes the use of TLS to secure the Simple Mail Transport Protocol (SMTP) which is used for transporting email. SMTP is a bad match for TLS and this chapter illustrates some of the limitations of SSL and TLS.

Chapter 11 - Contrasting Approaches is devoted to describing other alternatives to securing your applications. SSL/TLS isn't always the best solution and part of knowing how to use a protocol is knowing when not to. This chapter tries to give you a perspective on your other choices. We discuss IPSEC, S-HTTP, and S/MIME as alternatives to SSL/TLS.

How to Read This Book

This book is suitable for a number of audiences of different technical abilities and requirements. You should read any section that interests you, but depending on your needs you may want to focus on specific sections.

Protocol Designers

If you're designing a new application-level protocol or securing an existing protocol with SSL, you should read the first parts of Chapters 1-6 so that you have a good general understanding of how SSL works. Then carefully read Chapter 7 for a guide to SSL design principles. You can skip Chapter 8 unless you intend to implement your design, but be sure to read Chapters 9 and 10 so you can see real-world examples of how SSL should and should not be used in practice. Finally, before you start to design, read Chapter 11 to make sure that SSL is appropriate for your design and that you wouldn't be better served by using another security protocol.

Application Programmers

If you're writing an application that uses a preexisting SSL toolkit you can safely read only the first parts of Chapters 1-6. You should also read the summaries at the end of each chapter. These sections discuss SSL and SSL implementation techniques in overview form. This will provide enough information to understand what your SSL toolkit is doing. You should carefully read Chapters 7 and 8, paying special attention to the programming techniques discussed in Chapter 8. If you are implementing HTTP or SMTP over SSL, you should also read the chapters that deal with those protocols.

SSL/TLS Implementors

If you're implementing SSL from scratch, you should read the entire book. If you're already familiar with cryptography you can skip Chapter 1; however, if you don't have a detailed knowledge of cryptography you should read the entire chapter. You should pay particular attention to Chapters 2-6, which provide a detailed description of SSL and of the various implementation techniques required to produce a fast and secure implementation.

Just Curious

If you just want to learn about SSL you can skip around in the book. If you don't already know about cryptography, read all of Chapter 1. Then read Chapters 2-6 so you know how SSL works. Then you can read as much or as little of the rest of the book as interests you. It's probably worth reading Chapter 11 to get some perspective on how SSL compares to other security protocols.

SSL/TLS Versions

By now you've no doubt gotten tired of seeing the name SSL/TLS. We've been using it to avoid being specific about exactly which version we mean. There are currently two versions of SSL in wide deployment: SSL version 2 (SSLv2) and SSL version 3 (SSLv3). TLS, a modification of SSLv3, was standardized by the Interenet Engineering Task Force (IETF) in 1999. Despite what you might think from the names, SSLv2 and SSLv3 are completely different protocols, and TLS is extremely similar to SSLv3. SSLv2 is essentially obsolete, and TLS isn't really in wide deployment as of this writing. In general, we'll use the term SSL to refer to SSLv3/TLS interchangeably. When we mean one or the other, we'll specify it explicitly. In the few instances when we're talking about SSL version 2, we'll use SSLv2.

0201615983P04062001

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)