On Fri, 2021-12-10 at 15:43 +0200, Heikki Linnakangas wrote:
> ProcessStartupPacket() currently reads the first 4 bytes coming from the
> client to decide what kind of a connection it is, and I believe a TLS
> ClientHello message always begins with the same sequence of bytes, so it
> would be ea
On 09/12/2021 17:24, Peter Eisentraut wrote:
On 07.12.21 19:49, Jacob Champion wrote:
= Implicit TLS =
Reactions to implicit TLS were mixed, from "we should not do this" to
"it might be nice to have the option, from a technical standpoint".
Both a separate-port model and a shared-port model wer
On 07.12.21 19:49, Jacob Champion wrote:
= Implicit TLS =
Reactions to implicit TLS were mixed, from "we should not do this" to
"it might be nice to have the option, from a technical standpoint".
Both a separate-port model and a shared-port model were tentatively
proposed. The general consensus
On Tue, 2021-11-23 at 18:27 +, Jacob Champion wrote:
> Now that the MITM CVEs are published [1], I wanted to share my wishlist
> of things that would have made those attacks difficult/impossible to
> pull off.
Now that we're post-commitfest, here's my summary of the responses so
far:
> = Clie
On Wed, Nov 24, 2021 at 3:14 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Nov 24, 2021 at 2:53 PM Tom Lane wrote:
> >> One other point to be made here is that it seems like a stretch to call
> >> these particular bugs "high-severity".
>
> > Well, I was referring to the CVSS score, which
Robert Haas writes:
> On Wed, Nov 24, 2021 at 2:53 PM Tom Lane wrote:
>> One other point to be made here is that it seems like a stretch to call
>> these particular bugs "high-severity".
> Well, I was referring to the CVSS score, which was in the "high" range.
The server CVE is; the client CVE,
On Wed, 2021-11-24 at 14:01 -0500, Robert Haas wrote:
> The bar for actually ripping it out
> on an expedited time scale would be proving not only that it's broken
> in multiple ways, but that it's so badly broken that it can't be fixed
> with any reasonable amount of effort. And I just don't see o
On Wed, Nov 24, 2021 at 2:53 PM Tom Lane wrote:
> One other point to be made here is that it seems like a stretch to call
> these particular bugs "high-severity".
Well, I was referring to the CVSS score, which was in the "high" range.
> Given what we learned about
> the difficulty of exploiting
On Wed, 2021-11-24 at 14:03 -0500, Tom Lane wrote:
> > I don't buy the idea that, because we have fixed that particular
> > vulnerability, we've rendered this entire class of bugs "hypothetical".
> > There will be more code and more clients. There will always be bugs.
> > I'd rather the bugs that p
Robert Haas writes:
> I think it would take an overwhelming amount of evidence to convince
> the project to remove support for the current method. One or even two
> or three high-severity bugs will probably not convince the project to
> do more than spend more studying that code and trying to tigh
Jacob Champion writes:
> What I'm trying to convince you of is that this pattern of beginning a
> TLS conversation is known to be particularly error-prone, across
> multiple protocols and implementations. I think this is supported by
> the fact that at least three independent client libraries made
On Wed, Nov 24, 2021 at 1:29 PM Jacob Champion wrote:
> What I'm trying to convince you of is that this pattern of beginning a
> TLS conversation is known to be particularly error-prone, across
> multiple protocols and implementations. I think this is supported by
> the fact that at least three in
On Wed, 2021-11-24 at 09:40 -0500, Robert Haas wrote:
> I am not really persuaded by Jacob's argument that, had this only
> worked the other way from the start, this bug wouldn't have occurred.
> That's just a tautology, because we can only have bugs in the code we
> write, not the code we didn't w
On Tue, Nov 23, 2021 at 5:41 PM Heikki Linnakangas wrote:
> All that said, I'm not sure how serious I am about this. I think it
> would work, and it wouldn't even be very complicated, but it feels
> hacky, and that's not a good thing with anything security related. And
> the starttls-style negotia
On 24/11/2021 07:09, Michael Paquier wrote:
On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
Jacob Champion writes:
= Client-Side Auth Selection =
The second request is for the client to stop fully trusting the server
during the authentication phase. If I tell libpq to use a client
ce
On 23.11.21 23:41, Heikki Linnakangas wrote:
On 23/11/2021 23:44, Robert Haas wrote:
On Tue, Nov 23, 2021 at 2:18 PM Tom Lane wrote:
Jacob Champion writes:
= Implicit TLS =
Aside from security, one small benefit of skipping the Starttls-style
negotiation is that you avoid one round-trip t
On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
> Jacob Champion writes:
>> = Client-Side Auth Selection =
>> The second request is for the client to stop fully trusting the server
>> during the authentication phase. If I tell libpq to use a client
>> certificate, for example, I don't t
On 23/11/2021 23:44, Robert Haas wrote:
On Tue, Nov 23, 2021 at 2:18 PM Tom Lane wrote:
Jacob Champion writes:
= Implicit TLS =
Aside from security, one small benefit of skipping the Starttls-style
negotiation is that you avoid one round-trip to the server.
I think this idea is a nonsta
Robert Haas writes:
> I am not persuaded by this argument. Suppose we added a server option
> like ssl_port which causes us to listen on an additional port and, on
> that port, everything, from the first byte on this connection, is
> encrypted using SSL.
Right, a separate port number (much akin t
On Tue, Nov 23, 2021 at 2:18 PM Tom Lane wrote:
> Jacob Champion writes:
> > = Implicit TLS =
>
> I think this idea is a nonstarter. It breaks backwards compatibility
> at the protocol level in order to fix entirely-hypothetical bugs.
> Nobody is going to like that tradeoff. Moreover, how shall
Jacob Champion writes:
> = Implicit TLS =
I think this idea is a nonstarter. It breaks backwards compatibility
at the protocol level in order to fix entirely-hypothetical bugs.
Nobody is going to like that tradeoff. Moreover, how shall the
server know whether an incoming connection is expected
Hello all,
Now that the MITM CVEs are published [1], I wanted to share my wishlist
of things that would have made those attacks difficult/impossible to
pull off.
= Implicit TLS =
The frontend/backend protocol uses a STARTTLS-style negotiation, which
has had a fair number of implementation vulner
22 matches
Mail list logo
