PKI/SSL Client/Server Certificate Authentication

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxxx'
    -> AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
       O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@xxxxxxxxxxx'
    -> 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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux