Hi, thanks for your report and detailed research. Please see below...

On 6/2/16 8:24 AM, Kordován Szabolcs wrote:

Hi,

I had a problem with secure connection to sql server.
I use mysqli extension, I configured server['ssl'] = true. I have a user
'szabolcs' in sql who needs ssl.
First I received 'mysqli_real_connect(): (HY000/1045): Access denied for
user 'szabolcs'@'localhost' (using password: YES)'.
That was why PMA doesn't use MYSQLI_CLIENT_SSL. I should add it to
$client_flags.

As far as I'm aware, PHP doesn't need MYSQLI_CLIENT_SSL when calling
mysql_ssl_set() before mysqli_real_connect(). The current documentation
doesn't reference this scenario at all, but previous versions did state
that MYSQLI_CLIENT_SSL was not required here (see, for example, [1]).

After this I got the following error:'mysqli_query(): SSL operation
failed with code 1. OpenSSL Error messages: error:0607A082:digital
envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length
error:0607A082:digital envelope
routines:EVP_CIPHER_CTX_set_key_length:invalid key length'.

PMA uses openssel functions to encrypt values in cookie if openssl
functions exist, other case PMA uses Crypt\AES. With Crypt\AES PMA works
fine.
I don't know the exact source of this problem. I think openssl functions
have a bug.

There was some incompatibility between MySQL and OpenSSL (see [2]),
however the error reported was a bit different.

Because the mysqli connection with ssl is successful After connection
in common.inc.php $auth_plugin->storeUserCredentials() is called. This
function stores the username and password and other parameters into
cookie. To encrypt:
openssl_encrypt(
$data,
'AES-128-CBC',
$secret,
0,
$this->_cookie_iv
);
I think the problem is that openssl_encrypt change the cipher to
AES-128-CBC globally. It means the cipher of mysqli connection is also
modified. This is why mysqli_query failed after encryption.

Interesting.

Here is my solution:

