Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
>> One idea for fixing this is to make cancellation keys disposable, and
>> automatically issue a new one through the main connection when one is
>> used, but that's not completely trivial, and requires a change in both
>> the clients and the server. Another idea is to send the query cancel
>> message only after SSL authentication, but that is impractical for libpq
>> because we PQcancel needs to be callable from a signal handler.
>
> 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.
Seems much more complex than needed.
IIRC, the protocol allows us (at least does not explicitly forbid) to
issue new cancel keys at any time. And libpq will, again IIRC, accept
them. So we could just change the server to issue a new cancel key
whenever it has used the previous one (since the new key will then be
sent over the encrypted channel, we're safe).
The problem was (third IIRC here :-P) in other clients, such as the JDBC
driver (I think that one was checked specifically) which currently only
accept the BackendKeyData message during startup. All drivers not based
on libpq would have to be checked and potentially updated, but it's
sitll a lot easier than DHing or so.
//Magnus