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