Replay attack of query cancel

It occurred to me a while ago that our query cancel messages are sent 
unencrypted, even when SSL is otherwise used. That's not a big issue on 
its own, because the cancellation message only contains the backend PID 
and the cancellation key, but it does open us to a replay attack. After 
the first query in a connection has been cancelled, an eavesdropper can 
reuse the backend PID and cancellation key to cancel subsequent queries 
on the same connection.

We discussed this on the security list, and the consensus was that this 
isn't worth a quick fix and a security release, because
- it only affects applications that use query cancel, which is rare
- it only affects SSL encrypted connections (the point is moot 
non-encrypted connections, as you can just snatch the cancel key from 
the initial message)
- it only let's you cancel queries, IOW it's only a DOS attack.
- there's no simple fix.

However, it is something to keep in mind, and perhaps fix for the next 
release.

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.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com