Обсуждение: PKI/SSL Client/Server Certificate Authentication

The current PKI implementation seems to support the encryption aspects of
SSL/TLS, but what about using Authorization/Authentication?

I.e., when you configure SSL on the server, you're not specifying a
trusted CA cert (or directory of trusted CA Certs).

The client can specify REQUIRE_SSL environmental variable, but client
can't present an X.509 certificate.  There are no options on either the
client or the server to verify the authenticity of the peers certificates.

I ask because I generally discourage the practice of embedding database
passwords into source code.  That reminds me of Oracle, Solaris, and a lot
of other dirty, decrepit, security-hole-prone configurations.

However, "Another popular open source RDBMS" (whose name we wont mention
here) has a nifty feature that permits the mapping of certain Attribute
pairs in the DN= (sometimes called the "Subject) of a client X.509
certificate into the Username credential field.

Thereby:

- The database and the client submit CSRs to an mutually exclusive CA in
the organization

- The CA signs and returns X.509 certs to both.

- The server and client libraries configure to trust local copies of the
CA Cert

- The server requires client cert verification against the CA on the
server config

- The client requires server cert verification against the CA on the
client config

- The server configures a username/access grant like such:

GRANT ALL PRIVILEGES ON dbname.* TO
     -> 'web-app-meta-user'@'web-server-inside-dmz'
     -> IDENTIFIED BY 'goodsecret' (Optional)
     -> REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
        O=MySQL demo client certificate/
        CN=Tonu Samuel/Email=tonu@example.com'
     -> AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
        O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com'
     -> AND CIPHER 'EDH-RSA-DES-CBC3-SHA';

- Thus enforcing two-stage authentication, a very healthy practice.  This
adds a level of redundancy to security (In conjuntion with the use of
Views, ACLs, Firewall rules, Password Rotation, Auditing, Secure coding
practices, etc.)

If a "bad person" were to somehow obtain a copy of the source code with a
password embedded in the connect string (Steal it from a developer who
uses Windows, or maybe convince Apache to not interpret PHP before sending
to the client, something stupid like that), they would still be unable to
connect without a client certificate.

This two-stage authentication model is in use in Apache, OpenSSH sshd(8),
OpenLDAP, and FreeRADIUS (with EAP-TLS + PAP/CHAP).  It's even used on the
Cisco 3000 series VPN Concentrator by default (in all it's glory).

It's definately a very useful feature tha we should aspire to offer.

Thoughts?

TIA,
     ~BAS

"Brian A. Seklecki" <lavalamp@spiritual-machines.org> writes:
> If a "bad person" were to somehow obtain a copy of the source code with a
> password embedded in the connect string (Steal it from a developer who
> uses Windows, or maybe convince Apache to not interpret PHP before sending
> to the client, something stupid like that), they would still be unable to
> connect without a client certificate.

So they steal the client certificate file instead of (the file
containing) the password.  How exactly is this more secure?

            regards, tom lane

On Fri, 13 Jan 2006, Tom Lane wrote:

> "Brian A. Seklecki" <lavalamp@spiritual-machines.org> writes:
>> If a "bad person" were to somehow obtain a copy of the source code with a
>> password embedded in the connect string (Steal it from a developer who
>> uses Windows, or maybe convince Apache to not interpret PHP before sending
>> to the client, something stupid like that), they would still be unable to
>> connect without a client certificate.
>
> So they steal the client certificate file instead of (the file
> containing) the password.  How exactly is this more secure?

You'd have to get a local shell on the server *plus* the password.

If a hacker can get a local shell on your web server (not a multi-user
environment, obviously), and the Web server isn't in a jail, then they've
probably got your database server too, and you might as well pack up and
head home.

But with OCSP, the CA for the organization can revoke the validity of a
Cert at any time by updating the CRL.

The password is entirely optional for the user.  When you've got a Vhost
running multiple Apps talking to the same BD, and the Web servers runs as
the "www" or "http" user, you can even plug multiple database user
passwords into user ~/www/.pgpass and the username is mapped via the
Client X.509 cert.

In short, it's a deterrent to hackers and a convenience to admins.  But we
all know if someone wants in, they'll get in and it won't be some kind of
attack a weakness in X.509 PKI, it will be the develpoer on Windows that
opens the e-mail with the attachment (or image file!)

~BAS

>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

l8*
     -lava

x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8

On Fri, Jan 13, 2006 at 12:19:38PM -0500, Brian A. Seklecki wrote:
> In short, it's a deterrent to hackers and a convenience to admins.  But we

Not just that.  Unless something big has changed when I wasn't
looking, the jdbc driver can't use the .pgpass mechanism yet; but it
_can_ use SSL, except that it doesn't have the ability to validate
via certs.  So there'd be another potential use case for this.  I
briefly toyed with trying to find someone to implement cert-based
authentication, but found I had other things more pressing (so the
TODO fell off the end of my list).

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to.  That actually seems sort of quaint now.
        --J.D. Baldwin