Inc 456 #146
Open
Inc 456 #146
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ngx.ssl is only available in openresty land, whereas this plugin's CI does not have it enabled/installed to run tests. Also fix a regression where luasec_opts had incorrect parameters.
Setting password_encryption to scram-sha-256 in postgresql.conf will
encrypt the password with SCRAM-SHA-256. The default is md5, which will
encrypt the password with MD5.
If the password was encrypted with SCRAM-SHA-256 in postgres (by
setting password_enc56 in postgresql.conf), then postgres clients can
authenticate to the postgres server by setting the ff the password was
encrypted with SCRAM-SHA-256 in postgres (by setting
password_encryption to scram-sha-256 in postgresql.conf), then postgres
cl ients can authenticate to the postgres server by setting the
authentication method specification to scram-sha-256 in pg_hba.conf.
The problem is that the pgmoon client doesn't support the SCRAM-SHA-256
authentication method. So the postgres server supports SCRAM-SHA-256,
but the client doesn't. If the password is encrypted with SCRAM-SHA-256
(by setting password_encryption to scram-sha-256 in postgresql.conf)
and if the postgres method authentication is set to SCRAM-SHA-256 (by
setting the authentication method specification to scram-sha-256 in
pg_hba.conf) then pgmoon won't be able to authenticate to postgres
because the password will be sent as SCRAM-SHA-256 encrypted and not
MD5 or plaintext (the ones supported by pgmoon).
Here we are implementing the client-side support for SCRAM-SHA-256 as
defined by [3]. Per the postgres docs [2] only SASL is supported as per
the RFC 7677 [3]. So the client implementation should be conformant to
that RFC only, not for the HTTP version of SCRAM-SHA-256 (RFC 7804).
Implementation details:
- Support for channel binding is implemented as per RFC 5929 [4]
* Only 'tls-server-end-point' is implemented because it's the only
channel binding type used by postgres
* Requires LuaSec release >= v1.0 for socket type `luasocket`
* Requires lua-resty-openssl release >= 0.6.10 for socket type `nginx`
- There is no support for authzid since postgres doesn't support it [1]
- Right now we are relying on luaossl to provide all the crypto things
such as HMAC, PBKDF2, SHA-256 hash function, random bytes generation,
etc. It would be nice if in the future we create a compatibility
layer to use both the luaossl and resty-openssl libraries for this
purpose
[1] https://github.com/postgres/postgres/blob/REL_13_1/src/backend/libpq/auth-scram.c#L1011-L1013
[2] https://www.postgresql.org/docs/13/auth-password.html
[3] https://www.rfcreader.com/#rfc7677
[4] https://www.rfcreader.com/#rfc5929
fix(*) bump to 2.2.0, fix homepage/maintainer/url and add tag
with BoringSSL BoringSSL changed the size type of PBKDF2 functions, thus not binary compatible with OpenSSL library. This PR further removes dependency of luaossl in other places to ensure there're no other incompatible with BoringSSL.
The underlying LuaSec SSL library allows for setting the encryption protocol to 'any' [1]. When set as such, the client negotiates the highest encryption protocol available. This `any` protocol version setting is widely in use in the luasec repository [2]. In addition, this change limits the lowest allowable ssl protocol version to a version not less than TLSv1.1. In support of the above, the implementation is two-fold: - add no_sslv2, no_sslv3, and no_tlsv1 LuaSec options similar to what has been done in lua-cassandra [3] - set default LuaSec ssl_protocol to 'any' also similar to what has been done in lua-cassandra [4] [1] - https://github.com/brunoos/luasec/blob/711a98b7605ad87b521ba607024947113bc1f527/CHANGELOG#L101 [2] - https://github.com/brunoos/luasec/search?q=protocol+%3D+%22any%22 [3] - thibaultcha/lua-cassandra@b6dff88 [4] - thibaultcha/lua-cassandra@d742d5c Signed-off-by: Jeremy J. Miller <[email protected]> disable prefer server ciphers Signed-off-by: Jeremy J. Miller <[email protected]>
Postgres tball: Updating luasec options to fit new 1.14 base
ngx.ssl is only available in openresty land, whereas this plugin's CI does not have it enabled/installed to run tests. Also fix a regression where luasec_opts had incorrect parameters. tball: Updating for 1.14 code base
Setting password_encryption to scram-sha-256 in postgresql.conf will
encrypt the password with SCRAM-SHA-256. The default is md5, which will
encrypt the password with MD5.
If the password was encrypted with SCRAM-SHA-256 in postgres (by
setting password_enc56 in postgresql.conf), then postgres clients can
authenticate to the postgres server by setting the ff the password was
encrypted with SCRAM-SHA-256 in postgres (by setting
password_encryption to scram-sha-256 in postgresql.conf), then postgres
cl ients can authenticate to the postgres server by setting the
authentication method specification to scram-sha-256 in pg_hba.conf.
The problem is that the pgmoon client doesn't support the SCRAM-SHA-256
authentication method. So the postgres server supports SCRAM-SHA-256,
but the client doesn't. If the password is encrypted with SCRAM-SHA-256
(by setting password_encryption to scram-sha-256 in postgresql.conf)
and if the postgres method authentication is set to SCRAM-SHA-256 (by
setting the authentication method specification to scram-sha-256 in
pg_hba.conf) then pgmoon won't be able to authenticate to postgres
because the password will be sent as SCRAM-SHA-256 encrypted and not
MD5 or plaintext (the ones supported by pgmoon).
Here we are implementing the client-side support for SCRAM-SHA-256 as
defined by [3]. Per the postgres docs [2] only SASL is supported as per
the RFC 7677 [3]. So the client implementation should be conformant to
that RFC only, not for the HTTP version of SCRAM-SHA-256 (RFC 7804).
Implementation details:
- Support for channel binding is implemented as per RFC 5929 [4]
* Only 'tls-server-end-point' is implemented because it's the only
channel binding type used by postgres
* Requires LuaSec release >= v1.0 for socket type `luasocket`
* Requires lua-resty-openssl release >= 0.6.10 for socket type `nginx`
- There is no support for authzid since postgres doesn't support it [1]
- Right now we are relying on luaossl to provide all the crypto things
such as HMAC, PBKDF2, SHA-256 hash function, random bytes generation,
etc. It would be nice if in the future we create a compatibility
layer to use both the luaossl and resty-openssl libraries for this
purpose
[1] https://github.com/postgres/postgres/blob/REL_13_1/src/backend/libpq/auth-scram.c#L1011-L1013
[2] https://www.postgresql.org/docs/13/auth-password.html
[3] https://www.rfcreader.com/#rfc7677
[4] https://www.rfcreader.com/#rfc5929
tball: updating for 1.14 code base
fix(*) bump to 2.2.0, fix homepage/maintainer/url and add tag tball: Updating for 1.14 code base
with BoringSSL BoringSSL changed the size type of PBKDF2 functions, thus not binary compatible with OpenSSL library. This PR further removes dependency of luaossl in other places to ensure there're no other incompatible with BoringSSL.
The underlying LuaSec SSL library allows for setting the encryption protocol to 'any' [1]. When set as such, the client negotiates the highest encryption protocol available. This `any` protocol version setting is widely in use in the luasec repository [2]. In addition, this change limits the lowest allowable ssl protocol version to a version not less than TLSv1.1. In support of the above, the implementation is two-fold: - add no_sslv2, no_sslv3, and no_tlsv1 LuaSec options similar to what has been done in lua-cassandra [3] - set default LuaSec ssl_protocol to 'any' also similar to what has been done in lua-cassandra [4] [1] - https://github.com/brunoos/luasec/blob/711a98b7605ad87b521ba607024947113bc1f527/CHANGELOG#L101 [2] - https://github.com/brunoos/luasec/search?q=protocol+%3D+%22any%22 [3] - thibaultcha/lua-cassandra@b6dff88 [4] - thibaultcha/lua-cassandra@d742d5c Signed-off-by: Jeremy J. Miller <[email protected]> disable prefer server ciphers Signed-off-by: Jeremy J. Miller <[email protected]> tball: Updating for 1.14 code base
tball: Updating for 1.14 code base
Signed-off-by: Tyler Ball <[email protected]>
Signed-off-by: Tyler Ball <[email protected]>
We should use the author's implementation of the function
Rebasing off 1.14.0
Fix FT-2322
also fix bug in the else branch
and a potential bug fix: luasec_opts.cert -> luasec_opts.certificate
When doing SSL connection to Postgres with ECDSA certificate, the wrong signature digest name is used. Use https://github.com/fffonion/lua-resty-openssl#restyopensslobjects to set correct signature digest names. Fix https://konghq.atlassian.net/browse/FTI-3334.
Merge branch 'master' into kong-dev
fix the typo which causes mtls error "bad client cert type"
release: 2.3.2.0 (kong internal version)
cpwc
approved these changes
Mar 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.