Re: Banning TLS renegotiation
On Tue, Oct 03, 2017 at 12:08:36PM +0100, Daniel P. Berrange wrote:
> On Tue, Oct 03, 2017 at 11:32:56AM +0100, Richard W.M. Jones wrote:
> > I implemented TLS support in nbdkit last week.
> >
> > As part of this I came across an unusual corner of the TLS protocol
> > called ‘renegotiation’, where — in mid-stream — either peer can
> > request at the TLS level that the TLS handshake is performed again.
> >
> > I found a good explanation of why you might want to do this in the
> > context of web servers here:
> >
> > https://security.stackexchange.com/questions/24554/should-i-use-ssl-tls-renegotiation/24569#24569
> >
> > I don't think there is any case where NBD can renegotiate the
> > exportname mid-stream, so this does not apply to NBD.
> >
> > either qemu (client or server) nor nbdkit (server) implement this. I
> > didn't check other implementations in detail, but I would note that
> > with GnuTLS renegotiation is *not* handled transparently. What
> > happens is that any call to gnutls_record_recv can return
> > GNUTLS_E_REHANDSHAKE and the peer must decide either to perform the
> > handshake (calling gnutls_rehandshake[1]) or to drop the connection.
> > So doing this would complicate the implementation of NBD clients and
> > servers.
> >
> > As this feature is not needed, I think the NBD protocol doc should
> > explicitly ban it, or at least say that conforming servers and clients
> > are allowed to immediately terminate peers which try to perform
> > renegotiation.
>
> In TLS any client or server supporting renegotiation already has to
> deal with fact that their peer might reject the request to renegotiate.
> There is defined behaviour for TLS / GNUTLS about how to reject such a
> request in a graceful manner.
Even to deny a handshake, the server must check every call to
gnutls_record_recv for GNUTLS_E_REHANDSHAKE and send an alert
(gnutls_alert_send (GNUTLS_A_NO_RENEGOTIATION)). Plus the client also
has to be modified to handle alerts (ie. checking every return code
for GNUTLS_E_WARNING_ALERT_RECEIVED and handling it).
So this could be complex for an implementation. Remember that when
this happens we're somewhere deep in the stack in the data phase of
the connection.
What is the client trying to achieve by renegotiating? Is it ever a
valuable thing to do?
> So I think defining that the peer is allowed to terminate the connection
> is not required or desirable from NBD POV
>
> At most I would think that we could say
>
> "NBD servers and clients should not assume that the peer will
> support TLS renegotiation"
>
> if they wish to try renegotiation anyway, leave it upto the TLS library
> and app code as to what happens upon rejection.
nbdkit will currently drop the connection abruptly if the client
tries this, and I think this should be conforming behaviour.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
Reply to: