Hacker News Reader

Comment by fauigerzigerk | Hacker News Reader

What gives me the most headaches is how to protect my private key. The key has to be accessible to all web servers at all times, which usually means it is stored in clear text on the hoster's machines and automatically backed up on media that is stored who knows where.

I have no control over who can access it there. I'm not running the data center. I'm not hiring the staff. I'm not deciding on any monitoring. I basically just throw that key over the fence hoping the hoster will keep it secured.

And then I turn around and tell my users, trust me, only me and you can see the data we're exchanging. Isn't that one big lie? How do I handle this in a less haphazard way?

View on HN

If you want that level of security, your only solution is to own all your servers and have very strong physical security. The problem is that most web sites cannot justify the expense.

If you follow all the recommendations from the guide -- which is not that hard, in my opinion -- your (TLS) security will be among, say, 0.1% of the sites out there, or better.

Going back to the key protection: for the rest of us, the best you can do is always use a password with your key. That won't protect it on the web server, but it will protect it when you back it up independently.

Then, find a CA that allows unlimited key/certificate regeneration and rotate your private key (and revoke the previous certificate) every month, and every time your staff changes.

The TaoBao version of nginx has a patch to send the private key through the network to the server. IIRC. In that case, it won't be lying around in plaintext on your server's disk.

I will edit this post with a link if I can find it again.

I run a small number of servers, so I've password-protected my private keys.

That's interesting, but I don't think it raises the bar a lot. Private keys are still kept in process memory, from where they can be easily extracted by the attacker who can attach to the process.

A great innovation would be to have web server fork a special process that will only handle private keys. That other process would be running under a different username. Bonus points if a separate process can be deployed for each key. (It's possible to achieve a similar effect by running decryption in a separate proxy layer.)

My two cents is that requiring the ability to snoop on a running process is a significant extra hurdle compared to simply reading the filesystem.

Especially for virtual machines which almost everybody is running on these days. An attacker can simply read the disk from under the OS.

Although I can understand why you might think it's not significant enough. I do agree that storing private keys in a separate user's process can help with security.

Replying to myself since I can't edit my reply now.

This is the link to the TaoBao Tengine doc describing the feature: http://tengine.taobao.org/document/http_ssl.html

My memory was faulty: they have a way to get the passphrase, not the key itself. But wrt security, both are equivalent.

Thats why you host it on-site and not with a hosting provider. Any company worth its salt will be able to run one or two servers at its location under its supervision.

Hosting providers are for those small php sites that depend on AdWords for their income.

Try telling Netflix that.

How come Google can do it?

Why cant Netflix?

Cause Google has mostly equal traffic levels 24/7/365, while Netflix has huge spikes, which are impossible to efficiently sustain with bare metal hardware.

Also, Google's revenue is more than 10 times that of Netflix, and they have highly custom software and hardware.

Reply on news.ycombinator.com