securing ssl certificates on web servers

[Amos Shapira]

On 29 January 2010 18:43, shimi <linux-il at shimi.net> wrote:
> On Fri, Jan 29, 2010 at 3:06 AM, Amos Shapira <amos.shapira at gmail.com>
> wrote:
>>
>> My question - am I re-inventing a well-known wheel? I couldn't find
>> anything like this when google'ing around.
>> I know there is a lot of "security by obscurity" here, any PRACTICAL
>> ideas on how such a system can be improved? (please spare me the "it
>> can't be totally secure" spiel, I know that).
>>
>
> Sorry that I am not sparing the "it can't be totally secure"...
>
> Shouldn't your question be: "if someone managed to get root access to my
> machine, which is what's needed to read the key file which is chmod 600 with
> uid 0, what stops him from reading the key from the process memory of an
> already running Apache without restarting it even I don't store the key on a
> file?"

Does Apache keep it in plain text in memory or maybe it obscures it
until it's actually used?

>
> Not to mention that if the attacker got root access on your machine (and
> sometimes even less than that, enough to read your scripts with the DB
> credentials) - what do you care if he could read sessions between the server
> and the client, if all the sensitive client data is stored plaintext on the
> DB (or with a reversible encryption that utilizes a key in the code which
> equals plaintext...)

Our front line web servers do not store any static data, they transfer
it to servers on the internal network. We also aim to do the same for
log files on the DMZ (have issues with syslog performance).

We hear that Akamai don't store certificates on their front line
servers at all and have them shipped to the servers on-line.

>
> I mean... I don't think it's "security by obscurity" simply because I
> believe this measure is not obscuring anything useful...
>
> I think you should concentrate your efforts on maximizing web scripting code
> quality and input validation, using multi-tier security mechanisms if
> possible (like web servers chaining and/or privilege separation between
> different parts of the code that needs different DB access privileges),
> chroot jails, watch for security advisories on the software you chose to use
> at all tiers (don't forget the Kernel) etc... I believe it would make your
> security much better than fiddling with a private key file that only root
> can read on your server...

Part of this is how corporations make decisions, some of our clients
want to give us SSL certificates for servers under their domain names
and will feel more comfortable with us telling them that we don't
store them in plain text. When others (like - competition) tell them
the same you have to play by these kind of rules.

Same reason we are looking at hardware load balancers even though we
are very happy with LVS - that's the kind of stuff corporations make
decisions about.

>
> And finally, Apache is a huge bloat; The more bloat you have, the more you
> sacrifice on performance, and in my opinion, security. The less code that
> runs to serve your requests, the less chance for security issues down the
> road; But that's just me :)

I keep digging into our product management chain my concerns about
using Apache - not just for security but even for plain speed. But
it's deemed by Dev to be a none-trivial effort to move away from it to
when higher priority tasks are still on the plate (part of our Apache
code is written as C++ apache modules).

Thanks for your thoughts.

--Amos