Обсуждение: Post-CVE Wishlist

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 vulnerabilities in the SMTP
space [2] and is where I got the idea for the attacks to begin with.
There is a large amount of plaintext traffic on the wire that happens
before either party trusts the other, and there is plenty of code that
touches that untrusted traffic.

An implicit TLS flow would put the TLS handshake at the very beginning
of the connection, before any of the frontend/backend protocol is
spoken on the wire. (You all have daily experience with this flow, by
way of HTTPS.) So a verify-full client would know that the server is
the expected recipient, and that the connection is encrypted, before
ever sending a single byte of Postgres-specific communication, and
before receiving potential error messages. Similarly, a
clientcert=verify-* server would have already partially authenticated
the client before ever receiving a startup packet, and it can trust
that any messages sent during the handshake are received without
tampering.

This has downsides. Backwards compatibility tends to reintroduce
downgrade attacks, which defeats the goal of implicit TLS. So DBAs
would probably have to either perform a hard cutover to the new system
(with all-new clients ready to go), or else temporarily introduce a new
port for the implicit TLS mode (similar to HTTP/HTTPS separation) while
older clients are migrated.

And obviously this doesn't help you if you're already using a different
form of encryption (GSSAPI). I'm ignorant of the state of the art for
implicit encryption using that method. But for DBAs who are already
deploying TLS as their encryption layer and want to force its use for
every client, I think this would be a big step forward.

= 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 think the server should be allowed to
extract a plaintext password from my environment (at least not without
my explicit opt-in).

Auth negotiation has been proposed a couple of times on the list (see
for example [3]), and it's already been narrowly applied for SCRAM's
channel binding, since allowing a server to sidestep the client
authentication defeats the purpose. But I'd like to see this applied
generally, so that if the server sends an authentication request that
my client hasn't been explicitly configured to use, the connection
fails. Implementations could range from a simple "does the server's
auth method match the single one I expect" to a full SASL mechanism
negotation.

WDYT? Are these worth pursuing in the near future?

--Jacob

[1] https://www.postgresql.org/about/news/postgresql-141-135-129-1114-1019-and-9624-released-2349/
[2] https://www.feistyduck.com/bulletproof-tls-newsletter/issue_80_vulnerabilities_show_fragility_of_starttls
[3] https://www.postgresql.org/message-id/flat/CAB7nPqS-aFg0iM3AQOJwKDv_0WkAedRjs1W2X8EixSz%2BsKBXCQ%40mail.gmail.com

Jacob Champion <pchampion@vmware.com> 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 to use TLS
or not, if no prior communication is allowed?  "TLS is the only
supported case" is even more of a nonstarter than a protocol change.

> = 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 think the server should be allowed to
> extract a plaintext password from my environment (at least not without
> my explicit opt-in).

Yeah.  I don't recall whether it's been discussed in public or not,
but it certainly seems like libpq should be able to be configured so
that (for example) it will never send a cleartext password.  It's not
clear to me what extent of configurability would be useful, and I
don't want to overdesign it --- but that much at least would be a
good thing.

> ... Implementations could range from a simple "does the server's
> auth method match the single one I expect" to a full SASL mechanism
> negotation.

Again, any sort of protocol change seems like a nonstarter from a
cost/benefit standpoint, even before you get to the question of
whether a downgrade attack could defeat it.  I'm envisioning just
having local configuration (probably in the connection string) that
tells libpq to fail the connection upon seeing certain auth requests.

            regards, tom lane

On Tue, Nov 23, 2021 at 2:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jacob Champion <pchampion@vmware.com> 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 to use TLS
> or not, if no prior communication is allowed?  "TLS is the only
> supported case" is even more of a nonstarter than a protocol change.

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. Then we have to also add a matching libpq option
which the client must set to tell the server that this is the
expectation. For people using URL connection strings, that might be as
simple as specifying postgresqls://whatever rather than
postgresql://whatever. With such a design, the feature is entirely
ignorable for those who don't wish to use it, but anyone who wants it
can get it relatively easily. I don't know how we'd ever deprecate the
current system, but we don't necessarily need to do so. LDAP allows
either kind of scheme -- you can either connect to a regular LDAP
port, usually port 389, and negotiate security, or you can connect to
a different port, usually 636, and use SSL from the start. I don't see
why that couldn't be a model for us, and I suspect that it would get
decent uptake.

