Re: Banning TLS renegotiation

[Wouter Verhelst <w@uter.be>]

On Wed, Oct 04, 2017 at 08:39:38AM +0100, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 08:26:49PM +0200, Wouter Verhelst wrote:
> > On Tue, Oct 03, 2017 at 02:59:31PM +0100, Richard W.M. Jones wrote:
> > > On Tue, Oct 03, 2017 at 02:48:55PM +0100, Daniel P. Berrange wrote:
> > > > I would say
> > > > 
> > > >   "a peer  SHOULD follow the TLS protocol spec for accepting
> > > >    or rejecting a renegotiation, but MAY close the connection
> > > >    abruptly"
> > > 
> > > How about this extension of the above:
> > > 
> > >   "A peer SHOULD follow the TLS protocol spec for accepting
> > >   or rejecting a renegotiation, but MAY close the connection
> > >   abruptly.  If the peer accepts renegotiation then it MUST
> > >   follow RFC5746, and it MAY limit the number of times per
> > >   connection that renegotiations are permitted in order to
> > >   prevent a possible Denial of Service attack."
> > 
> > I can think of one situation where TLS renegotiation would be necessary
> > or valid in an NBD context: if a client tries to connect to an export
> > which requires client certificate, but a server has several exports and
> > some do not. In that case, the client would do STARTTLS (the server
> > necessarily allowing a negotiation without certificates), and then send
> > NBD_OPT_GO for a certificate-requiring export. and then receive a
> > renegotiation request from the server so that it can provide a
> > certificate. The server shouldn't ask for renegotation followed by a
> > NBD_REP_ACK in that case (to mitigate the mitm-vulnerability in
> > renegotiation that was pointed to earlier), but instead some error, then
> > perform the renegotiation, and then the client should try the NBD_OPT_GO
> > again.
> 
> We shouldn't try to workaround TLS flaws in a layer above it, as that kind
> of approach has a fine history of security screw ups. 

Fair enough.

Giving it more thought, though, it makes precious little difference,
because a client which does not perform TLS renegotiation and which
suddenly receives a renegotation request would have to produce an error
message to a user, and then it would be helpful to have a human-readable
error message in the NBD_REP_ERR_RENEG_REQD payload rather than to have
to produce a cryptic error message from the TLS library in use...

We might perhaps want to drop the "must not retain state" part of my
proposal, though.

[...]

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
     Hacklab