Re: Replay attack of query cancel

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> 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 strictly greater than any previous value
>>> successfully used for this session. (Since we already have md5 code,
>>> HMAC-MD5 would be the obvious choice.)
>
>> I like this approach.
>
> It's not a bad idea, if we are willing to change the protocol.
>
>> If we don't touch the protocol version, we could in theory at least
>> backpatch this as a fix for those who are really concerned about this
>> issue.
>
> Huh? How can you argue this isn't a protocol change?

Um. By looking at it only from the backend perspective? *blush*

> [ 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?

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 success/fail response to the cancel
packet).

I guess bumping the protocol to 3.1 pretty much kills any chance for a
backpatch though :( Since a "new libpq" would no longer be able to talk
to an old server, if I remember the logic correctly?

//Magnus