Now that being said, https://www.openldap.org/faq/data/cache/605.html
claims that ldaps (encrpyt from the first byte) is deprecated in favor
of STARTTLS (encrypt by negotiation). It's interesting that Jacob is
proposing to introduce as a new and better option the thing they've
decided they don't like. I guess my question is - is either one truly
better, or is this just a vi vs. emacs type debate where different
people have different preferences? I'm really not sure.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Robert Haas <robertmhaas@gmail.com> 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 to http 80 vs https 443) is
pretty much the only way this could be managed.  That's messy enough
that I don't see anyone wanting to do it for purely-hypothetical
benefits.  If we'd done it that way from the start, it'd be fine;
but there's way too much established practice now.

> Now that being said, https://www.openldap.org/faq/data/cache/605.html
> claims that ldaps (encrpyt from the first byte) is deprecated in favor
> of STARTTLS (encrypt by negotiation). It's interesting that Jacob is
> proposing to introduce as a new and better option the thing they've
> decided they don't like.

Indeed, that is interesting.  I wonder if we can find the discussions
that led to that decision.

            regards, tom lane

On 23/11/2021 23:44, Robert Haas wrote:
> On Tue, Nov 23, 2021 at 2:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jacob Champion <pchampion@vmware.com> 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 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 to use TLS
>> or not, if no prior communication is allowed?  "TLS is the only
>> supported case" is even more of a nonstarter than a protocol change.
> 
> 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, iswh
> encrypted using SSL. Then we have to also add a matching libpq option
> which the client must set to tell the server that this is the
> expectation. For people using URL connection strings, that might be as
> simple as specifying postgresqls://whatever rather than
> postgresql://whatever. With such a design, the feature is entirely
> ignorable for those who don't wish to use it, but anyone who wants it
> can get it relatively easily. I don't know how we'd ever deprecate the
> current system, but we don't necessarily need to do so. LDAP allows
> either kind of scheme -- you can either connect to a regular LDAP
> port, usually port 389, and negotiate security, or you can connect to
> a different port, usually 636, and use SSL from the start. I don't see
> why that couldn't be a model for us, and I suspect that it would get
> decent uptake.
One intriguing option is to allow starting the TLS handshake without the 
SSLRequest packet. On the same port. A TLS handshake and PostgreSQL 
SSLRequest/StartupMessage/CancelRequest can be distinguished by looking 
at the first few bytes. The server can peek at them, and if it looks 
like a TLS handshake, start TLS (or fail if it's not supported), 
otherwise proceed with the libpq protocol.

This would make the transition smooth: we can add server support for 
this now, with an option in libpq to start using it. After some years, 
we can make it the default in libpq, but still fall back to the old 
method if it fails. After a long enough transition period, we can drop 
the old mechanism.

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 negotiation isn't that bad, really. I'm inclined to 
do nothing I guess. Thoughts?

> Now that being said, https://www.openldap.org/faq/data/cache/605.html
> claims that ldaps (encrpyt from the first byte) is deprecated in favor
> of STARTTLS (encrypt by negotiation). It's interesting that Jacob is
> proposing to introduce as a new and better option the thing they've
> decided they don't like. I guess my question is - is either one truly
> better, or is this just a vi vs. emacs type debate where different
> people have different preferences? I'm really not sure.

Huh, that's surprising, I though the trend is towards implicit TLS. As 
another data point, RFC 8314 recommends implicit TLS for POP, IMAP and SMTP.

- Heikki

On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
> Jacob Champion <pchampion@vmware.com> 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 think the server should be allowed to
>> extract a plaintext password from my environment (at least not without
>> my explicit opt-in).
>
> Yeah.  I don't recall whether it's been discussed in public or not,
> but it certainly seems like libpq should be able to be configured so
> that (for example) it will never send a cleartext password.  It's not
> clear to me what extent of configurability would be useful, and I
> don't want to overdesign it --- but that much at least would be a
> good thing.

I recall this part being discussed in public, but I cannot put my
finger on the exact thread.  I think that this was around when we
discussed the open items of 10 or 11 for things around channel binding
and how libpq was sensitive to downgrade attacks, which would mean
around 2016 or 2017.  I also recall reading (writing?) a patch that
introduced a new connection parameter that takes in input a
comma-separated list of keywords to allow the user to choose a set of
auth methods accepted, failing if the server is willing to use a
method that does not match with what the user has put in his list.
Perhaps this last part has never reached -hackers though :)

Anyway, the closest thing I can put my finger on now is that:
https://www.postgresql.org/message-id/c5cb08f4cce46ff661ad287fadaa1b2a@postgrespro.ru
--
Michael

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 <tgl@sss.pgh.pa.us> wrote:
>>> Jacob Champion <pchampion@vmware.com> 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.

