On Thu, May 16, 2024 at 10:23 AM Heikki Linnakangas wrote:
> Yep, committed. Thanks everyone!
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
On 16/05/2024 17:08, Daniel Gustafsson wrote:
On 16 May 2024, at 15:54, Robert Haas wrote:
On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote:
Ok, yeah, I can see that now. Here's a new version to address that. I
merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
> On 16 May 2024, at 15:54, Robert Haas wrote:
>
> On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote:
>> Ok, yeah, I can see that now. Here's a new version to address that. I
>> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
>> ENC_SSL. The places that need to d
On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote:
> Ok, yeah, I can see that now. Here's a new version to address that. I
> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
> ENC_SSL. The places that need to distinguish between them now check
> conn-sslnegotiation.
On Wed, May 15, 2024 at 6:33 AM Heikki Linnakangas wrote:
> Ok, yeah, I can see that now. Here's a new version to address that. I
> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
> ENC_SSL. The places that need to distinguish between them now check
> conn-sslnegotiation.
On 14/05/2024 01:29, Jacob Champion wrote:
Definitely not a major problem, but I think
select_next_encryption_method() has gone stale, since it originally
provided generality and lines of fallback that no longer exist. In
other words, I think the following code is now misleading:
if (conn->sslm
On Mon, Apr 29, 2024 at 11:04 AM Jacob Champion
wrote:
> On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
> > Unfortunately the error message you got in the client with that was
> > horrible (I modified the server to not accept the 'postgresql' protocol):
> >
> > psql "dbname=postgres ss
[this should probably belong to a different thread, but I'm not sure
what to title it]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> I think these options should be designed from the user's point of view,
> so that the user can specify the risks they're willing to accept, and
> the
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> I find this idea to be a massive improvement over the status quo,
+1
> and
> I didn't spot any major problems when I read through the patch,
> either.
Definitely not a major problem, but I think
select_next_encryption_method() has gone stale,
On Mon, May 13, 2024 at 1:42 PM Jelte Fennema-Nio wrote:
> Like Jacob already said, I guess you meant me here. The main point I
> was trying to make is that sslmode=require is extremely insecure too,
> so if we're changing the default then I'd rather bite the bullet and
> actually make the default
On Mon, May 13, 2024 at 12:45 PM Jacob Champion
wrote:
> For the record, I didn't say that... You mean Jelte's quote up above?
Yeah, sorry, I got my J-named hackers confused. Apologies.
--
Robert Haas
EDB: http://www.enterprisedb.com
[soapbox thread, so I've changed the Subject]
On Mon, May 13, 2024 at 4:08 AM Heikki Linnakangas wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.
This isn't true in the same way that "standard" TLS protects against
MITM. I know you know that, but for the benefi
On Mon, 13 May 2024 at 18:14, Robert Haas wrote:
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer. That seems like the kind of pessimism
> that makes people hate security professionals. There have got to be
> some attacks that are foreclosed b
(There's, uh, a lot to respond to above and I'm trying to figure out
how best to type up all of it.)
On Mon, May 13, 2024 at 9:13 AM Robert Haas wrote:
> However,
> I disagree with Jacob's assertion that sslmode=require has no security
> benefits over sslmode=prefer.
For the record, I didn't say
On Mon, May 13, 2024 at 9:37 AM Heikki Linnakangas wrote:
> On 10/05/2024 16:50, Heikki Linnakangas wrote:
> > New proposal:
> >
> > - Remove the "try both" mode completely, and rename "requiredirect" to
> > just "direct". So there would be just two modes: "postgres" and
> > "direct". On reflectio
On 13/05/2024 16:55, Jelte Fennema-Nio wrote:
On Mon, 13 May 2024 at 15:38, Heikki Linnakangas wrote:
Here's a patch to implement that.
+ if (conn->sslnegotiation[0] == 'd' &&
+ conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
I think these checks should use strcmp instead
On Mon, 13 May 2024 at 13:07, Heikki Linnakangas wrote:
> "channel_binding=require sslmode=require" also protects from MITM attacks.
Cool, I didn't realize we had this connection option and it could be
used like this. But I think there's a few security downsides of
channel_binding=require over ss
On Mon, 13 May 2024 at 15:38, Heikki Linnakangas wrote:
> Here's a patch to implement that.
+ if (conn->sslnegotiation[0] == 'd' &&
+ conn->sslmode[0] != 'r' && conn->sslmode[0] != 'v')
I think these checks should use strcmp instead of checking magic first
characters. I see this
On 10/05/2024 16:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic fallback mode doesn't seem very
useful. It would make sense a
On 13/05/2024 12:50, Jelte Fennema-Nio wrote:
On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote:
In v18, I'd like to make sslmode=require the default. Or maybe introduce
a new setting like "encryption=ssl|gss|none", defaulting to 'ssl'. If we
want to encourage encryption, that's the right
On Sun, 12 May 2024 at 23:39, Heikki Linnakangas wrote:
> You might miss that by changing sslnegotiation to 'postgres', or by
> removing it altogether, you not only made it compatible with older
> server versions, but you also allowed falling back to a plaintext
> connection. Maybe you're fine wit
On 11/05/2024 23:45, Jelte Fennema-Nio wrote:
On Fri, 10 May 2024 at 15:50, Heikki Linnakangas wrote:
New proposal:
- Remove the "try both" mode completely, and rename "requiredirect" to
just "direct". So there would be just two modes: "postgres" and
"direct". On reflection, the automatic fall
On Fri, 10 May 2024 at 15:50, Heikki Linnakangas wrote:
> New proposal:
>
> - Remove the "try both" mode completely, and rename "requiredirect" to
> just "direct". So there would be just two modes: "postgres" and
> "direct". On reflection, the automatic fallback mode doesn't seem very
> useful. It
On 29/04/2024 22:32, Jacob Champion wrote:
On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
There is a small benefit with sslmode=prefer if you connect to a server
that doesn't support SSL, though. With sslnegotiation=direct, if the
server rejects the direct SSL connection, the client
> On 29 Apr 2024, at 21:06, Heikki Linnakangas wrote:
> Oh I was not aware sslrootcert=system works like that. That's a bit
> surprising, none of the other ssl-related settings imply or require that SSL
> is actually used. Did we intend to set a precedence for new settings with
> that?
It was
On Mon, Apr 29, 2024 at 12:32 PM Jacob Champion
wrote:
>
> On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
> > On 29/04/2024 21:43, Jacob Champion wrote:
> > > But if you're in that situation, what does the use of directonly give
> > > you over `sslnegotiation=direct`? You already know
On Mon, Apr 29, 2024 at 12:06 PM Heikki Linnakangas wrote:
> On 29/04/2024 21:43, Jacob Champion wrote:
> > But if you're in that situation, what does the use of directonly give
> > you over `sslnegotiation=direct`? You already know that servers
> > support direct, so there's no additional perform
On 29/04/2024 21:43, Jacob Champion wrote:
On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas wrote:
If you only
have v17 servers in your environment, so you know all servers support
direct negotiation if they support SSL at all, but a mix of servers with
and without SSL, sslnegotiation=directo
On Mon, Apr 29, 2024 at 11:43 AM Heikki Linnakangas wrote:
> Note that if the client does not request ALPN at all, the callback is
> not called, and the connection is accepted. Old clients still work
> because they do not request ALPN.
Ugh, sorry for the noise -- I couldn't figure out why all my
On 29/04/2024 21:04, Jacob Champion wrote:
On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
I finally understood what you mean. So if the client supports ALPN, but
the list of protocols that it provides does not include 'postgresql',
the server should reject the connection with 'no_app
On Mon, Apr 29, 2024 at 1:38 AM Heikki Linnakangas wrote:
> Sure, we'd try to fix them ASAP. But we've had the SSLRequest
> negotiation since time immemorial. If a new vulnerability is found, it's
> unlikely that we'd need to disable the SSLRequest negotiation altogether
> to fix it. We'd be in se
On Fri, Apr 26, 2024 at 3:51 PM Heikki Linnakangas wrote:
> I finally understood what you mean. So if the client supports ALPN, but
> the list of protocols that it provides does not include 'postgresql',
> the server should reject the connection with 'no_applicaton_protocol'
> alert.
Right. (And
On Mon, Apr 29, 2024 at 4:38 AM Heikki Linnakangas wrote:
> Making requiredirect to imply sslmode=require, or error out unless you
> also set sslmode=require, feels like a cavalier way of forcing SSL. We
> should have a serious discussion on making sslmode=require the default
> instead. That would
On Mon, Apr 29, 2024 at 12:43:18PM +0300, Heikki Linnakangas wrote:
> If a caller wants to distinguish between "libpq or the SSL library doesn't
> support ALPN at all" from "the server didn't support ALPN", you can tell
> from whether PQsslAttribute returns NULL or an empty string. So I think an
>
On 23/04/2024 10:07, Michael Paquier wrote:
In the documentation of PQsslAttribute(), it is mentioned that empty
string is returned for "alpn" if ALPN was not used, however the code
returns NULL in this case:
SSL_get0_alpn_selected(conn->ssl, &data, &len);
if (data == NULL || le
On 26/04/2024 02:23, Jacob Champion wrote:
On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas wrote:
I think that comes down to the debate upthread, and whether you think
it's a performance tweak or a security feature. My take on it is,
`direct` mode is performance, and `requiredirect` is secur
On 23/04/2024 20:02, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven't gotten
On Thu, Apr 25, 2024 at 5:50 PM Heikki Linnakangas wrote:
> On 25/04/2024 21:13, Jacob Champion wrote:
> > On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> >> Maybe I'm missing something here, but why doesn't sslnegotiation
> >> override sslmode completely? Or alternatively, why not remove
>
On Thu, Apr 25, 2024 at 2:50 PM Heikki Linnakangas wrote:
> > I think that comes down to the debate upthread, and whether you think
> > it's a performance tweak or a security feature. My take on it is,
> > `direct` mode is performance, and `requiredirect` is security.
>
> Agreed, although the the
On 25/04/2024 21:13, Jacob Champion wrote:
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
Maybe I'm missing something here, but why doesn't sslnegotiation
override sslmode completely? Or alternatively, why not remove
sslnegotiation entirely and just have more sslmode values? I mean
maybe t
On Thu, Apr 25, 2024 at 10:35 AM Robert Haas wrote:
> Maybe I'm missing something here, but why doesn't sslnegotiation
> override sslmode completely? Or alternatively, why not remove
> sslnegotiation entirely and just have more sslmode values? I mean
> maybe this shouldn't happen categorically, bu
On Thu, Apr 25, 2024 at 12:28 PM Jacob Champion
wrote:
> On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
> > It is difficult to imagine a world in which we have both requiredirect
> > and forcedirect and people are not confused.
>
> Yeah... Any thoughts on a better scheme? require_auth was mea
On Thu, Apr 25, 2024 at 9:17 AM Robert Haas wrote:
>
> It is difficult to imagine a world in which we have both requiredirect
> and forcedirect and people are not confused.
Yeah... Any thoughts on a better scheme? require_auth was meant to
lock down overly general authentication; maybe a require_
On Thu, Apr 25, 2024 at 12:16 PM Jacob Champion
wrote
> Right. I don't like that it still happens with
> sslnegotiation=requiredirect, but I suspect that this is not the
> thread to complain about it in. Maybe I can propose a
> sslnegotiation=forcedirect or something for 18, to complement a
> post
On Tue, Apr 23, 2024 at 2:20 PM Heikki Linnakangas wrote:
>
> Attached patch tries to fix and clarify those.
s/negotiatied/negotiated/ in the attached patch, but other than that
this seems like a definite improvement. Thanks!
> (Note that the client will only attempt GSSAPI encryption if it can
On 23/04/2024 22:33, Jacob Champion wrote:
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
I've not followed this thread closely enough to understand the comment
about requiredirect maybe not actually requiring direct, but if that
were true it seems like it might be concerning.
It may be
On Tue, Apr 23, 2024 at 10:43 AM Robert Haas wrote:
> I've not followed this thread closely enough to understand the comment
> about requiredirect maybe not actually requiring direct, but if that
> were true it seems like it might be concerning.
It may be my misunderstanding. This seems to imply
On Tue, Apr 23, 2024 at 1:22 PM Jacob Champion
wrote:
> On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
> > On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > > On 22/04/2024 10:19, Michael Paquier wrote:
> > >> As a whole, I can get behind a unique GUC that forces th
On Mon, Apr 22, 2024 at 10:42 PM Michael Paquier wrote:
>
> On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> > On 22/04/2024 10:19, Michael Paquier wrote:
> >> As a whole, I can get behind a unique GUC that forces the use of
> >> direct. Or, we could extend the existing "ssl"
On Fri, Apr 19, 2024 at 2:43 PM Heikki Linnakangas wrote:
>
> On 19/04/2024 19:48, Jacob Champion wrote:
> > On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> >> With direct SSL negotiation, we always require ALPN.
> >
> > (As an aside: I haven't gotten to test the version of the patc
On Tue, Apr 23, 2024 at 01:48:04AM +0300, Heikki Linnakangas wrote:
> Here's the patch for that. The error message is:
>
> "direct SSL connection was established without ALPN protocol negotiation
> extension"
WFM.
> That's accurate, but I wonder if we could make it more useful to a user
> who's
On Mon, Apr 22, 2024 at 10:47:51AM +0300, Heikki Linnakangas wrote:
> On 22/04/2024 10:19, Michael Paquier wrote:
>> As a whole, I can get behind a unique GUC that forces the use of
>> direct. Or, we could extend the existing "ssl" GUC with a new
>> "direct" value to accept only direct connections
On 22/04/2024 10:47, Heikki Linnakangas wrote:
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we
On 22/04/2024 10:19, Michael Paquier wrote:
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven'
On Sat, Apr 20, 2024 at 12:43:24AM +0300, Heikki Linnakangas wrote:
> On 19/04/2024 19:48, Jacob Champion wrote:
>> On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
>>> With direct SSL negotiation, we always require ALPN.
>>
>> (As an aside: I haven't gotten to test the version of the
On 19/04/2024 19:48, Jacob Champion wrote:
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
With direct SSL negotiation, we always require ALPN.
(As an aside: I haven't gotten to test the version of the patch that
made it into 17 yet, but from a quick glance it looks like we're not
On Fri, Apr 19, 2024 at 6:56 AM Heikki Linnakangas wrote:
> On 19/04/2024 08:06, Michael Paquier wrote:
> > Since 91044ae4baea (require ALPN for direct SSL connections) and
> > d39a49c1e459 (direct hanshake), direct SSL connections are supported
> > (yeah!), still the thread where this has been di
On 19/04/2024 08:06, Michael Paquier wrote:
Hi all,
(Heikki in CC.)
(Adding Jacob)
Since 91044ae4baea (require ALPN for direct SSL connections) and
d39a49c1e459 (direct hanshake), direct SSL connections are supported
(yeah!), still the thread where this has been discussed does not cover
the p
Hi all,
(Heikki in CC.)
Since 91044ae4baea (require ALPN for direct SSL connections) and
d39a49c1e459 (direct hanshake), direct SSL connections are supported
(yeah!), still the thread where this has been discussed does not cover
the potential impact on HBA rules:
https://www.postgresql.org/message
59 matches
Mail list logo
