Re: vulnerability/SSL

Поиск
Список
Период
Сортировка
От Marco Colombo
Тема Re: vulnerability/SSL
Дата
Msg-id 1118315476.12004.73.camel@Frodo.esi
обсуждение исходный текст
Ответ на Re: vulnerability/SSL  (Changyu Dong <dcy1_1999@yahoo.com>)
Ответы Re: vulnerability/SSL  (Changyu Dong <dcy1_1999@yahoo.com>)
Список pgsql-general
On Thu, 2005-06-09 at 02:59 -0700, Changyu Dong wrote:
> Hi Marco,
> The problem I described in the first mail is that
> because of some unknown reasons, if you save the
> server.key file with a passphrase, you will be
> prompted to enter the passphrase every time you start
> the server AND a client make a connection, which
> actually forbids us to use a passphrase to protect the
> key file, therefore the key file have to be saved in
> plaintext without encryption.
> EFS is a feature provided by Windows which will
> encrypt any selected file using a symmetric algorithm,
> the symmetric key will encrypted by the user¡¯s public
> key and the recovery agent¡¯s public key and the
> encrypted key will be saved within the file header.

As long as the 'postgres' user has access to it w/o typing any password,
that's only a detail. Unless someone physically steals your disk, the
fact it's stored encrypted is irrelevant. The only thing that matters is
who can access it, and how.

> Thus only the user and recovery agent can decrypt it.
> And for another user, he cannot even open it (but can
> delete it). So we can ensure no one can read and
> modify it.

That's how the permission bits work in Unix. No need to encrypt the
file, we know permission bits actually work as expected under Unix. In
this case encryption adds no extra level of security on a running
system.

>  Decryption is transparent to users and
> applications. The operation system will do it
> automatically if it can find appropriate private key.
> The difference between this and -r--------  1 postgres
> postgres    50 Jan 15 21:15
> is that the file is encrypted using EFS, while the
> latter is remain plaintext.

I fail to see the difference. On Windows, the 'postgres' user can read
it without password. 'Administrator' has access to it, too.

On Unix, with 400 permissions, the 'postgres' user can read it without
password. 'root' has access to it, too.

> When you backup the file, it remains encrypted.

Then the backup is useless. If the secret key of the user 'postgres' is
lost (and it can be, since it is stored elsewhere, I think buried
somewhere where 'Administrator' can find it, maybe in user profile),
you'll never recover then content of the file.

> If you
> restore the file to a file system which doesn¡¯t
> support EFS (non-NTFS), it will corrupt, else it will
> remain encrypted.

Now THAT puzzles me a lot. I can imagine it be restored in plain. I can
imagine it be restored encrypted. I have no way to justify the file
contents being lost only because of restoring it on FAT.

Anyway, that's not the point here.

The point is: on Windows, if someone breaks in your 'postgres' account,
he can read the key. If someone breaks in your 'administrator' account,
he can read the key. But other users cannot read it.

This level of protection is exactly the same provided by the 400
permissions above under Unix. If someone breaks in the 'postgres'
account, he can read the key. If someone breaks in the 'root' account,
he can read the key. But other users cannot read it.

I fail to see any difference in the above scenarios.

Encrypting the key in the .pem file (as supported by openssl) is
completely different! No one, ever, can access it w/o knowing the
password. That's why it takes the operator to type the password in.
Also backups are safe. And just as useful as the file itself, they can
be restored everywhere. If someone forgets the password, the contents
are lost, but that's true for the file itself. The backup is just what
you expect to be, a copy. You restore it, and get a _working_ copy for
the file, on every filesystem. The .pem key can be sent by email even,
as is (since it's base64 encoded).

The daemon should ask for the password only once, we agree on that.

Storing the key encrypted (in the openssl sense) doesn't help much
against root, if he's able to trick the operator into typing the
password again. If you're able to avoid it, that is you're in a highly
secure environment with operators trained _not_ to type the password in
"just to have the server restarted", .pem encryption adds a lot to your
security.

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.

.TM.
--
      ____/  ____/   /
     /      /       /                   Marco Colombo
    ___/  ___  /   /                  Technical Manager
   /          /   /                      ESI s.r.l.
 _____/ _____/  _/                      Colombo@ESI.it


В списке pgsql-general по дате отправления:

Предыдущее
От: Jernej Kos
Дата:
Сообщение: Postgre "idle" process using 100% CPU
Следующее
От: "Ets ROLLAND"
Дата:
Сообщение: Pb with linked tables on PG8