When SSL/TLS is enabled but no CA / server certificate is provided, the
connector verifies the server's identity using fingerprint validation. The
check is effective, the connection is ultimately rejected when it fails,
but it happens after the authentication exchange. As a result, the
credentials are sent before validation occurs, so an active man-in-the-middle
who presents their own certificate receives the password in the handshake
before the connection is aborted.
Impact
The credentials are transmitted to the peer before the server's identity is
validated. An on-path attacker (MitM) presenting any certificate can capture
the account password, even though the connection then fails the fingerprint
check and is closed. The disclosed credentials can subsequently be used to
authenticate directly against the server.
Attacker requirement: active man-in-the-middle position on the network path
Affected configuration: SSL/TLS enabled without a CA / server certificate
Affected versions
< 3.2.4
3.3.0 – 3.3.2
3.4.0 – 3.4.5
3.5.0 – 3.5.2
Patches
Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later)
on your branch.
Workarounds
Until you can upgrade, configure certificate verification explicitly, provide
the server/CA certificate and use a verifying SSL mode (e.g. VERIFY_CA /
VERIFY_FULL).