This bug has not been fixed, but it is on the TODO list:
o Prevent query cancel packets from being replayed by an attacker,
especially when using SSL
I am going to consider this item closed meaning I am not going to track
that it is fixed for 8.4; it is just documented on our
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Gierth wrote:
2. The server accepts either the old-style or the secure cancel
request from the client, but doesn't allow old-style requests
once a valid secure request has been seen.
Hmm, I think there should be a way to turn
Magnus == Magnus Hagander [EMAIL PROTECTED] writes:
[snip]
I'm looking (at Magnus' suggestion) at implementing this.
There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recording the
Andrew Gierth wrote:
There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recording the new value of N on success. This
is obviously fairly easy in the EXEC_BACKEND case, but it seems
Alvaro Herrera [EMAIL PROTECTED] writes:
Andrew Gierth wrote:
2. The server accepts either the old-style or the secure cancel
request from the client, but doesn't allow old-style requests
once a valid secure request has been seen.
Hmm, I think there should be a way to turn off acceptance of
Tom == Tom Lane [EMAIL PROTECTED] writes:
Andrew Gierth wrote:
2. The server accepts either the old-style or the secure cancel
request from the client, but doesn't allow old-style requests
once a valid secure request has been seen.
Hmm, I think there should be a way to turn off
Added to TODO:
* Prevent query cancel packets from being replayed by an attacker,
especially when using SSL
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php
---
Heikki Linnakangas wrote:
It
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Gierth wrote:
That's easily solved: when the client wants to do a cancel, have it
send, in place of the actual cancel key, an integer N and the value
HMAC(k,N) where k is the cancel key. Replay is prevented by requiring
the
Tom Lane wrote:
[ thinks for a bit... ] You could make it a change in the cancel
protocol, which is to some extent independent of the main FE/BE
protocol. The problem is: how can the client know whether it's okay to
use this new protocol for cancel?
Two options:
a. Send two cancelkeys in rapid
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that's the point that will require a protocol bump, I think. Since
there is no response to the cancel packet, we can't even do things like
sending in a magic key and look at the response (which would be a rather
ugly hack, but doable if we had a
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Yeah, that's the point that will require a protocol bump, I think. Since
there is no response to the cancel packet, we can't even do things like
sending in a magic key and look at the response (which would be a rather
ugly hack,
Magnus Hagander wrote:
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
We could have the server indicate it's the new protocol by sending the
initial
cancel key twice. If the client sees more than one cancel key it
automatically
switches to new-style cancel messages.
That
Stephen R. van den Berg wrote:
Magnus Hagander wrote:
Gregory Stark wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
We could have the server indicate it's the new protocol by sending the
initial
cancel key twice. If the client sees more than one cancel key it
automatically
switches to
Magnus Hagander [EMAIL PROTECTED] writes:
What would work is using a parameter field, per Stephen's suggestion
elsewhere in the thread. Older libpq versions should just ignore the
parameter if they don't know what it is.
+1 for that one; we have done it already for several send-at-startup
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
What would work is using a parameter field, per Stephen's suggestion
elsewhere in the thread. Older libpq versions should just ignore the
parameter if they don't know what it is.
+1 for that one; we have done it already for several
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Server accepts two different styles of cancel messages, identified
by different protocol numbers.
With the additional point that there is a GUC variable to turn this off
or warn about it, right?
I see pretty much no value in that.
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
* Server accepts two different styles of cancel messages, identified
by different protocol numbers.
With the additional point that there is a GUC variable to turn this off
or warn about it, right?
I see pretty
Tom Lane [EMAIL PROTECTED] wrote:
BTW, should we make all of this conditional on the use of an SSL
connection? If the original sending of the cancel key isn't secure
against sniffing, it's hard to see what anyone is buying with all
the
added computation.
+1
All of our important
On 8/8/08, Heikki Linnakangas [EMAIL PROTECTED] wrote:
It occurred to me a while ago that our query cancel messages are sent
unencrypted, even when SSL is otherwise used. That's not a big issue on its
own, because the cancellation message only contains the backend PID and the
cancellation key,
On Wed, 13 Aug 2008, Marko Kreen wrote:
On 8/8/08, Heikki Linnakangas [EMAIL PROTECTED] wrote:
One idea for fixing this is to make cancellation keys disposable, and
automatically issue a new one through the main connection when one is used,
but that's not completely trivial, and requires a
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
The problem was (third IIRC here :-P) in other clients, such as the JDBC
driver (I think that one was checked specifically) which currently only
accept the BackendKeyData message during startup. All drivers not based
on libpq would
Andrew Gierth wrote:
Tom == Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if we can do something diffie-hellman'ish, where we have
a parameter exchanged in the initial SSL'ed handshake, which is
later used to generate new cancel keys each time
Magnus Hagander [EMAIL PROTECTED] writes:
Andrew Gierth wrote:
That's easily solved: when the client wants to do a cancel, have it
send, in place of the actual cancel key, an integer N and the value
HMAC(k,N) where k is the cancel key. Replay is prevented by requiring
the value of N to be
Tom == Tom Lane [EMAIL PROTECTED] writes:
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if we can do something diffie-hellman'ish, where we have
a parameter exchanged in the initial SSL'ed handshake, which is
later used to generate new cancel keys each time the previous one
is
Tom Lane napsal(a):
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if we can do something diffie-hellman'ish, where we have a
parameter exchanged in the initial SSL'ed handshake, which is later used
to generate new cancel keys each time the previous one is used.
Seems like the risk of
It occurred to me a while ago that our query cancel messages are sent
unencrypted, even when SSL is otherwise used. That's not a big issue on
its own, because the cancellation message only contains the backend PID
and the cancellation key, but it does open us to a replay attack. After
the
Heikki Linnakangas wrote:
One idea for fixing this is to make cancellation keys disposable, and
automatically issue a new one through the main connection when one is
used, but that's not completely trivial, and requires a change in both
the clients and the server. Another idea is to
Alvaro Herrera [EMAIL PROTECTED] writes:
I wonder if we can do something diffie-hellman'ish, where we have a
parameter exchanged in the initial SSL'ed handshake, which is later used
to generate new cancel keys each time the previous one is used.
Seems like the risk of getting out of sync would
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
One idea for fixing this is to make cancellation keys disposable, and
automatically issue a new one through the main connection when one is
used, but that's not completely trivial, and requires a change in both
the clients and the
Magnus Hagander [EMAIL PROTECTED] writes:
The problem was (third IIRC here :-P) in other clients, such as the JDBC
driver (I think that one was checked specifically) which currently only
accept the BackendKeyData message during startup. All drivers not based
on libpq would have to be checked
30 matches
Mail list logo
