Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Privacy Books Media Book Reviews

SSL and TLS: Designing and Building Secure Systems 36

Posted by timothy from the late-than-never dept.
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.
This discussion has been archived. No new comments can be posted.

SSL and TLS: Designing and Building Secure Systems More

SSL and TLS: Designing and Building Secure Systems

Comments Filter:

  • Keep in mind that... (Score:1)

    by Anonymous Coward
    SSL/TLS protects the information while it's in transit. This is pretty obvious but people tend to forget that this is all SSL does (and rightly so, it should not do more)

    This is to say that you shouldn't necessarily feel safe because a site allows you to submit information through SSL. The real question is, once the information is safely transited to the online store, how safely is it stored?

  • A big problem is that many people assume that if the site is SSL protected, then your data is secure. This is far from the truth! SSL is only a tiny part of the solution for creating a secure web site.

    For example, imagine you are entering your credit card info for your favorite online retailer. You see the little lock in the corner of your browser. Maybe you are one of the very few people who actually double-clicks on that lock to view the information about your SSL session and the servers certificates. Heck, maybe you're really smart and even have server certificate revocation checking enabled (assuming your browser supports it.) You're happy that your credit card information is being encrypted and is safe as can be.

    But in reality, that credit card number is only encrypted as it travels from your web browser to the web server. As soon as it hits the web server, it is decrypted. And of course, no ecommerce site uses single webserver for its entire operation. So now your unencrypted credit card number is sent over a network to a datbase. And then it's extracted and sent over the network for validation. And then it's sent over the network to generate your confirmation email (but they nicely X out the last 16 digits to make you feel safe.)

    SSL was a nice, easy little system to make people feel secure, but it's time has come and gone. We need a system that will allow -persistant- encrypted data. I want to be able to encrypt data on my web browser, and have it stay encrypted all the way to that back-end database. The web server has no need to decrypt it.

    Disclaimer: I work for Entrust. We work on this stuff.

  • While I totally agree with you that this is a very nasty problem, I dont understand why you impute a "cash cow" motive to not fixing this. Fixing this problem is non-trivial. The fundamental problem with virtual hosting and SSL is that the ip-address (from the ip-level information) is used by the webserver to derive the decryption key that needs to be used to decode the payload. However, with virtual hosting, the ip-address points to many domain names, and thus is not sufficient information to determine the decryption key. The Host header, which would be useful for this, is encrypted within the payload.

    Now, you may argue that the SSL protocol could be "fixed" by taking this information outside of the SSL encapsulation and placing it in a plaintext form (as part of an un-encrypted SSL "header"). This would break the HTTP protocol. If this information is merely duplicated, the problem would be solved - but only for HTTP. Remember that SSL can be associated with any TCP based protocol, and for this solution to work, the SSL client would have to determine which protocol is being used, then determine on the basis of this info, which information would have to be duplicated outside of the encrypted payload. This is not a good engineering solution.

    Perhaps you have thought of a better solution?

  • 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.
    --

  • 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.
  • 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.
    --
  • Quite true! Although, in some cases the security risks requiring something like SSL are overrated. How often have you heard about someone's credit card information being stolen after being sniffed off of the network - versus being stolen after an insecure server was broken into? Way too often both the customers and the owners of the e-commerce (or whatever) servers place too much trust in the use of SSL/TLS without considering ALL of the other security issues. Most likely because the use of SSL/TLS is openly advertised and obvious - a badly configured server is not so apparent but far more critical. Issuing certificates is also a lucrative business but one with some dubious assumptions of substantial value.
  • Sorry, that should have been ARIN, not the IANA.

    My bad.
  • 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.

  • The nastiest bit about SSL... (Score:4)

    by Velox_SwiftFox ( 57902 ) on Thursday June 07, 2001 @11:19AM (#169166)
    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.

  • my three cents (Score:3)

    by joq ( 63625 ) on Thursday June 07, 2001 @05:44AM (#169167) Homepage Journal

    Good to see more security books are coming out and I agree an intro into stunnel [stunnel.org] 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 [antioffline.com] could've given clarity to those who don't understand some of the overhype about PKI.
  • There are two ways to have an absolutely secure system (or as absolutely secure as possible):

    1. A system with an encrypted filesystem (rubberhose, perhaps), no external connectivity, in a room coated with a 10-foot thick layer of lead. Rig the case to dump strong acid on the internals when opened, thus destroying them entirely. Write a custom BIOS to use a specific sector on the hard drive to boot from, without any possibility of changing it. Compile the kernel to run only signed binaries, with a 2,048-bit encryption system for the signature. Etc.

    or

    2. Take hammer. Pound computer into small pieces. Repeat until satisfied.
  • I don't know if this is insightful or funny.
  • 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 [slashdot.org] comparing the two (usual /. caveats apply), if you care.

  • thinkgeek url (Score:3)

    by paranoic ( 126081 ) on Thursday June 07, 2001 @05:39AM (#169171)
    Until those folks fix their links, use http://www.thinkgeek.com/stuff/things/3782.html [thinkgeek.com]

  • 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 [ibm.com]

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

  • After reading this book, download a copy of Stronghold [c2.net] from C2.net/Redhat. It's really robust and built quite well. Ported over to multiple platforms, too.

    If you run a business, it's worth the $99 for the license. Otherwise it's a great build of Apache w/SSL that's fun to evaluate.

    For those of us who already use Stronghold, this book looks like a great reference book - a must have. I'll be sure to get a copy.

  • With mod_ssl you can set up a HTTP server using SSL to encrypt data. SHTTP is another protocol that can only be used with HTTP. SSL otherwise is used with many protocols to give security. (IMAP, HTTP, STUNNEL for forwarding...)
  • Is there a tool that allows me to capture and save the x509 certificate given out by an https server?

    For example, in order to use java to connect to an https server with a selfsigned cert, you first have to import the cert so that it is trusted - but there's no easy way to get that cert in a file unless you control the server in question.

    So how do you get the cert?

  • What the hell? I thought SSL was a transport protocol, that just happened to be encrypted. Even a description of all methods of using SSL with your favourite programming language AND a description of a sample implementation of SSL (for those who like wasting their time reimplementing protocols) would take less than the full length of a book.
  • You respond to a surreal troll, asking for a serious explanation? Are you mad?

    Okay then. Basically, when you throw a ball into the air, you have to supply a force greater than its weight. The reaction to this is a downward force on the thrower. So, throwing the ball upwards also pushes you downwards by the same amount.

  • Is mod_ssl the mechanism used to create an shttp connection? I probably should do a search for apache documentation, but I'm hoping the slashdot crowd can help me out the easy way ;-) Is configuring mod_ssl all you need to do to get some information securely from the browser to a middle-tier process? Anyone have links to free resources on the subject, or is the info as hard to find as the reviewer suggests?

    Thanks,

    --d

    Well, your fingers weave quick minarets; Speak in secret alphabets;
  • 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 [antioffline.com] site.

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

  • 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;

  • I know you can do it with current browsers, but when MIT set up its SSL PKI a few years back, some users had a hard time with the series of dialog boxes involved in getting a certificate. We also had to do a lot of work to get certificate support integrated into Lynx. IIRC there was some issue in getting the same server (or was it CA?) cert to work in both Netscape and IE.

    MIT solved the transport issue by setting up its own CA server, where you could type a password into a web form and get a cert in your current browser. No problem with having many valid certs, and you could set them to expire in a short time if desired.

    The nice thing is anyone can set up a web server that authenticates MIT users, without needing any special private key.

  • 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.

  • Can only be obtained by using a server like this [bbspot.com].

  • Thanks for all the hard work! (Score:3)

    by ackthpt ( 218170 ) on Thursday June 07, 2001 @05:55AM (#169184) Homepage Journal
    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!

  • The linked article [antioffline.com] has an unfortunate title:

    Ten Risks of PKI: What You're not Being Told about Public Key Infrastructure By Carl Ellison and Bruce Schneier
    One might interpret this as the 10 risks of PKI that Carl and Bruce aren't telling us :-)
  • I like SSL/TLS, a few years ago I used it while writing a web based interface for a legacy information system since the info system did not run a web server, I needed to securely transport the data to the secure web server.

    Using SSLeay and later OpenSSL, it wasn't that hard, but the interface in my case was quite limited. I can imagine that writing a larger scale client-server system might need a handy reference like this book, I didn't find writing a simple very hard based on Eric Young's example code.

    Does it cover digital certificates (X.509) used to verify the players (client, server) are whom they claim to be? If so, does it deal with everyone's favorite security buzzword, PKI?

    SSL was not developed as a black art, Netscape published white papers about it right from the beginning. Probabilly still on their site, though I don't know where any more. And the open-source of SSLeay, later OpenSSL (after Eric and Tim joined RSA-Austrilia) had source code and example code, while not the easiest, quite manageable if you understand client server programming and cryptography.

    SSL/TLS is not very hard if you know the bits, I take it this book helps those who aren't familiar with those bits.

  • Myth #2: Because I am incapable of doing something, it can't be done.
  • Sorry, my friend, but your card number fails the secret 'mod 10' check built into every swipable account number. Nice try, though.

  • heh (Score:2)

    by waspleg ( 316038 )
    "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

  • This book is absolutely top-notch. I've been working with SSL lately and have found the book invaluable. The writing is crystal clear and the author really knows what he's talking about. It's worth reading even if you don't need to know SSL, just for general education and edification (although if you're not using SSL you can skip over the sections that go into detail). It doesn't get any better than this.
  • We can only hope that Profligate doesnt become as ubiquitous as ubiquitous! It seems like everyone has the same word-of-the-day calandar!
  • Although this book is not too bad, I've read better. Let's face it, SSL is "like so yesterday"--pardon the analogy to the valley girls-remember them, way back?

Slashdot Top Deals

Nothing ever becomes real till it is experienced -- even a proverb is no proverb to you till your life has illustrated it. -- John Keats

Close