[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Banning TLS renegotiation



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.

Thoughts on this?

Rich.

[1] https://www.gnutls.org/manual/html_node/Re_002dauthentication.html

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/


Reply to: