Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 - Mailing list pgsql-jdbc
From | Álvaro Hernández Tortosa |
---|---|
Subject | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 |
Date | |
Msg-id | b73a4aab-49cf-189b-1c15-af25dc8d964a@8kdata.com Whole thread Raw |
In response to | Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256 (Michael Paquier <michael.paquier@gmail.com>) |
Responses |
Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256
|
List | pgsql-jdbc |
On 20/06/17 06:11, Michael Paquier wrote: > On Tue, Jun 6, 2017 at 3:40 PM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> As far as I can see, there are a couple of things that I still need to >> work on to make people happy: >> - Rework the generic APIs for TLS finish and endpoint so as any >> implementation can use channel binding without inducing any extra code >> footprint to be-secure.c and fe-secure.c. >> - Implement endpoint, as Alvaro is saying for JDBC that would be nicer. >> - Have a couple of tests for channel binding to allow people to test >> the feature easily. Those will be in src/test/ssl/. It would be nice >> as well to be able to enforce the channel binding type on libpq-side, >> which is useful at least for testing. So we are going to need an >> environment variable for this purpose, and a connection parameter. > Okay, here we go. Attached is a set of four patches: > - 0001 is some refactoring for the SSL tests so as other test suite in > src/test/ssl can take advantage of the connection routines. There is > nothing fancy here. > - 0002 is the implementation of tls-unique as channel binding. This > has been largely reworked since last submission, I have found on the > way a couple of bugs and some correctness issues. > - 0003 is a patch to add as connection parameters saslname and > saslchannelbinding. With support of more SASL mechanisms (PG10 has > SCRAM-SHA-256, I am adding SCRAM-SHA-256-PLUS here), saslname can be > used to enforce on the client-side the value of the SASL mechanism > chosen. saslchannelbinding does the same for the channel binding name. > This is very useful for testing, and a set of tests are added in > src/test/ssl/ for tls-unique and the SASL mechanisms. The tests cover > many scenarios, like downgrade attacks for example. > - 0004 is the implementation of tls-server-end-point, as Alvaro has > asked. Per RFC 5929, the binding data needs to be a hash of the server > certificate. If the signature algorithm of the certificate is MD5 or > SHA-1, then SHA-256 is used. Other signature algos like SHA-384 or 512 > are used to hash the data. The hashed data is then encoded in base64 > and sent to the server for verification. Tests using saslchannelname > have been added as well. It took me a while to find out that > OBJ_find_sigid_algs(X509_get_signature_nid(X509*)) needs to be used to > find out the algorithm of a certificate with OpenSSL. > > With the tests directly in the patch, things are easy to run. WIth > PG10 stabilization work, of course I don't expect much feedback :) > But this set of patches looks like the direction we want to go so as > JDBC and libpq users can take advantage of channel binding with SCRAM. This is awesome, Michael. In the coming weeks, and once my PR for pgjdbc has been added, I will work towards another patch to implement channel binding. Should be reasonably easy now, thanks to this. Appreciated! Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
pgsql-jdbc by date: