Re: Replay attack of query cancel

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Alvaro Herrera <alvherre(at)commandprompt(dot)com> 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.

Tom> Seems like the risk of getting out of sync would outweigh any
Tom> benefits. Lose one cancel message in the network, you have no
Tom> hope of getting any more accepted.

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.)

Migration to this could probably be handled without a version change
to the protocol, by defining a new SecureCancelRequest message and a
GUC to control whether the old CancelRequest message is accepted or
ignored. The key length for the cancel key can be increased with a
minor-version change to the protocol (if client asks for protocol 3.1,
send it a longer key, otherwise a shorter one).

--
Andrew (irc:RhodiumToad)