Re: SSL renegotiation

On Thu, Jul 11, 2013 at 1:13 AM, Sean Chittenden <sean(at)chittenden(dot)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.