SSL and TLS: Designing and Building Secure Systems

Credit card numbers? Personal correspondence? Medical information? If you've ever sent anything you'd like kept private over the profligate and global Internet, be grateful there are good guys devoted to keeping private information private. The long-suffering RantyDave reviews here for your learning pleasure Eric Rescorla's SSL and TLS: Designing and Building Secure Systems; readers should also check out the amazingly prolific Danny Yee's review of the same book. Both reviewers indicate that this is a book whose learning curve is worth tackling. SSL and TLS: Designing and Building Secure Systems author Eric Rescorla pages 499 publisher AddisonWesley rating 9 reviewer RantyDave ISBN 0-201-61598-3 summary Eric Rescorla talks us through SSL, from firstconcepts thru protocol all the way to example code.

The Scoop Until recently SSL was the black art on the Internet. The (not incidental) details were passed around almost as word of mouth leaving only a few individuals actually able to implement secure services and the rest of us staring at ethereal in bewilderment. It stops right here. Eric Rescorla starts at the very beginning and takes us at breakneck pace through to full byte-by-byte implementation of SSL, HTTP over SSL and anything halfway relevant along the way. Written in the tradition of 'TCP/IP Illustrated' expect clear diagrams, copious code samples (OpenSSL and Java) and ruthless attention to detail. What's to Like? Two words: Horse's mouth. Rescorla is the author of RFC's 2659, 2660 and 2818 (HTTP over TLS). Also the Java PureTLS toolkit (free), ssldump (free), some commercial toolkits and parts of Nokia's SSL offload boxes. In short, he knows his stuff and it shows.

One way it shows is that you'll never be short of an explaination. Every third paragraph seems to be why it is that we do something, and for me at least this is almost as relevant as what. This leads naturally over to discussion of the historical perspective of SSL/TLS and a surprisingly neutral standpoint with even our friends in Redmond getting credit where it's due. The correctness also shows with the book being fully up-to-date with the patent and export situations, although obviously this may be subject to a sell by date.

The performance chapter gives actual figures on a variety of algorithms and platforms (mostly FreeBSD and OpenSSL) and is major slashdot fodder.

What's to not Like? Very little. I would have liked to have seen a brief mention of (/usr/ports/security/)stunnel as a quick'n'dirty SSL wrapper or offload box. I also found the line-by-line coverage of mod_ssl's session caching code (end of appendix A) a bizarre choice - or are we being given hints towards transparent failover? What's to Consider? This is a large, complex subject and although the writing is clear, you're looking at a long and fairly steep learning curve. If your hope is to get mod_ssl up and going on a cable modem, this is not what you need. If, OTOH, you were looking to contribute to mod_ssl, this would probably be a good starting point.

This is no quick fix or howto, it's about understanding. Be prepared to take a little while and let it all sink in.

The Summary Hard work, but worth it. Worth the price of admission just to use Chapter 1 as a companion to Cryptonomicon.

Table of Contents

Security Concepts

Introduction to SSL

Basic SSL

Advanced SSL

SSL Security

SSL Performance

Designing with SSL

Coding with SSL

HTTP over SSL

SMTP over TLS

Contrasting Approaches

1. Example Code
2. SSLv2

You can purchase this book at ThinkGeek.

Comments

The nastiest bit about SSL...

[Velox_SwiftFox]

Is the bizarre assumption made by the initial connection protocol that there is a one-to-one relationship between IP address:port, hostname, and certificate. When in fact a web server should be able to serve a variety of virtual hostnames, and for that matter, a host name should be able to refer to more than one IP address.

In fact, the way the certificates are designed, only one IP:port may be used for a given hostname, without using bizarre port redirection schemes or (possibly) features found in expensive SSL accelerators (Certs issued by some authorities with wildcards only work for the few using Netscape browsers, and other CAs just won't issue such certificates).

Unfortunately, no commercial site can tolerate having an address that has to specify a port number, not least because firewalls often will not pass traffic to nonstandard SSL ports for security reasons both real and imagined by sysadmins writing firewalling rules. Often the only alternative is to use multiple Internet-addressable IP addresses aliased on a box - this is a total pain in the butt that unnecessarily devours IP space and cripples server farm functionality, and one which by report the SSL working group has obstinately refused to fix, and that is largely responsible for the IANA having to withdraw its proposal that multiple-real-IP virtual servers be replaced with the IP-address saving virtual hostname method, rendered nonfunctional by SSL.

Evidently preserving the cash cow that is represented by the guarantee that a certificate will have to be bought for each and every IP and each and every hostname (or that an SSL accelerator board will be purchased) is considered more important than either functionality or the problems with address congestion.