On Tue, Jun 6, 2017 at 3:40 PM, Michael Paquier <michael.paqu...@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. -- Michael
0001-Refactor-routine-to-test-connection-to-SSL-server.patch
Description: Binary data
0002-Support-channel-binding-tls-unique-in-SCRAM.patch
Description: Binary data
0003-Add-connection-parameters-saslname-and-saslchannelbi.patch
Description: Binary data
0004-Implement-channel-binding-tls-server-end-point-for-S.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
