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 T
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 b
> "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 w
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 accep
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 seem
> "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 recordin
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 occurre
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 ch
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
>>> 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 importan
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?
>
>
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 i
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
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
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
>>> automat
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 m
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
"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 w
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 rap
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 requi
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
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
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
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 get
> "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 previ
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 chec
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 t
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 w
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
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 first
30 matches
Mail list logo
