Andrew Gierth wrote:
>>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> >> I wonder if we can do something diffie-hellman'ish, where we have
> >> a parameter exchanged in the initial SSL'ed handshake, which is
> >> later used to generate new cancel keys each time the previous one
> >> is used.
>
> Tom> Seems like the risk of getting out of sync would outweigh any
> Tom> benefits. Lose one cancel message in the network, you have no
> Tom> hope of getting any more accepted.
>
> 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 does away with the sharead memory hackery - we
just need to store one more number in the postmaster array, which
shouldn't be a problem.
> Migration to this could probably be handled without a version change
> to the protocol, by defining a new SecureCancelRequest message and a
> GUC to control whether the old CancelRequest message is accepted or
> ignored.
We could even have a third setting - accept, but write a warning to the log.
> The key length for the cancel key can be increased with a
> minor-version change to the protocol (if client asks for protocol 3.1,
> send it a longer key, otherwise a shorter one).
Yeah, that seems easy enough. The question is how important is it to
increase the cancel key length? Should we do it now, or should we push
it off until whenever we have to bump the protocol version number anyway?
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. But it's probably too big a change for that?
/Magnus