On Thu, Jul 11, 2013 at 1:13 AM, Sean Chittenden <s...@chittenden.org> wrote: >> , I suppose two things can be done: >> >> 1. Quit the connection > > With my Infosec hat on, this is the correct option - force the client > back in to compliance with whatever the stated crypto policy is through > a reconnection. > >> 2. Carry on pretending nothing happened. > > This is almost never correct in a security context (all errors or > abnormalities must boil up). > >> I think 2 is correct in the vast majority of cases (as it looks like >> is being done now). > > That is a correct statement in that most code disregards renegotiation, > but that is because there is a pragmatic assumption that HTTPS > connections will be short lived. In the case of PostgreSQL, there is a > good chance that a connection will be established for weeks or months. > In the case of Apache, allowing a client to renegotiate every byte would > be a possible CPU DoS, but I digress....
And, allowing the client to refuse to renegotiate leaves the relevant vulnerability unpatched. Renegotiation was introduced to patch a vulnerability in which, without renegotiation, there was the possibility of an attacker gaining knowledge of session keys (and hence the ability to intercept the stream). I think 2 is not viable in this context. Only 1. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
