David Schwartz wrote:
Edward Diener wrote:
Perhaps your seeing this shows why I was at least nominally concerned
about the MySQL client having its own public key-private key
certificates. I have tried to find out what actual use the client's
public key-private key has in MySQL, from either the client or the
server's point of view, but to no avail since no one involved with MySQL
answers questions about SSL and the documentation that comes with MySQL
does not explain the use MySQL may have for the client certs.
The ideal solution would be for you to issue each customer their own X.509
certificate signed by your own CA. You can then identify each customer just
by certificate. This is how, I think, it was all intended to work. Using
things the way they are intended to work means that you don't have any
unique security issues, which is good.
This would be ideal if someone broke into the database to do disruptive
things. Then I imagine it might be possible, via database logs, to
determine who that person might be based on the individual client certs.
I think this is what you mean by your second sentence above.
A more practical solution might be to just give every client the exact same
certificate, public key, and 'private' key. Make no attempt to keep this a
secret. Do not rely on it for anything. Just grant privileges by
username/password, not by X.509 certificate.
This is what we are doing now. Admittedly it is a little less safe than
the ideal solution above, since a disruptive hacker need only obtain the
one common certificate, public key, private key in order to try to
compromise the database if he could figure out the username/password.
There are two potential risks with this approach:
1) You need someone to confirm that having a client use a known-compromised
private key to authenticate over SSL is no worse than the client using no
key at all. It seems to me like you'd almost have to try to make this a
problem, but who knows -- maybe it's never been thought about.
Whether a client private key is used or no client key at all, there is
still the issue of figuring out the username/password.
2) You need someone to confirm that MySQL doesn't specifically have some odd
issue with this non-standard setup.
I have to test out whether I can pass just the CA cert as an SSL option
to the connection object, and have this make an SSL connection if just
the REQUIRE SSL option of the GRANT statement is used.
Alternatively, you can hack your own MySQL code to not require or request
client authentication. To a lesser extent, you still have problem '2'.
See just above.
You could hack just your MySQL server not to request client authentication.
Give the client's some garbage key/cert (just because the client library
insists), but the server won't request it, so I don't think they'll use it
at all. You can leave the MySQL client libraries alone.
Granted, but hacking MySQL server is not my idea of fun programming <g>.
You could also put a proxy in front of your MySQL server. The proxy won't
request any client authentication on the customer-facing SSL connections.
This also seems like much work.
Thanks for the suggestions.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
