Project

General

Profile

Issue #2771

Mysql plugin stopped working for the newer versions.

Added by Yasin Bahtiyar 5 months ago. Updated 5 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Affected version:
5.7.0
Resolution:

Description

Hi,

I am running strongswan instance to connect with mobile clients. Had a working configuration with 5.6.3dr1 mysql and eap-mschap was operational flawlessly.
Even though I have the same configuration with 5.6.3 or 5.7.0
It results with failed mschapv2

15[IKE] initiating EAP_MSCHAPV2 method (id 0xE9)
15[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
15[NET] sending packet: from 172.19.0.2[4500] to 172.19.0.3[4500] (112 bytes)
14[NET] received packet: from 172.19.0.3[4500] to 172.19.0.2[4500] (160 bytes)
14[ENC] parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
14[IKE] EAP-MS-CHAPv2 verification failed, retry (1)
14[ENC] generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
14[NET] sending packet: from 172.19.0.2[4500] to 172.19.0.3[4500] (128 bytes)
06[NET] received packet: from 172.19.0.3[4500] to 172.19.0.2[4500] (80 bytes)
06[ENC] parsed INFORMATIONAL request 4 [ N(AUTH_FAILED) ]
06[ENC] generating INFORMATIONAL response 4 [ N(AUTH_FAILED) ]
06[NET] sending packet: from 172.19.0.2[4500] to 172.19.0.3[4500] (80 bytes)
06[IKE] IKE_SA ikev2-mschapv2-apple[2] state change: CONNECTING => DESTROYING

Here is the working ipsec.conf and ipsec.secrets file os only containing : RSA privkey.pem. I am able to get this all working with correct mysql db identities & shared secrets. But not in newer versions.



config setup
    uniqueids=never
    charondebug = "ike 2, cfg 2" 

conn %default
    dpdaction=clear
    dpddelay=600s

    keyexchange=ikev2
    auto=add
    rekey=no
    reauth=no
    fragmentation=yes
    compress=yes

    leftcert=fullchain.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0

    ike=aes256gcm16-aes192gcm16-prfsha256-ecp256-ecp521,aes256-sha256-modp3072,chacha20poly1305-prfsha256-ntru256
    esp=aes256gcm16-aes192gcm16-prfsha256-ecp256-modp3072,aes256-sha256-ecp256-modp3072,chacha20poly1305-ntru256

    eap_identity=%identity
    rightsourceip=10.7.0.0/16
    rightdns=1.1.1.1, 8.8.8.8

conn ikev2-mschapv2
    rightauth=eap-mschapv2

conn ikev2-mschapv2-apple
    rightauth=eap-mschapv2
    leftid=mysite.org

History

#1 Updated by Tobias Brunner 5 months ago

  • Status changed from New to Feedback

I'm not sure this has anything to do with the mysql, sql or eap-mschapv2 plugin (there have been no changes to any of them since 5.6.3dr2). And if no password was found at all you'd get a different error message. Can you confirm that going back to 5.6.3dr2 fixes the problem?

The error message indicates that the two peers disagree on the calculated NT-Response. So this could also be a client issue. Did that change? Or was the password entered incorrectly?

#2 Updated by Yasin Bahtiyar 5 months ago

I used to build from https://download.strongswan.org/strongswan-5.6.3dr1.tar.bz2 which is not distributed any longer. I built 5.6.3dr1 from github tarball https://github.com/strongswan/strongswan/archive/5.6.3dr1.tar.gz following the hacking instructions and that build also failed mschap as in 5.7.0.

I am still able to get a working tunnel with the original build i have from tar.bz2 archive but I am unable to get it working with the new builds. The client is the same client for all of the working and failing versions above. and all codebases are configured with such options.

   ./configure --enable-silent-rules --prefix=/usr \
            --sysconfdir=/etc \
            --libexecdir=/usr/lib \
            --with-ipsecdir=/usr/lib/strongswan \
            --enable-aesni \
            --enable-ccm \
            --enable-chapoly \
            --enable-cmd \
            --enable-curl \
            --enable-dhcp \
            --enable-eap-identity \
            --enable-eap-mschapv2 \
            --enable-farp \
            --enable-files \
            --enable-gcm \
            --enable-md4 \
            --enable-newhope \
            --enable-ntru \
            --enable-sha3 \
            --enable-shared \
            --enable-sql \
            --enable-mysql \
            --enable-gmp \
            --enable-rdrand \
            --disable-aes \
            --disable-ikev1 \
            --disable-md5 \
            --disable-rc2 \
            --disable-sha1 \
            --disable-static && \

#3 Updated by Tobias Brunner 5 months ago

that build also failed mschap as in 5.7.0.

As expected.

I am still able to get a working tunnel with the original build i have from tar.bz2 archive

Do you still have that old source dir? Then compare it to that of the newly downloaded code for 5.6.3dr1. Except for newly generated files (keywords, parsers etc.) there shouldn't be any differences.

but I am unable to get it working with the new builds.

Which doesn't really make sense, unless you somehow patched the code that's working.

#4 Updated by Yasin Bahtiyar 5 months ago

I managed to get hold of of the 5.6.3dr1 archive in my build artefacts and tried to build it. And that one too failed. Then I noticed I am running my build pipeline on top of alpine:edge then quickly realised maybe mysql client libs are not behaving well. Managed to get 5.7.0 successfully establish a connection on alpine:3.7 with mariadb-client-libs. On 3.8 and edge mariadb-connector-c-3.0.3-r2 -> mariadb-connector-c-3.0.5-r0 version bump seems to lead to the failure discussed earlier. Apologies for taking your time. But mystery is solved for now at least for alpine 3.7. Thanks a lot!

#5 Updated by Tobias Brunner 5 months ago

Managed to get 5.7.0 successfully establish a connection on alpine:3.7 with mariadb-client-libs. On 3.8 and edge mariadb-connector-c-3.0.3-r2 -> mariadb-connector-c-3.0.5-r0 version bump seems to lead to the failure discussed earlier.

Thanks for the update. I wonder what changed in that library to cause this effect, and whether it's a bug or a feature change. It seems that either the wrong or corrupted data is returned from a query, which isn't good, if just an external library is updated.

#6 Updated by Noel Kuntze about 1 month ago

That's a bug in the library, I stumbled upon that too. I'll work towards getting that fixed in a couple of days.

#7 Updated by Yasin Bahtiyar 7 days ago

Trying to debug this and see what might be the root cause. Not sure if this is a mariadb-connector-c problem anymore.
eap_mschapv2.c:1125 is failing on my newer builds.

(gdb) x/24xb res->response.nt_response
0x55638519e242: 0xc8    0x3f    0x21    0x5f    0xad    0xe8    0xe9    0x92
0x55638519e24a: 0x48    0x3e    0xcf    0xc9    0x5f    0x58    0xed    0xb0
0x55638519e252: 0xbb    0xdc    0x67    0x2a    0x95    0x62    0xb4    0x72
(gdb) x/24xb this->nt_response.ptr
0x5563851a5d00: 0x3f    0x51    0x67    0x5d    0x5f    0x49    0x36    0xee
0x5563851a5d08: 0x1e    0x6e    0x42    0x42    0xc1    0x18    0xe3    0x88
0x5563851a5d10: 0x40    0x13    0x1d    0x56    0x0d    0xce    0x27    0xc2

Where in the older builds `memeq_const` returns true

(gdb) x/24b res->response.nt_response
0x56080f7deb82: 0x85    0x77    0xd4    0x6c    0x6a    0xb3    0x60    0x80
0x56080f7deb8a: 0x4d    0x09    0x97    0x35    0xa1    0x6d    0xf6    0x01
0x56080f7deb92: 0xe2    0x27    0xcb    0xb2    0x4c    0xd6    0xfa    0x3f
(gdb) x/24b this->nt_response.ptr
0x56080f804940: 0x85    0x77    0xd4    0x6c    0x6a    0xb3    0x60    0x80
0x56080f804948: 0x4d    0x09    0x97    0x35    0xa1    0x6d    0xf6    0x01
0x56080f804950: 0xe2    0x27    0xcb    0xb2    0x4c    0xd6    0xfa    0x3f

Do you have any recommendations on how to debug this further?

#8 Updated by Noel Kuntze 7 days ago

Continue this ticket on the mariadb bug tracker: MDEV-17116
It's closed right now because I didn't respond, but I'm sure you can reopen it.

#9 Updated by Yasin Bahtiyar 7 days ago

I had seen the issues you reported there earlier but not sure if I would be able to follow them up on my own. What I can probably try to do is build mariadb-connector-c from source and try to debug the library perhaps if that is the problem. Not sure how complex that would be but still. On the othar hand I am having hard time how is the

"SELECT s.type, s.data FROM shared_secrets AS s " 
                "JOIN shared_secret_identity AS sm ON s.id = sm.shared_secret " 
                "JOIN identities AS m ON sm.identity = m.id " 
                "JOIN shared_secret_identity AS so ON s.id = so.shared_secret " 
                "JOIN identities AS o ON so.identity = o.id " 
                "WHERE m.type = ? AND m.data = ? AND o.type = ? AND o.data = ? " 
                "AND (? OR s.type = ?)" 

query results are utilized by eap_mschapv2 module. Would appreciate some high level explanation. How could I enumerate on the shared_enumerator_t within gdb? Would really appreciated if I could inspect what data is coming from mysql perhaps in this way.

#10 Updated by Noel Kuntze 7 days ago

The problem is really not with how strongSwan uses the mysql lib. The problem is with the mysql lib and/or the server. Follow up on the issue I linked to get the problem solved in a timely manner.

#11 Updated by Yasin Bahtiyar 7 days ago

Yes probably the client libs only. Both old & new client builds are connecting to the same mysql server instance. Thanks

#12 Updated by Yasin Bahtiyar 5 days ago

There was a fix made previously but it looks like the bug was introduced again in mariadb-connector-c 3.0.4.
https://jira.mariadb.org/browse/CONC-390

Also available in: Atom PDF