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
