From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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-17 08:36:47 |
Message-ID: | 48A7E31F.20206@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Andrew Gierth wrote:
>>> 2. The server accepts either the old-style or the secure cancel
>>> request from the client, but doesn't allow old-style requests
>>> once a valid secure request has been seen.
>
>> Hmm, I think there should be a way to turn off acceptance of old-style
>> without necessarily requiring a new-style request. Otherwise, how are
>> you protected from DoS if you have never sent a cancel request at all?
>
> Assuming you were using SSL, it's hard to see how an attacker is going
> to get your cancel key without having seen a cancel request.
Not only that, but he'll have to see an *old-style* cancel request,
since the new style doesn't contain the key.
And if you're *not* using SSL, the attacker can just sniff they key off
the initial packet instead.
> However, I dislike Andrew's proposal above even without that issue,
> because it means *still more* changeable state that has to be magically
> shared between postmaster and backends. If we want to have a way for
> people to disable insecure cancels, we should just have a postmaster
> configuration parameter that does it.
Agreed. Your security policy also should not depend on what your client
happens to do, it should be enforceable.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-08-17 11:51:39 | Re: proposal sql: labeled function params |
Previous Message | Pavel Stehule | 2008-08-17 06:06:43 | Re: proposal sql: labeled function params |