On Sat, Jan 30, 2010 at 2:31 PM, Michael Richardson
<..hidden..> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Chris" == Chris Travers <
..hidden..> writes:
Chris> so we can check to see that the user on the cert is the same
Chris> user as the provided credentials. LDAP might be needed to
Chris> make that work cleanly though....
>> LDAP is not necessary or important. Apache will provide a DN,
>> etc. to the script. see
>>
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, and the
>> SSL_CLIENT_* variables.
>>
Chris> the certificate maps to a specific user, short of requiring
Chris> the username in the cert. LDAP might make it easier to avoid
Chris> problems.
LDAP is neutral to the problem. It's just a database with a poor
interface, and an inflexible schema.
We have a much more sophicated database :-)
Don't get me wrong: I think that both LDAP and SSL suck. However, the original concept was that the system which SSL was ported from (X.501) would be based fundamentally on the system LDAP was ported from (X.500), so I think a proper SSL certificate system for a company will probably depend on LDAP.
Really, I wish the old OSI-derived protocols (X.500, X.501, H.323, T.101, etc) would all die and we could get proper replacements steeped in more TCP/IP or UNIX-like ways of working. The OSI concept of networking doesn't match the way things are done in the TCP/IP world and the mismatch causes all manner of nastiness when it comes to security or flexibility of implementation. OTOH, they would be really cool if we were running an OSI stack instead of TCP/IP.....
You can map the certificate by DN (no matter what is there), by just
adding a column to the users table. Or you can be more ssh/spki-like
and just use the sha1 of the public key in the certificate. There are
pros and cons of each method.
True. However, there are some things you can do here via LDAP which are beyond the mechanism you propose. For example, using LDAP and OpenSSL, one could allow new certificates to be issued, check the cert info against the ldap info, and then apply other standard checks. This provides a single-point check to show that the certificate was issued to the correct user and that it is valid.
I am of the opinion that a proper corporate SSL implementation would almost certainly be based on LDAP (and that is probably the only valid use or LDAP out there).
>> But, in the situation where the browser is on the corporate
>> intranet, one hop from the server, or in my personal company
>> case, where the whole thing is "localhost", it wasn't privacy
>> that was the problem.
Chris> Ok, there is a specific issue with 1.3 that I think requires
Chris> SSL on the corporate intranet in order to be effective.
Chris> The basic issue is that we use internal db accounts so we
Chris> have to obtain credentials from the web browser we can use to
Chris> authenticate against the db. Currently the only way
Chris> supported to do this is via HTTP Basic Auth, though Kerberos
Chris> could be supported for intranet environments with a little
Chris> effort.
I'm not sure I understand how you leap from HTTP-Basic-Auth-is-bad
(which I agree, and which SSL "solves"), to needing Kerberos, unless
what you are trying to do is to integrate against ActiveDirectory.
The basic point is that if you use a negotiated auth against a Kerberos KDC, then the concern about password disclosure is more or less gone.
HTTP Digest Authentication is the obvious "better choice", and
recently some people have done some work such that you do not need to
store the passwords in the clear to make digest authentication work.
How would this work in the way we are going with 1.3 (where PostgreSQL provides all authentication control and permission enforcement)?
How would one take an HTTP Digest Authentication token and log into the db with it?
Chris> What about a new schema with VIEWs that are in 2nf?
okay... and then dump that?
That could be dumped independently or audited live.
>> This is as much about producing good audit records as it is to
>> permit recovery from data corruption that may have occured in the
>> past...
>>
>> Has anyone considered having an ledgersmb mini-conference either
>> independently, or as a summit of another
>> conference... e.g. PGcon, OLS, onlinux, OScon, ???
Chris> Not yet. Maybe we will get there though :-) Efforts in
Chris> helping with such things is appreciated.
Next email.
Great.
Best Wishes,
Chris Travers