Обсуждение: 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