Also, you could make use of existing TLS-aware proxy infrastructure 
without having to hack in PostgreSQL protocol support.  There is 
definitely demand for that.

On 24/11/2021 07:09, Michael Paquier wrote:
> On Tue, Nov 23, 2021 at 02:18:30PM -0500, Tom Lane wrote:
>> Jacob Champion <pchampion@vmware.com> 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 think the server should be allowed to
>>> extract a plaintext password from my environment (at least not without
>>> my explicit opt-in).
>>
>> Yeah.  I don't recall whether it's been discussed in public or not,
>> but it certainly seems like libpq should be able to be configured so
>> that (for example) it will never send a cleartext password.  It's not
>> clear to me what extent of configurability would be useful, and I
>> don't want to overdesign it --- but that much at least would be a
>> good thing.
> 
> I recall this part being discussed in public, but I cannot put my
> finger on the exact thread.  I think that this was around when we
> discussed the open items of 10 or 11 for things around channel binding
> and how libpq was sensitive to downgrade attacks, which would mean
> around 2016 or 2017.  I also recall reading (writing?) a patch that
> introduced a new connection parameter that takes in input a
> comma-separated list of keywords to allow the user to choose a set of
> auth methods accepted, failing if the server is willing to use a
> method that does not match with what the user has put in his list.
> Perhaps this last part has never reached -hackers though :)
> 
> Anyway, the closest thing I can put my finger on now is that:
> https://www.postgresql.org/message-id/c5cb08f4cce46ff661ad287fadaa1b2a@postgrespro.ru

Here's a thread:

https://www.postgresql.org/message-id/227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel%40j-davis.com

The result of that thread was that we added the 
channel_binding=require/prefer/disable option.

- Heikki

On Tue, Nov 23, 2021 at 5:41 PM Heikki Linnakangas <hlinnaka@iki.fi> 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 negotiation isn't that bad, really. I'm inclined to
> do nothing I guess. Thoughts?

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 write. So perhaps we would have just had
some other bug, which might have been more or less serious than the
one we actually had. It's hard to say, really, because the situation
is hypothetical.

But on reflection, one thing that isn't very nice about the current
approach is that it won't work with anything that doesn't support the
PostgreSQL wire protocol specifically. Imagine that you have a driver
for PostgreSQL that for some reason does not support SSL, but you want
to use SSL to talk to the server. You cannot stick a generic proxy
that speaks plaintext on one side and SSL on the other side between
that driver and the server and have it work. You will need something
that knows how to proxy the PostgreSQL protocol specifically, and that
will probably end up being higher-overhead than a generic proxy. There
are all sorts of other variants of this scenario, and one of them is
probably the motivation behind the request for proxy protocol support.
I don't use these kinds of software myself, but I think a lot of
people do, and it wouldn't be a bad thing if we could be
"plug-compatible" with things that people on the Internet want to do,
without needing a PostgreSQL-specific adapter. SSL is certainly one of
those things.

This argument doesn't answer the question of whether speaking pure SSL
on a separate port is better or worse than having a single port that
does either. If I had to guess, the latter is more convenient for
users but less convenient to code. I don't even see a compelling
reason why we can't support multiple models here, supposing someone is
willing to do the work and fix the bugs that result.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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 write. So perhaps we would have just had
> some other bug, which might have been more or less serious than the
> one we actually had. It's hard to say, really, because the situation
> is hypothetical.

I'm not trying to convince you that there wouldn't have been bugs.
There will always be bugs.

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 changes
in response to this Postgres CVE, a decade after the first writeup of
this exact vulnerability.

- https://github.com/postgres/postgres/commit/160c0258802
- https://github.com/pgbouncer/pgbouncer/commit/e4453c9151a
- https://github.com/yandex/odyssey/commit/4e00bf797a

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 people write be in places that are less
security-critical.

> This argument doesn't answer the question of whether speaking pure SSL
> on a separate port is better or worse than having a single port that
> does either. If I had to guess, the latter is more convenient for
> users but less convenient to code. I don't even see a compelling
> reason why we can't support multiple models here, supposing someone is
> willing to do the work and fix the bugs that result.

I only have experience in the area of HTTP(S), which supports three
models of plaintext-only, plaintext-upgrade-to-TLS (which is rare in
practice), and implicit-TLS. I'm not aware of mainstream efforts to mix
plaintext and implicit-TLS traffic on the same HTTP port -- but there
are projects that fill that niche [1] -- so I don't know what security
issues might arise from that approach.

--Jacob

[1] https://github.com/mscdex/httpolyglot

