OnGres SCRAM silent channel-binding authentication downgrade via unsupported certificate algorithms
A flaw in com.ongres.scram:scram-client allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from SCRAM-SHA-256-PLUS (with channel binding) to standard SCRAM-SHA-256 (without channel binding), bypassing strict client-side enforcement policies.
This occurs due to a two-part failure in TlsServerEndpoint when a server presents an X.509 certificate using a modern signature algorithm that lacks traditional WITH naming structures (such as Ed25519 or post-quantum algorithms):
NoSuchAlgorithmException, and silently returns an empty byte array via the deprecated getChannelBindingData()` API.This issue only impacts deployments where the downstream application layer explicitly enforces strict channel binding enforcement (e.g., channelBinding=require in pgJDBC).
Drivers operating under a "prefer" or "allow" policy (used by default) are structurally insulated from an unhandled exception since a fallback to standard SCRAM is within their expected configuration.
Update your project configuration to pull in version 3.3 or later of the SCRAM library, which introduces strict exception propagation and explicit policy controls.
If you are interacting with the ScramClient builder API directly (e.g., writing a custom driver or database extension):
TlsServerEndpoint.getChannelBindingData(). Transition immediately to TlsServerEndpoint.getChannelBindingHash(), which correctly propagates NoSuchAlgorithmException up the stack.ChannelBindingPolicy API during client construction. Do not rely on implicit parameter presence to dictate your security boundaries.ScramClient client = ScramClient.builder()
.advertisedMechanisms(serverMechanisms)
.username(user)
.password(pass)
// Explicitly enforce strict boundaries if needed.
.channelBindingPolicy(ChannelBindingPolicy.REQUIRE)
.channelBinding(TlsServerEndpoint.TLS_SERVER_END_POINT, certHash)
.build();