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  (Magnus Hagander <magnus@hagander.net>)
Re: Replay attack of query cancel  ("Stephen R. van den Berg" <srb@cuci.nl>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: SeqScan costs
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Transaction-controlled robustness for replication