Post-CVE Wishlist

2021-11-23 Thread Jacob Champion
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

Re: Post-CVE Wishlist

2021-11-23 Thread Tom Lane
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

Re: Post-CVE Wishlist

2021-11-23 Thread Robert Haas
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

Re: Post-CVE Wishlist

2021-11-23 Thread Tom Lane
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

Re: Post-CVE Wishlist

2021-11-23 Thread Heikki Linnakangas
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

Re: Post-CVE Wishlist

2021-11-23 Thread Michael Paquier
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

Re: Post-CVE Wishlist

2021-11-23 Thread Peter Eisentraut
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

Re: Post-CVE Wishlist

2021-11-24 Thread Heikki Linnakangas
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

Re: Post-CVE Wishlist

2021-11-24 Thread Robert Haas
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

Re: Post-CVE Wishlist

2021-11-24 Thread Jacob Champion
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

Re: Post-CVE Wishlist

2021-11-24 Thread Robert Haas
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

Re: Post-CVE Wishlist

2021-11-24 Thread Tom Lane
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

Re: Post-CVE Wishlist

2021-11-24 Thread Tom Lane
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

Re: Post-CVE Wishlist

2021-11-24 Thread Jacob Champion
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

Re: Post-CVE Wishlist

2021-11-24 Thread Robert Haas
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

Re: Post-CVE Wishlist

2021-11-24 Thread Jacob Champion
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

Re: Post-CVE Wishlist

2021-11-24 Thread Tom Lane
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,

Re: Post-CVE Wishlist

2021-11-24 Thread Robert Haas
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

Re: Post-CVE Wishlist

2021-12-07 Thread Jacob Champion
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

Re: Post-CVE Wishlist

2021-12-09 Thread Peter Eisentraut
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

Re: Post-CVE Wishlist

2021-12-10 Thread Heikki Linnakangas
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

Re: Post-CVE Wishlist

2021-12-16 Thread Jacob Champion
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