Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 6/23/18 17:09, Bruce Momjian wrote: > On Wed, Jun 6, 2018 at 01:16:11PM -0700, Steven Fackler wrote: >> TLS 1.3, (which is currently in a draft state, but is theoretically being >> finalized soon) does not support the TLS channel binding algorithms [1]. From > > Uh, according to this article,

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Tue, Jun 19, 2018 at 09:19:40AM +0900, Michael Paquier wrote: > As Peter and Heikki have worked as well on all those features with me, > are there any objection to discard this open item? I looked again at > the patch this morning and it is true that OpenSSL's history makes > things harder, so

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 24/06/18 18:49, Dave Cramer wrote: On 29 May 2018 at 22:48, Michael Paquier > wrote: On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > Hmm. I think Peter went through this in commits ac3ff8b1d8 and 054e8c6cdb. > If you got

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 29 May 2018 at 22:48, Michael Paquier wrote: > On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > > Hmm. I think Peter went through this in commits ac3ff8b1d8 and > 054e8c6cdb. > > If you got that working now, I suppose we could do that, but I'm actually > > inclined to

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 6, 2018 at 01:16:11PM -0700, Steven Fackler wrote: > TLS 1.3, (which is currently in a draft state, but is theoretically being > finalized soon) does not support the TLS channel binding algorithms [1]. From Uh, according to this article, TLS 1.3 was finalized in March:

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Sat, Jun 09, 2018 at 09:28:17AM +0900, Michael Paquier wrote: > I am still not completely sure what is the correct course of action > here. Heikki and Peter and not much in favor of adding more complexity > here as OpenSSL has a long history of having a non-linear history across > platforms.

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Mon, Jun 11, 2018 at 10:47:23AM -0400, Peter Eisentraut wrote: > I think we'll just have to wait for an updated RFC on channel bindings > for TLS 1.3. > > Perhaps we should change PostgreSQL 11 to not advertise channel binding > when TLS 1.3 is used? Yeah, that's what we should do and I would

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 6/6/18 16:16, Steven Fackler wrote: > TLS 1.3, (which is currently in a draft state, but is theoretically > being finalized soon) does not support the TLS channel binding > algorithms [1]. From talking with one of the people working on the TLS > 1.3 standard, tls-unique is seen as particularly

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 6, 2018 at 2:21 PM Michael Paquier wrote: Thanks for the pointers, Steven. You should avoid top-posting on this > list, this is not the style used on the Postgres lists. > Ah sorry about that! Hopefully this looks better. > Does this mean that tls-server-end-point goes into

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 06, 2018 at 01:16:11PM -0700, Steven Fackler wrote: Thanks for the pointers, Steven. You should avoid top-posting on this list, this is not the style used on the Postgres lists. > TLS 1.3, (which is currently in a draft state, but is theoretically being > finalized soon) does not

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

TLS 1.3, (which is currently in a draft state, but is theoretically being finalized soon) does not support the TLS channel binding algorithms [1]. >From talking with one of the people working on the TLS 1.3 standard, tls-unique is seen as particularly problematic. There's some discussion on the

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 6/6/18 12:37, Alvaro Herrera wrote: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

Alvaro Herrera writes: > If SCRAM channel binding is an important aspect to security, and the > older OpenSSL versions will still be around in servers for some time > yet, it seems like it behooves us to go the extra mile and provide an > implementation that works with such existing servers.

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 2018-May-29, Michael Paquier wrote: > On Tue, May 29, 2018 at 10:33:03PM -0400, Heikki Linnakangas wrote: > > Hmm. I think Peter went through this in commits ac3ff8b1d8 and 054e8c6cdb. > > If you got that working now, I suppose we could do that, but I'm actually > > inclined to just stick to

Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On 29/05/18 17:02, Michael Paquier wrote: Currently, the SCRAM channel binding tls-server-end-point is supported only with OpenSSL 1.0.2 and newer versions as we rely on X509_get_signature_nid to get the certificate signature ID, which is the official way of upstream to get this information as

Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

Hi all, Currently, the SCRAM channel binding tls-server-end-point is supported only with OpenSSL 1.0.2 and newer versions as we rely on X509_get_signature_nid to get the certificate signature ID, which is the official way of upstream to get this information as all the contents of X509 are