Re: Replay attack of query cancel
От | Tom Lane |
---|---|
Тема | Re: Replay attack of query cancel |
Дата | |
Msg-id | 8857.1218601255@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Replay attack of query cancel (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Replay attack of query cancel
Re: Replay attack of query cancel |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.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
В списке pgsql-hackers по дате отправления: