On 8/17/2010 6:02 PM, Anders Kaseorg wrote:
On Wed, 2010-08-11 at 14:23 -0400, Shawn Green (MySQL) wrote:
On 8/9/2010 5:27 PM, Yves Goergen wrote:
What's that supposed to mean? If there's no way to force the connection
into SSL, it is entirely useless. Anyone on the wire could simply
pretend that the server doesn't support SSL and so deny the encryption
and the client wouldn't even care...
If you don't want to require SSL on the local connections then don't
set the flag on the @localhost account.
If you want the SSL required on the other connections, then set it on
the @'...' version of the account that the remote users login through.
Excuse me, but isn’t Yves exactly right here?
None of the client-side options (I tried --ssl, --ssl-ca=…,
--ssl-verify-server-cert, --ssl-key=…, --ssl-cipher=…) can currently be
used to force an SSL connection to be used. And requiring SSL from the
server side does nothing to stop man-in-the-middle attacks.
(Suppose Bob the SQL server grants some privileges to Alice the user
with SSL required. Now Alice can log in with her password over SSL and
gets denied over non-SSL. Great.
But now Mallory comes along and intercepts a connection from Alice
intended for Bob. Even if Bob would have claimed that he requires SSL,
nothing stops Mallory from claiming that she doesn’t require SSL.
Because Alice cannot force the use of SSL from the client side, Alice
will make a successful unencrypted connection to Mallory. Then Mallory
can accept the connection, ignoring Alice’s authentication, and steal
Alice’s data; or Mallory can make a separate SSL connection to Bob,
forward Alice’s authentication over it, then take over and issue evil
commands to Bob.)
This same issue was reported back in 2004 and ignored:
http://bugs.mysql.com/bug.php?id=3138
I think this is a serious security problem that demands more attention
than dismissal as documented behavior. To solve it, there needs to be a
way to force the use of SSL from the client side.
Anders
If the server specifies REQUIRES SSL then that client cannot connect
without going through the full SSL validation process. This means that
Mallory would need to present the same security credentials that Alice
has in order to qualify as a secure user (the same certs, same password,
login from the correct host, etc).
Your redirect has pointed out to me what I missed in Yves's first post.
In order for the client to require an SSL connection, you have to
designate a certificate for it to use for the connection.
From the same page but a few lines above the line he quoted
##
This option is not sufficient in itself to cause an SSL connection to be
used. You must also specify the --ssl-ca option, and possibly the
--ssl-cert and --ssl-key options.
##
So you can see that using just the --ssl option by itself is not
specific enough to designate which certificate a client is designated to
use. You can specify these options either on the command line or in the
configuration file used by the client (put them in the [mysql] section).
In your simulated MITM attack, if Alice was using the specific --ssl-*
options on her connection attempt, then Mallory would need to hold the
server-side equivalents in order to pose as the server. Since the
likelihood of this is small (except in the case of a physical hack of
the server's cert files which no amount of digital manipulation can
really avoid) then Mallory would be unable to pose as Bob and the
intercept would fail.
Does this help close the security hole you perceived in our SSL
implementation?
--
Shawn Green
MySQL Principal Technical Support Engineer
Oracle USA, Inc.
Office: Blountville, TN
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