On Wed, Nov 24, 2021 at 1:29 PM Jacob Champion <pchampion@vmware.com> 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 independent client libraries made changes
> in response to this Postgres CVE, a decade after the first writeup of
> this exact vulnerability.
>
> - https://github.com/postgres/postgres/commit/160c0258802
> - https://github.com/pgbouncer/pgbouncer/commit/e4453c9151a
> - https://github.com/yandex/odyssey/commit/4e00bf797a

Sure, that's certainly true, but there are many programming patterns
that have well-known gotchas, and people still write programs that do
those things, debug them, and are satisfied with the results.
Beginning programming classes often cover the abuse of recursion using
fact() and fib() as examples. It's extremely easy to write a program
that concates a large number of strings with O(n^2) runtime, and tons
of people must have made that mistake. I've personally written fork()
bombs multiple times, sometimes unintentionally. None of that proves
that computing factorials or fibonacci numbers, concatenating strings,
or calling fork() are things that you just should not do. However, if
you do those things and make the classic errors, somebody's probably
going to think that you're kind of stupid. So here.

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 tighten
things up in a systematic way. Even if we did agree to move away from
it, we would mostly likely add support for the replacement method now
with a view to deprecating the old way in 6-10 years when existing
releases are out of support, which means we'd still need to fix all of
the bugs in the existing implementation, or at least all of the ones
discovered between now and then. 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 one bug
that had a pretty localized fix is really moving the needle as far as
that burden of proof is concerned.

And if the existing method is not going away, then adding a new method
just means that we have two things that can have bugs instead of one.
That might or might not be an advancement in usability or convenience,
but it certainly can't be less buggy.

--
Robert Haas
EDB: http://www.enterprisedb.com

Jacob Champion <pchampion@vmware.com> 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 changes
> in response to this Postgres CVE, a decade after the first writeup of
> this exact vulnerability.

Well, it's not clear that they didn't just copy libpq's buggy logic,
so I'm not sure how "independent" these bugs are.  I actually took
considerable comfort from the number of clients that *weren't*
vulnerable.

> 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 people write be in places that are less
> security-critical.

Unless we actively remove the existing way of starting SSL encryption
--- and GSS encryption, and anything else somebody proposes in future ---
we are not going to be able to design out this class of bugs.  Maybe
we could start the process now in the hopes of making such a breaking
change ten years down the road; but whether anyone will remember to
pull the trigger then is doubtful, and even if we do remember, you can
be dead certain it will still break some people's clients.  So I don't
put much stock in the argument that this will make things more secure.
(Ten years from now, SSL may be dead and replaced by something more
secure against quantum computers.)

The suggestion that we could remove one network roundtrip is worth
something.  And perhaps the argument about improving compatibility
with tools that know SSL but not the PG wire protocol (although
that one seems pretty unbacked by concrete facts).  Whether these
things make it worth the effort is dubious in my mind, but others
may evaluate that differently.  Note, however, that neither argument
impels us to break compatibility with existing clients.  That's a
far heavier price to pay, and basically I don't believe that we
are willing to pay it.

            regards, tom lane

Robert Haas <robertmhaas@gmail.com> 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 tighten
> things up in a systematic way.

One other point to be made here is that it seems like a stretch to call
these particular bugs "high-severity".  Given what we learned about
the difficulty of exploiting the libpq bug, and the certainty that any
other clients sharing the issue would have their own idiosyncrasies
necessitating a custom-designed attack, I rather doubt that we're going
to hear of anybody trying to exploit the issue in the field.

(By no means do I suggest that these bugs aren't worth fixing when we
find them.  But so far they seem very easy to fix.  So moving mountains
to design out just this one type of bug doesn't seem like a great use
of our finite earth-moving capacity.)

            regards, tom lane

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 people write be in places that are less
> > security-critical.
> 
> Unless we actively remove the existing way of starting SSL encryption
> --- and GSS encryption, and anything else somebody proposes in future ---
> we are not going to be able to design out this class of bugs.

_We_ can't. I get that. But if this feature is introduced, new clients
will begin to have the option of designing it out of their code. And
DBAs will have the option of locking down their servers so that any new
bugs we introduce in the TLS-upgrade codepath will simply not affect
them.

The ecosystem has the option of transitioning faster than we can. And
then, some number of releases later, an entirely new conversation might
happen. (Or it might not.)

> Maybe
> we could start the process now in the hopes of making such a breaking
> change ten years down the road; but whether anyone will remember to
> pull the trigger then is doubtful, and even if we do remember, you can
> be dead certain it will still break some people's clients.

