From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Gregory Stark <stark(at)enterprisedb(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-13 14:00:29 |
Message-ID: | 18248.1218636029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> What would work is using a parameter field, per Stephen's suggestion
> elsewhere in the thread. Older libpq versions should just ignore the
> parameter if they don't know what it is.
+1 for that one; we have done it already for several send-at-startup
parameters that didn't use to be there, eg standard_conforming_strings.
I'd go with defining it as the maximum cancel version number
supported, eg "cancel_version = 31", with the understanding that
if it's not reported then 3.0 should be assumed.
So the plan looks like this, I think:
* Main FE/BE protocol doesn't change, but there might be an additional
value reported in the initial ParameterStatus messages. We believe that
this will not break any existing clients.
* Server accepts two different styles of cancel messages, identified
by different protocol numbers.
* Client decides which type to send based on looking for the
cancel_version parameter.
This seems back-patchable since neither old clients nor old servers
are broken: the only consequence of using an old one is your cancels
aren't sent securely, which frankly a lot of people aren't going
to care about anyway.
Note after looking at the postmaster code: the contents of new-style
cancel keys ought to be the backend PID in clear, the sequence number in
clear, and the hash of backend PID + cancel key + sequence number.
If we don't do it that way, the postmaster will need to apply the hash
function for *each* backend to see if it matches, which seems like
a lot more computation than we want. The postmaster needs to be able to
identify which backend is the potential match before executing the hash.
The main drawback I can see to keeping this backward-compatible is that
keeping the cancel key to 32 bits could still leave us vulnerable to
brute force attacks: once you've seen a cancel message, just try all
the possible keys till you get a match, and then you can generate a
cancel that will work. Can we refine the HMAC idea to defeat that?
Otherwise we're assuming that 2^32 HMACs take longer than the useful
life of a cancel key, which doesn't seem like a very future-proof
assumption.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-08-13 14:09:36 | Re: Replay attack of query cancel |
Previous Message | Simon Riggs | 2008-08-13 14:00:24 | Re: Transaction-controlled robustness for replication |