>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> 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.) 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. 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). -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