I am familiar with the "we didn't plant a tree 20 years ago, so we
shouldn't plant one now" line of argument. :D I hope it's not as
persuasive as it used to be.

> So I don't
> put much stock in the argument that this will make things more secure.
> (Ten years from now, SSL may be dead and replaced by something more
> secure against quantum computers.)

That would be great! But I suspect that if that happens, the new
argument will be "we can't upgrade our server to XQuantum-only! Look at
all these legacy SSL clients."

--Jacob

On Wed, Nov 24, 2021 at 2:53 PM Tom Lane <tgl@sss.pgh.pa.us> 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 the libpq bug, and the certainty that any
> other clients sharing the issue would have their own idiosyncrasies
> necessitating a custom-designed attack, I rather doubt that we're going
> to hear of anybody trying to exploit the issue in the field.

I don't know. The main thing that I find consoling is the fact that
most people probably have the libpq connection behind a firewall where
nasty people can't even connect to the port. But there are probably
exceptions.

> (By no means do I suggest that these bugs aren't worth fixing when we
> find them.  But so far they seem very easy to fix.  So moving mountains
> to design out just this one type of bug doesn't seem like a great use
> of our finite earth-moving capacity.)

I have enough trouble just moving the couch.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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 one bug
> that had a pretty localized fix is really moving the needle as far as
> that burden of proof is concerned.

I'm not suggesting that we rip it out today, for the record. I agree
with you on where the bar is for that.

--Jacob

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 24, 2021 at 2:53 PM Tom Lane <tgl@sss.pgh.pa.us> 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, not so much, precisely because we
couldn't find exciting exploits.

            regards, tom lane

On Wed, Nov 24, 2021 at 3:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Nov 24, 2021 at 2:53 PM Tom Lane <tgl@sss.pgh.pa.us> 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, not so much, precisely because we
> couldn't find exciting exploits.

Right, I understand that.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

On Tue, 2021-11-23 at 18:27 +0000, 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:

> = Client-Side Auth Selection =

There is interest in letting libpq reject certain auth methods coming
back from the server, perhaps using a simple connection option, and
there are some prior conversations on the list to look into.

> = 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 seems to be that the StartTLS-style
flow is currently sufficient from a security standpoint.

I didn't see any responses that were outright in favor, so I think my
remaining question is: are there any committers who think a prototype
would be worth the time for a motivated implementer?

Thanks for the discussion!

--Jacob

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 seems to be that the StartTLS-style
> flow is currently sufficient from a security standpoint.
> 
> I didn't see any responses that were outright in favor, so I think my
> remaining question is: are there any committers who think a prototype
> would be worth the time for a motivated implementer?

I'm quite interested in this.  My next question would be how complicated 
it would be.  Is it just a small block of code that peaks at a few bytes 
and decides it's a TLS handshake?  Or would it require a major 
restructuring of all the TLS support code?  Possibly something in the 
middle.

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 were tentatively
>> proposed. The general consensus seems to be that the StartTLS-style
>> flow is currently sufficient from a security standpoint.
>>
>> I didn't see any responses that were outright in favor, so I think my
>> remaining question is: are there any committers who think a prototype
>> would be worth the time for a motivated implementer?
> 
> I'm quite interested in this.  My next question would be how complicated
> it would be.  Is it just a small block of code that peaks at a few bytes
> and decides it's a TLS handshake?  Or would it require a major
> restructuring of all the TLS support code?  Possibly something in the
> middle.

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 easy to check for.

You could use recv(.., MSG_PEEK | MSG_WAITALL) flags to leave the bytes 
in the OS buffer. Not sure how portable that is, though. Alternatively, 
you could stash them e.g. in a global variable and modify 
secure_raw_read() to return those bytes first.

Overall, doesn't seem very hard to me.

- Heikki

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 easy to check for.
> 
> You could use recv(.., MSG_PEEK | MSG_WAITALL) flags to leave the bytes 
> in the OS buffer. Not sure how portable that is, though. Alternatively, 
> you could stash them e.g. in a global variable and modify 
> secure_raw_read() to return those bytes first.
> 
> Overall, doesn't seem very hard to me.

After further thought... Seems like sharing a port between implicit and
explicit TLS will still allow a MITM to put bytes on the wire to try to
attack the client-to-server communication, because they can craft the
SSLRequest themselves and then hand it off to the real client.

But they shouldn't be able to attack the server-to-client communication
if the client is using implicit TLS, so it's still an overall
improvement? I wonder if there are any other protocols out there doing this.

--Jacob