diff -ruN original/libraries/dbi/DBIMysqli.php
working/libraries/dbi/DBIMysqli.php
--- original/libraries/dbi/DBIMysqli.php 2016-05-25
19:07:44.000000000 +0200
+++ working/libraries/dbi/DBIMysqli.php 2016-05-26 15:55:49.000000000 +0200
@@ -152,6 +152,7 @@

     /* Optionally enable SSL */
     if ($cfg['Server']['ssl']) {

•       $client_flags |= MYSQLI_CLIENT_SSL;
       mysqli_ssl_set(
           $link,
           $cfg['Server']['ssl_key'],
  

  diff -ruN original/libraries/plugins/auth/AuthenticationCookie.php
  working/libraries/plugins/auth/AuthenticationCookie.php
  --- original/libraries/plugins/auth/AuthenticationCookie.php
  2016-05-25 19:07:44.000000000 +0200
  +++ working/libraries/plugins/auth/AuthenticationCookie.php
  2016-05-26 15:56:27.000000000 +0200
  @@ -661,6 +661,7 @@
  */
  public static function useOpenSSL()
  {

•   return false;
  

This also makes me think about some sort of OpenSSL problem.

     return (
         function_exists('openssl_encrypt')
         && function_exists('openssl_decrypt')

diff -ruN original/RELEASE-DATE-4.6.1 working/RELEASE-DATE-4.6.1
--- original/RELEASE-DATE-4.6.1 1970-01-01 01:00:00.000000000 +0100
+++ working/RELEASE-DATE-4.6.1 2016-05-02 17:24:00.000000000 +0200
@@ -0,0 +1 @@
+Mon May 2 21:23:35 UTC 2016

Regards,
Szabolcs

---

Developers mailing list
Developers@phpmyadmin.net
https://lists.phpmyadmin.net/mailman/listinfo/developers

From phpinfo() could you please provide your OpenSSL version? Mine is
1.0.1k.

From the main page of phpMyAdmin, could you please provide "Database
client version", "PHP extension", and "PHP version" information? (Mine
is libmysql - 5.5.49 / mysqli curl mbstring / 5.6.20-0+deb8u1 )

Regards,
Isaac

1 -
http://board.phpbuilder.com/showthread.php?10383611-Connecting-PHP-and-MYSQL-using-SSL&s=f12add2a512f61180c75efc107856c04&p=10998575&viewfull=1#post10998575
2 - https://bugs.mysql.com/bug.php?id=64870

Hi,

Sorry for delay.
I forgot the versions:
Database server

Server: fone2 (127.0.0.1 via TCP/IP)
Server type: MySQL
Server version: 5.7.12-0ubuntu1 - (Ubuntu)
Protocol version: 10
User: szabolcs@localhost
Server charset: UTF-8 Unicode (utf8)
Web server

Apache/2.4.18 (Ubuntu)
Database client version: libmysql - mysqlnd 5.0.12-dev - 20150407 - $Id: f59eb767fe17a6679589b5c076d9fa88d3d4eac0 $
PHP extension: mysqli curl mbstring
PHP version: 7.0.4-7ubuntu2.1

openssl

OpenSSL support enabled
OpenSSL Library Version OpenSSL 1.0.2g-fips 1 Mar 2016
OpenSSL Header Version OpenSSL 1.0.2g-fips 1 Mar 2016
Openssl default config /usr/lib/ssl/openssl.cnf

If you have to authenticate with certification you use mysqli_ssl_set(). In this case you need private key and certification. But if you want only a secure communication (like https) you don't need these. Only need mysqli_client_ssl flag to use ssl.
From mysql log:
2016-06-03T06:02:02.098148Z11604 Connect szabolcs@xxx.xxx.xxx.xxx on using SSL/TLS

Regards,
Szabolcs

I really wonder how changing useOpenSSL can help in this case. When it's false, we use phpseclib, which prefers openssl as well, so you end up using same library, just through phpseclib and not directly...

I've added the MYSQLI_CLIENT_SSL flag. It indeed seems to be needed in some PHP versions. Unfortunately the handling of SSL connection in MySQL heavily depends on how PHP is compiled and what version is that and there seems to be case where the flag is needed. Anyway it doesn't cause any harm, so let's keep it added.

Reportedly fixed by above commit:

Dne 9.6.2016 v 14:19 Kordován Szabolcs napsal(a):

Hello,

I tested this dev version and it works fine.

I'm actually still experiencing this issue:

OpenSSL Error messages: error:0607A082:digital
envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length
error:0607A082:digital envelope
routines:EVP_CIPHER_CTX_set_key_length:invalid key length'.

I get this with an AES-256-CBC key sent from MySQL Server. I use an intermediate and root CA combined in a PEM file. 2048 RSA is used for my server cert and key.

Server type: MySQL
Server version: 5.7.14 - MySQL Community Server (GPL)
Protocol version: 10
User:
Server charset: UTF-8 Unicode (utf8)
Apache/2.4.23 (Win64) PHP/5.6.25
Database client version: libmysql - mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $
PHP extension: mysqliDocumentation curlDocumentation mbstringDocumentation
PHP version: 5.6.25
MyPHPAdmin Version information: 4.6.4

C:\ProgramFiles\wamp\3.0.6_x64\apps\phpmyadmin4.6.4\libraries\plugins\auth\AuthenticationCookie.php

public static function useOpenSSL()
{   
+ return false;
    return (
        function_exists('openssl_encrypt')
        && function_exists('openssl_decrypt')
        && function_exists('openssl_random_pseudo_bytes')
    );
}

By not using OpenSSL in AuthenticationCookie.php, phpseclib is used. This is the only way I do not get the invalid key length error.

.\phpmyadmin4.6.4\libraries\plugins\auth\AuthenticationCookie.php

    if (self::useOpenSSL()) {
        $result = openssl_encrypt(
            $data,
            'AES-128-CBC',
            $secret,
            0,
            $iv
        );
    } else {
        $cipher = new Crypt\AES(Crypt\Base::MODE_CBC);
        $cipher->setIV($iv);
        $cipher->setKey($aes_secret);
        $result = base64_encode($cipher->encrypt($data));
    }

Looking in phpseclib, openssl is used first if available, but what is also important is the key length is set based on the AES key size (note that key size is in bytes here, so 32 is 256 bit)
\phpmyadmin4.6.4\libraries\phpseclib\Crypt\AES.php

/**
 * Sets the key.
 *
 * Rijndael supports five different key lengths, AES only supports three.
 *
 * @see \phpseclib\Crypt\Rijndael:setKey()
 * @see setKeyLength()
 * @access public
 * @param string $key
 */
function setKey($key)
{
    parent::setKey($key);

    if (!$this->explicit_key_length) {
        $length = strlen($key);
        switch (true) {
            case $length <= 16:
                $this->key_length = 16;
                break;
            case $length <= 24:
                $this->key_length = 24;
                break;
            default:
                $this->key_length = 32;
        }
        $this->_setEngine();
    }
}

key_length is later used in
\phpmyadmin4.6.4\libraries\phpseclib\Crypt\Rijndael.php

/**
 * Test for engine validity
 *
 * This is mainly just a wrapper to set things up for \phpseclib\Crypt\Base::isValidEngine()
 *
 * @see \phpseclib\Crypt\Base::__construct()
 * @param int $engine
 * @access public
 * @return bool
 */
function isValidEngine($engine)
{
    switch ($engine) {
        case self::ENGINE_OPENSSL:
            if ($this->block_size != 16) {
                return false;
            }
            $this->cipher_name_openssl_ecb = 'aes-' . ($this->key_length << 3) . '-ecb';
            $this->cipher_name_openssl = 'aes-' . ($this->key_length << 3) . '-' . $this->_openssl_translate_mode();
            break;
        case self::ENGINE_MCRYPT:
            $this->cipher_name_mcrypt = 'rijndael-' . ($this->block_size << 3);
            if ($this->key_length % 8) { // is it a 160/224-bit key?
                // mcrypt is not usable for them, only for 128/192/256-bit keys
                return false;
            }
    }

    return parent::isValidEngine($engine);
}

So the code should be adjusted to dynamically determine the key length (instead of just guessing AES-128-CBC) and maybe even scrap the custom useOpenSSL()altogether, phpseclib already seems to handle it.

PS. I don't know PHP that well, so if you have to keep the useOpenSSL() for a specific reason then please explain.

My fix for now is to return false; in useOpenSSL()

The custom useOpenSSL logic is there to make the dependency on phpseclib optional (this was requested especially by Linux distributors).

Anyway this looks like something is seriously broken in the PHP openssl or MySQL/ssl API as I really don't see why encrypting using some specific parameters should change settings used by MySQL driver.

Okay, in the end it is bug in our code, but hidden by PHP API weirdness:

• we do use wrong key with openssl_encrypt
• however openssl_encrypt works just fine with that
• it only sets internal openssl error, which we do not read
• the error is later read by mysqlnd driver

Thanks for the prompt fix!

I realize that mysqlnd should stay connected now, but won't I still be seeing the key_length error displayed in the UI all the time? Should we be using the same key lengths for the cookie encryption and the mysql connection to avoid these errors from consistently appearing?

No, because I've fixed wrong key usage as well (in 30cd5fc). The problem is not in using different keys for different operations, the problem is that errors persist in the PHP's openssl layer - we did use wrong key length for our chosen cipher and it did set error message, which we did not pick up, but was later picked up by the mysqlnd driver.

Okay, sounds all fixed :) Thanks.

Hi, I come to this issue to report this fix is work for me ... and request another fix

My case is try to connect to AWS RDS with SSL by mysqli
First for all, AWS RDS only require ca file to connect
so $cfg['Server'][$i]['ssl_key'] is not require

same problem/error message was reported at here(the mailing list), #11553 and #12146
Just let me state again at here
I also got the 2 error in below when I set

$cfg['Server'][$i]['ssl'] = true;
$cfg['Server'][$i]['ssl_ca'] = '/rds-combined-ca-bundle.pem';

After login by correct username and password

Error
SQL query: Edit
SELECT * FROM information_schema.CHARACTER_SETS
MySQL said:
#2006 - MySQL server has gone away

when I go back to login page, this message come up

'mysqli_query(): SSL operation failed with code 1. OpenSSL Error messages: error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length'.

before apply this fix, 2 step to "quick fix" my problem

1. use check ssl_ca instead of check ssl_key, because I did not have ssl_key
2. add return false at useOpenSSL

libraries/dbi/DBIMysqli.php

public function connect(
...
- if (!empty($server['ssl_key'])) {
+ if (!empty($server['ssl_ca'])) {
	mysqli_ssl_set(
		$link,
		$server['ssl_key'],
		$server['ssl_cert'],
		$server['ssl_ca'],

libraries/plugins/auth/AuthenticationCookie.php

public static function useOpenSSL()
     {
+       return false;
         return (

And now, this fix is fixed by a correct way on my step 2 (different key to use on openssl)
but still have step 1, would phpmyadmin also accept only have ['ssl_ca'] to enable mysqli_ssl_set ?
something like
if (!empty($server['ssl_key']) || !empty($server['ssl_ca'])) {

Thank you very much

I'm wondering if you actually got the latest code that has the fix, because I don't think 4.6.6 is released yet, unless you got their latest dev code from GitHub. The return false shouldn't be needed after that fix.

That being said you bring an excellent point on mysqli_ssl_set(). It will still connect via SSL with just setting ['ssl_ca'] because $client_flags |= MYSQLI_CLIENT_SSL; is set. But it won't verify Amazons Public Certificate with the CA you provided, because mysqli_ssl_set() is not used.

if ($cfg['Server']['ssl']) {
            $client_flags |= MYSQLI_CLIENT_SSL;
            if (!empty($cfg['Server']['ssl_key'])) {
                mysqli_ssl_set(
                    $link,
                    $cfg['Server']['ssl_key'],
                    $cfg['Server']['ssl_cert'],
                    $cfg['Server']['ssl_ca'],
                    $cfg['Server']['ssl_ca_path'],
                    $cfg['Server']['ssl_ciphers']
                );
            }

SSL verification of the CA should not just depend on the client having a private key, maybe the client just wants to verify the server.

This is a security flaw in DBIMysqli and definitely should be fixed. A new bug should be opened for it, unless the devs are fine with fixing it in this bug.

Certainly it's another bug in the code. I'd really prefer if new issues got reported separately as this issue is covering more and more bugs...

Also I don't think it's security flaw - it will use only system built in certification authorities to verify the certificate and it will refuse to connect if it fails to do so.