securing ssl certificates on web servers

[shimi]

On Fri, Jan 29, 2010 at 11:25 AM, Amos Shapira <amos.shapira at gmail.com>wrote:

> 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:
> >
> > 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?
>

 "Until it's actually used" ? It's used in every request... no?


> >
> > 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).
>
>
I do hope the Internal network is actually a "backend network", and not your
real Internal network... :)

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

The SSL termination point must present a certificate to the connecting
client; If the front server does not do that, and handles the connection to
a backend, it effectively means the frontend is a stupid TCP proxy (unless I
missed something) or even a simple NAT / load balancing device; Not an
actual HTTP server... if IP translation is the only thing it does, I think
it is a bit redundant... but again, that's just me :)


>
> > 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.
>
>
OK, but that's a marketing decision. It has NOTHING to do with security.
Your question was how to secure this. If you want to know how to sell it,
you need a marketing guy :) You could try to explain that your competition
is busy with telling stories and buzzwords, while YOU take care of what's
IMPORTANT. They might believe it and might not, but again, this is a
marketing venue...  It's OK to do what you said you want to do, as long as
you keep in mind that you're adding nothing to security, and you're adding
complexity instead; From my experience, complexity tends to be the enemy of
Uptime. YMMV :)


> 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.
>
>
Exactly my point. The HW load balancers (well, most of them?) are probably
PC appliances running code not much different than Nginx/Varnish and
friends. I know some hardware "accelerators" use actual proprietary hardware
to be able to process a huge amount of connections / attacks, but again,
those are prone to bugs just like software is, though are probably much
harder to fix when a bug is discovered...


> >
> > 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).
>
>
That's sad to hear :| Been there, done that... wish you luck! :)

-- Shimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100129/d7d4ace7/attachment.html>