Slashdot Mirror


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.

18 of 36 comments (clear)

  1. Re:Can someone clear this up for me? by larien · · Score: 2
    Personally, I found mod_ssl to be easier! Mind you, that was on Solaris, so YMMV.

    In any case, the two products do the same thing (ie, turn Apache into an https server) and seem to work just as well, so use whichever you want.
    --

  2. Re:What about certificates? by Ageless · · Score: 2

    Actually, there is plenty of browser support. Netscape supported client auth with X.509 certs long ago and IE does the same. The main hold back is that no one wants to pay for a password, and it's too complex. If you want to do client auth you need to buy a cert from Verisign or Thawte or whoever and then you need to install it. The first install isn't too bad... but when you are over your friends house and you want to show him the newest porn site you signed up for, you have probally forgotten to export your certificate and carry it around on a floppy.

    Until it's possible to remember everything you need to know to auth, or everyone carries some token we're not going to have widespread use of anything more than a password.

  3. Re:What about certificates? by IntlHarvester · · Score: 2

    I setup a system that used x509 client certs, and I'd agree that the "certificate store" is the biggest blackbox from the user standpoint. Users commonly switch machines and browsers, or have their machines reinstalled, and just had problems getting that there needed to be something "in" the browser for them to connect. If it was just a regular file you could copy it wouldn't be so bad (for example the Lotus Notes ID file, which effectively the same thing).

    On the other hand, we used a private CA, and nobody really squealed about it. Turns out IE and Netscape's handling wasn't so bad.

    I agree that this could be another great opportunity for the porn industry to show leadership.
    --

    --
    Business. Numbers. Money. People. Computer World.
  4. Re:The nastiest bit about SSL...opps by Velox_SwiftFox · · Score: 2

    Sorry, that should have been ARIN, not the IANA.

    My bad.

  5. Re:The nastiest bit about SSL... by Velox_SwiftFox · · Score: 2
    Umm...

    So how is it that some Netscape browsers manage to work fine with the wildcard type certificates so few CAs are willing to issue?

    Just curious...

    --
    Sirus Cybernetics Corporation Products-it is very easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words-- and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded--their fundamental design flaws are completely hidden by their superficial design flaws. - Douglas Adams, Hitchhiker's Guide to the Galaxy

    Sirus Cybernetics Corporation Marketing Division: A bunch of mindless jerks who'll be the first up against the wall when the revolution comes. - ibid.

  6. The nastiest bit about SSL... by Velox_SwiftFox · · Score: 4
    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.

  7. my three cents by joq · · Score: 3


    Good to see more security books are coming out and I agree an intro into stunnel would have been well worth it. Currently I wrap just about everything under stunnel, X, LICQ, pppd, and I love it. However on the other hand many people who don't understand SSL and are prompted for certificates would likely be offended to see an SSL cert created by something other than Verisign so the author should have attempted to debunk the idea that only Verisign or other vendor cert is law.

    Maybe referencing Bruce Schneier's doc either by snippets or including a link to the document could've given clarity to those who don't understand some of the overhype about PKI.

  8. Re:Can someone clear this up for me? by Fjord · · Score: 2

    You can use mod_ssl for that. I personally used Apache-SSL, because it was easier for me (back when I had to compile instead of using the RPMs). Now I don't know what I'm using. There apparently is a /. article comparing the two (usual /. caveats apply), if you care.

    --
    -no broken link
  9. thinkgeek url by paranoic · · Score: 3

    Until those folks fix their links, use http://www.thinkgeek.com/stuff/things/3782.html

  10. Re:Can someone clear this up for me? by overlord2 · · Score: 2

    I've been using IBM's implementation of Apache for pretty much everything *NIX. It has pretty much everything you need built-in (including SSL) and setting up the certs (self-signed or otherwise) can't get much easier. It even has an admin site included (if you like using these things) that wades through the soup that httpd.conf sometimes is.

    You can find it here: http://www-4.ibm.com/software/webservers/httpserve rs/download.html

    Oh yeah, and it's totally free too (not like Stronghold, etc.).

    --
    -- "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -A.Einstein
  11. Re:Can someone clear this up for me? by graveyhead · · Score: 2

    Do moderators just get kicks from modding other people down? Underrated? It was a serious on-topic question. No-one rated me up, so you are just sucking away my karma for no good reason. I'm beginning to seriously think that the moderation system here is totally broken. It doesn't achieve it's goal of reducing the signal-to-noise ratio, and it just pisses me off when I ask serious on-topic questions and my karma gets drained. This post will probably get modded "offtopic" but I'm starting to not care. I might as well be reading this site.

    Well, your fingers weave quick minarets; Speak in secret alphabets;

    --
    std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
  12. Re:Can someone clear this up for me? by graveyhead · · Score: 2

    How, exactly, was it a dumb question? I don't yet have any direct experience with shttp / mod_ssl / ApacheSSL, and I was looking for advice on reading materials *other* than the book being reviewed.

    People in a community generally help each other. I know it is difficult for us anti-socal geeks who spend most of our time telling a machine what to do, but could you have just an ounce of respect for another human being in need of assistance?

    If a newbie asked me a dumb question about, say, OpenGL, I would rather spend an hour explaining the subtleties than derriding them for their ignorance as you have done.

    This is now a real moral plea: slashdotters, get off your high horse. If you know everything there is to know about a system, don't just sit on your pedistal, congratulating yourself on how smart you are... share your knowledge! Be patient with the new guy. Some day, he or she might be in a position to help you out in return.

    Sorry for the rant, but I really believe slashdot has some great untapped potential for bringing us togther, and what we have done in the previous couple of posts is shameful.



    Well, your fingers weave quick minarets; Speak in secret alphabets;
    --
    std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
  13. What about certificates? by brlewis · · Score: 2

    Password-access sites have proliferated so much now that it seems SSL certificate-based authentication ought to make a comeback. Does the book talk about certificates much?

    Unfortunately, browser support is the main issue holding back certificates; probably too mundane a topic for his book.

  14. Absolutely security by briggsb · · Score: 2

    Can only be obtained by using a server like this.

  15. Thanks for all the hard work! by ackthpt · · Score: 3
    I'd like to buy all those security minded people a drink, here's my visa card #: 4428 2214 0010 5529 xp 04/02, please just one drink, thanks!

    --
    All your .sig are belong to us!

    --

    A feeling of having made the same mistake before: Deja Foobar
  16. Re:Myth #1 by flynt · · Score: 2

    Myth #2: Because I am incapable of doing something, it can't be done.

  17. heh by waspleg · · Score: 2

    "Until recently SSL was the black art on the Internet."

    i thought that was how to (effectively) bail the water out of your sinking dot com ship

  18. Re:Profligate by ShortedOut · · Score: 2

    We can only hope that Profligate doesnt become as ubiquitous as ubiquitous! It seems like everyone has the same word-of-the-day calandar!