| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Replay attack of query cancel |
| Date: | 2008-08-13 04:20:55 |
| Message-ID: | 8857.1218601255@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
[ 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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2008-08-13 04:30:37 | Re: SeqScan costs |
| Previous Message | Tom Lane | 2008-08-13 04:14:33 | Re: temporary statistics option at initdb time |