HTTPS and SSL: Thoughts and Musings...

I like bikes. If you've ever clicked through and looked at my profile, and wandered over to my other blog, its filled with all sorts of pictures of bikes, and bike parts. Its gotten a little ridiculous here, with piles of parts on my desk -- just yesterday, Dino inquired as to whether there was a stapler on my desk behind the pile of derailleurs. Anyhow, I've been selling off parts recently, on eBay. Clears out space at home, makes the wife happy, and gives me an excuse to buy more stuff.

I'm getting to a point here, I swear.

So this weekend, I was logging in to Paypal to check if I have been paid for some of stuff I just sold. Up popped a dialog box, indicating that their certificate had expired that day, and did I wish to accept it, etc, etc. Of course, I clicked the continue button, as I've been conditioned to do. These things happen way too often, and usually are pretty innocuous. I hope.

But it got me to thinking about the widespread use of HTTPS. Clearly, the internal and external threat models are radically different things. The external threat is from things like phishing attacks, people trying to guess passwords on sites, and breaking in to services.

Sure, sniffing on the Internet is possible. Dave and I were discussing it as a viable attack this afternoon. People have documented all sorts of theoretical ways in which one could go about sniffing traffic from more than a hop or 2 away. It's possible, to be sure, but its not a trivial attack, and requires all sorts of criteria be met to even begin to attempt to handle the massive quantities of data we'd be talking about. Protecting data in motion is a valid concern, but my experience suggests that the threat lies more with the data at rest (ie, stored in a database).

Really, though, I'm more interested in internal security than external these days, so rather than go in to a whole thing about what HTTPS really does for Internet facing web applications, lets just say it addresses the (potential) sniffing problem, and ensures I'm talking to a valid server, assuming I'm not the kind of user who ignores error messages from my browser. SSL can do a whole lot more, including peer authentication, but its rare to see that being implemented. Most websites just use SSL to wrap a tradition login page.

On the internal network, people are beginning to talk about encrypting their traffic. People I've asked the question of "why" to don't seem to have very convincing answers. So I've come up with a few for them:

• Protecting data in motion from observation
• Peer identification and authentication
• Because someone told me I should.

And thats about it. I'm not saying those are good or bad reasons, or even what ends up being implemented. Just some reasons people may toss out. That being said, I bet a few of you have some experience implementing or justifying using HTTPS/SSL on the internal network. So rather than ramble on and take a position thats based on my experiences, I'd like to hear what you think. Here's a micro questionnaire:

• Do you use HTTPS on your internal network?
  • If so, for what types of applications?
  • If not, do you have plans to? When?
• Do you use SSL with other applications?
  • If so, what?
• If you do use HTTPS, did you decide to do this to
  • Prevent sniffing?
  • Prevent man-in-the-middle attacks?
  • Prevent host spoofing?
  • Do all my identification and authorization?
• Do you use client side certificates?
  • If so, how do you distribute these certs?
• Do you issue your own certs for internal use?
  • If so
    • Do you issue them for servers?
    • How about client machines?
    • How are you validating these certs?
  • If not
    • Do you purchase them for servers?
    • How about client machines?

Feel free to mail it to me directly, post it as a comment, respond to it in your own blog, or whatever. If you do, I'll make sure Dave buys you a beer at the next conference I'm at.