openssl secure renegotiation (not supported)

Question

I'm running a web service implemented on Ubuntu 14.04 LTS server. I'm debugging TLSv1 connection breaking after some time between a client using openssl version 0.9.7m and a server using openssl 1.0.1f. I don't have access to the client side myself, only to the server and the router. When I run openssl s_server in place of the server I see the message secure renegotiation not supported when the client connects. Renegotiation doesn't necessarily have anything to do with the connection problems but I'm trying to understand renegotiation. So far I haven't been able to find answers to following questions:

1. What are the typical triggers for renegotiation? Is it done insecurely if secure negotiation is not supported?
2. Is the renegotiation initiated by client or server code or can openssl initiate it in certain point?
3. Is there a way to force renegotiation with openssl s_server and/or openssl s_client to experiment with it?

Answer 1

There are four types of renegotiation possible:

• Client-initiated secure renegotiation
• Client-initiated insecure renegotiation
• Server-initiated secure renegotiation
• Server-initiated insecure renegotiation

Since the discovery of the possibility to perform renegotiation attacks (CVE-2009-3555), a vulnerability that exists "on all current versions of TLS", it's safe to assume that renegotiation won't be performed safely unless both client and server implement TLS Renegotiation Indication Extension.

OpenSSL first reaction was to disable renegotiation, with secure renegotiation being implemented on a later release.

A client using 0.9.7m, by definition, pre-dates CVE-2009-3555 and is both susceptible to this attack and also unable to perform secure renegotiation.

As to what can trigger renegotiation, you can track that in different RFCs: TLS v1.0, TLS v1.1, TLS v1.2. Different blog posts analising CVE-2009-3555 also provide details as to when this happens.

And regarding whether this can be forced from the s_client subcommand for testing purposes, yes, this is documented in the manual page:

CONNECTED COMMANDS
If a connection is established with an SSL server then any data received from the server is displayed and any key presses will be sent to the server. When used interactively (which means neither -quiet nor -ign_eof have been given), the session will be renegotiated if the line begins with an R [...]

It is also possible to do this programatically.