On 8/8/08, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > 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.
Why not establish SSL before sending cancel key? That way potential SSL auth is also enforced. I'm not against improving cancel protocol generally, also for non-SSL clients, but this seems orthogonal to SSL issue - if client uses SSL then I'd expect cancel packet also be sent over SSL. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers