On Fri, Oct 14, 2022 at 11:00:10AM +0900, Michael Paquier wrote:
> Oh, okay. That's an argument in favor of not doing that, then.
> Perhaps we'd better revisit the introduction of tls-exporter once we
> know more about all that, and it looks like we would need a way to be
> able to negotiate
On Thu, Oct 13, 2022 at 10:30:37AM -0700, Jacob Champion wrote:
> Is the intent to backport tls-exporter client support? Or is the
> compatibility break otherwise acceptable?
Well, I'd rather say yes thanks to the complexity avoided in the
backend as that's the most sensible piece security-wise,
On Wed, Oct 12, 2022 at 11:01 PM Michael Paquier wrote:
> One thing that would reduce the complexity of the equation is
> to drop support for tls-server-end-point in the backend in PG >= 16 as
> the versions of OpenSSL we still support on HEAD would cover
> completely tls-exporter.
Is the intent
On Tue, Sep 20, 2022 at 11:51:44AM -0700, Jacob Champion wrote:
> On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion
> wrote:
>> Well, I'm working on a next version, but it's ballooning in complexity
>> as I try to navigate the fix for OpenSSL 1.0.1 (which is currently
>> failing the tests,
On Tue, Sep 20, 2022 at 11:01 AM Jacob Champion wrote:
> Well, I'm working on a next version, but it's ballooning in complexity
> as I try to navigate the fix for OpenSSL 1.0.1 (which is currently
> failing the tests, unsurprisingly).
To be more specific: I think I'm hitting the case that Heikki
On Mon, Sep 19, 2022 at 5:54 PM Michael Paquier wrote:
> X509_get_signature_nid() has been introduced in 1.0.2.
> SSL_export_keying_material() is older than that, being present since
> 1.0.1. Considering the fact that we want to always have
> tls-server-end-point as default, it seems to me that
On Mon, Sep 19, 2022 at 09:27:41AM -0700, Jacob Champion wrote:
> While looking into this I noticed that I left the following code in place:
>
>> #ifdef HAVE_BE_TLS_GET_CERTIFICATE_HASH
>> if (strcmp(selected_mech, SCRAM_SHA_256_PLUS_NAME) == 0 &&
>> port->ssl_in_use)
>
> In other words,
On Wed, Sep 7, 2022 at 10:03 AM Jacob Champion wrote:
> Yeah, that should be fine. Requiring newer OpenSSLs for stronger
> crypto will probably be uncontroversial.
While looking into this I noticed that I left the following code in place:
> #ifdef HAVE_BE_TLS_GET_CERTIFICATE_HASH
> if
On Wed, Aug 31, 2022 at 5:57 PM Michael Paquier wrote:
> On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> > OpenSSL should have an API for that (SSL_get_extms_support); I don't
> > know when it was introduced.
>
> This is only available from 1.1.0, meaning that we'd better
On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote:
> For protocols less than 1.3 we'll need to ensure that the extended
> master secret is in use:
>
>This channel binding mechanism is defined only when the TLS handshake
>results in unique master secrets. This is true of TLS
On Sun, Aug 28, 2022 at 11:02 PM Michael Paquier wrote:
> RFC9266, that has been released not so long ago, has added
> tls-exporter as a new channel binding type:
> https://www.rfc-editor.org/rfc/rfc5929.html
Hi Michael, thank you for sending this!
> Note also that tls-exporter is aimed for
>
Hi all,
RFC9266, that has been released not so long ago, has added
tls-exporter as a new channel binding type:
https://www.rfc-editor.org/rfc/rfc5929.html
An advantage over tls-server-end-point, AFAIK, is that this prevents
man-in-the-middle attacks even if the attacker holds the server's
12 matches
Mail list logo
