MySQL Bugs: #35895: Client on vista cannot connect using encryption

Bug #35895	Client on vista cannot connect using encryption
Submitted:	8 Apr 2008 9:55	Modified:	30 Jun 2009 21:58
Reporter:	Lars Ole Avery Simonsen	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	Connector / NET	Severity:	S1 (Critical)
Version:	5.1.5.0	OS:	Windows (vista)
Assigned to:	Vladislav Vaintroub	CPU Architecture:	Any
Tags:	encryption, vista

Description:

Attempts to open a connection cause application to hang on windows vista. I suspect this is related to my using 'encrypt=true' in the connection string (since this is the only thing I can think of that separates my use of the connector from 100% mainstream use on a standard vista installation). The user in question is configured on the server to require ssl.

I have tried several versions of MySql.Data.dll with identical results.

Server runs on ubuntu machine (standard LAMP)
MySql server version: 5.0.11

On windows XP the exact same code runs without a hitch.

How to repeat:
See description.

Hi Lars and thanks for your report.

Please attach small but complete test case that will help me reproduce reported problem.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Not sure what you mean by complete test case reproducing the problem since that would involve a MySql server installation among other things.

The code that creates the troublesome connection is as follows:
        
public static MySqlConnection prepareRemoteConnection()
{
  SuiteConf conf = SuiteConf.Instance;
  string connectString = String.Format("server={0};user id={1};password={2};pooling=false;connection timeout={3}{4}",
    conf.TestDataServerAddress,
    conf.TestDataServerUsername,
    conf.TestDataServerPass,
    conf.TestDataServerTimeout,
    conf.UseEncryption ? ";encrypt=true" : "");
  MySqlConnection connection = new MySqlConnection(connectString);
  connection.Open();
  return connection;
}

It produces a connection string like the following:

"server=some_url;user id=some_user;password=some_pass;pooling=false;connection timeout=6;encrypt=true"

where sensitive information has been replaced by appropriately named placeholders.

As stated previously, the server has been set up so some_user is flagged with require-ssl. These are all things that work beautifully under windows xp. Please let me know what other information you need to get to the bottom of this. Thank you for looking into it!

Lars, I was on vacation so my work was delayed. Looking into this problem.

I am also having this problem.  It works fine on XP and 2003, but fails on Vista and 2008.  It will either hang or throw an exception: 
"System.IO.IOException: Authentication failed because the remote party has closed the transport stream."

Stack trace

Attachment: stacktrace.txt (text/plain), 1.27 KiB.

It appears that Vista supports some additional SSL ciphers or supports them differently in a way that isn't working.

Discovered a simple workaround: force the mysql server to support only RC4-SHA (This seems to be what XP uses normally by choice. Debug the connector in XP and check the properties on a working SslStream).

Add this to my.cnf:
ssl-cipher=RC4-SHA

I tried the suggested workaround and it does appear to be helping in that the application no longer crashes or hangs on vista. A new problem is that with the workaround, my connection attempts are all refused with "Access denied for user 'some_user'@'some_ip' (using password: YES)" - both from xp and vista. At least I now have consistent behavior :)

The working ssl stream on XP (without server workaround) has the following properties:
CipherAlgorithm = Rc4
HashAlgorithm = Sha1
KeyExchangeAlgorithm = RsaSign
KeyExchangeStrength = 2048
CipherStrength = 128
HashStrength = 160
RemoteCertificate = X509Certificate
SslProtocol = Tls

So I take it that means the workaround *should* work. My problem might have to do with the certificate used on the server or some such. If anybody has a clue for me then I'm most interested :)

Thanks for the help!

In case it wasn't entirely clear from my last post (and it wasn't), I am still unable to workaround this bug and so I think its severity should remain critical. Please let me know if any more information is needed to work this out.

Bug report is accurate and that is exactly how it happens. But, the true reason as to *why* this error happens is that MySQL server *crashes* on host! I need more time to investigate this.

Looking at crash stack trace, it's probably YaSSL related.

Using WinXP host with MySQL server 5.0.68PB10 I got crash once thus I filed Bug#39178.

Turning the story around, XP client connecting to Vistax64 MySQL server:
  Latest 5.1 community on Vistax64 didn't crash.
  Latest 5.0 community server on Vistax64 - also no crash (however I do get errors similar to reported ones).

"encrypt=true" appears to be working *only* on localhost; working from remote client one is bound either to crash server or to get "Access denied" or something...

Verified in that:
  o) There is no proper support for SSL.
  o) Although SSL support appears to work on localhost I don't know why nor how.

As there are no plans to fix this in c/NET soon I ask of you to be patient.

I'm having this problem as well, and in fact it is worse (for me at least) than described here.  If I enable SSL on the server, even if I do not require SSL for login, no Vista client can connect (even without SSL).  My code sample is here:

  MessageBox(NULL, "Connecting", "Note", MB_OK);

  st_mysql* handle = mysql_init(NULL);

  if (!mysql_real_connect(handle, server, user, pw, db, 0, NULL, CLIENT_MULTI_RESULTS))
    MessageBox(NULL, mysql_error(handle), "Note", MB_OK);

  else
    MessageBox(NULL, "Connected", "Note", MB_OK);

  mysql_close(handle);

Has there been any movement on this bug since September?  Any ETA?

Same Problem,
one small problem: When using ssl-cipher=RC4-SHA at the server
it works but the connections are no more encrypted!
tested with wireshark and microsoft network monitor. Clear Text.

Could neither reproduce server crash nor "access denied" from remote host nor unencrypted data sent over the wire with proper configuration.

The clue to "access denied" might be a missing "grant". The clue to unencrypted data is that the server was not started with SSL support. "encrypt=true" silently ignored it and worked without encryption. Currently, code in the trunk deprecates "encrypt" and has a better option "sslMode" that allows for more fine-grained control on how client handles unencrypted data from server (and invalid certificates etc)