Re: vulnerability/SSL - Mailing list pgsql-general

--- Marco Colombo <pgsql@esiway.net> wrote:

> Either the Windows backup contains the private key
> of the user or not.
>
> If not, the backup is incomplete and useless (to get
> the file contents).
> You may get other files from it, but that's not the
> point. You may just
> not include the key file in _that_ backup.
>
> If you have two backups, one "normal" and another
> "safe", just put the
> keyfile on the safe one, along with the other
> private keys. You can do
> the same under Unix of course.
>
> If your single backup contains the user private key,
> EFS is bypassed as well.

I don't think we should include everything in ONE
backup. Incremental and differential backup are often
used, but they need several backup to resore the
system. And as I have said, the user's private key can
be exported in a standard pem file, encrypted by a
password only known by himself(not use EFS, just the
same as any encrypted pem file), if you don't know the
password, how could you bypassed EFS?

>
> This is going offtopic. The EFS approach is no
> different from any
> encrypted filesystem, nothing new under the sun. It
> shares the weakness
> of any system that lets you access the data at
> runtime w/o password.
>
>
> Save the server key in the same way then. Put the
> server key and the
> user key together.
>
That is not a good idea, you have to encrypt the
server's key and delete the plain key before you
backup.

> [...]
> > If an intruder can break the postgres or root
> account,
> > he can read everything, as have been discussed,
> not
> > only the key but also the data file. So in this
> > situation, it's useless to protect the key only.
>
> Yes, it has been discussed: the purpose of the key
> is not protecting the
> data, but protecting your identity. If the key is
> compromised, they can
> impersonate you. Generally, this is much bigger a
> damage. They can
> create fake data, _signed by you_.
>
But this key is only used for SSL of my postgres, so
even it is copromised, the only way the intruder to
use it is to decrypt and forge data between client and
postgres. If he can access the data directly, why not
he do so?

> [...]
> > Yes, the .pem file can be kept for distribution
> and
> > backup, but the working copy has to be plain.
> >
> > > The daemon should ask for the password only
> once, we
> > > agree on that.
> > >
> > Yes, that's the ultimate solution. So we can use
> > encrypted key without any outside mechanism.
>
> We agree on that. That's the _only_ solution if you
> want that kind of
> security.
>
>
> That changes nothing. Somehow the key as to be
> given, unencrypted, to
> the server. Be it an operator typing a password, or
> inserting a
> smartcard, a patched server can store the key in
> cleartext anywhere.
> You have to teach your operators to think twice
> before performing
> anything that lets the server access the key. With
> your solution, you're
> letting the server access the key automatically.
>
It's also a problem with encrypted pem.

> > > The EFS encryption as you described it adds
> nothing
> > > but a false sense of
> > > security (and the ability to use some more
> > > buzzwords). The level of
> > > protection is just the same of a Unix file with
> the
> > > right permissions.
> > > The key point here is that both the 'postgres'
> user
> > > and 'administrator'
> > > have _transparent_ access to the file contents.
> No
> > > password required.
> > >
> > At least it make it impossible to restore the
> plain
> > key from backup.
>
> The safety of that backup lies only on its
> incompleteness.
>
> If you include the user key in the same backup,
> there's no security.
> If you don't include the user key (and thus create
> an incomplete
> backup), it's easier not to include the server key
> either, and put it in
> the same place you put the user key. They are both
> "private keys".
>
> Including a useless copy of the server key encrypted
> with the user key
> (stored elsewhere) is just a perverse way to gain
> nothing.
> But I agree that sometimes perverse systems make
> perverse things look
> natural. :-)
>
In your logic, then all the encryption algorithms are
"perverse" because they rely on incompleteness, you
can never include the key itself in the encrypted
data, you always need to keep something secret.

cheers,
Changyu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com