On Wed, 13 Aug 2008, Marko Kreen wrote:
> On 8/8/08, Heikki Linnakangas <heikki@enterprisedb.com> 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.
>
> 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.
Because libpq PQcancel needs to be callable from a signal handler. There's
limitations on what you can safely do in a signal handler, and calling an
external SSL library probably isn't safe, at least not on all platforms.
It certainly would be possible for many other clients like JDBC, though.
In fact, we might want to do that anyway, even if we change the protocol,
just on the grounds that it's surprising that the cancellation isn't SSL
protected while the rest of the protocol is. In theory, one might have a
strict firewall rule that only let's through SSL connections, or you might
want to hide the fact that a query is being cancelled from eavesdroppers,
or the PID. It's a bit far-fetched and I doubt anyone cares in practice,
but for the clients that it's easy to do, I think we should.
- Heikki
