Renegotiation is disabled in 0.9.8l due to the prefix-injection attack flaw that the IETF/TLS group just approved a draft standard to fix.
I expect 0.9.8m to have the new renegotiation semantics enabled. Until then, you can go back to 0.9.8k -- just be aware that renegotiation cannot be performed within the guarantees that TLS otherwise makes (namely, that the endpoint cannot be arbitrarily changed without collusion between the old and new endpoints). The attack is simple: 1) Set up a secure webserver, with an (innocent) file that you don't want accessed, somewhere. This is 'server'. (This demo works better if it's in a directory that requires a client certificate for access.) 2) Set up a TLS client endpoint and a server endpoint in the same process, preferably somewhere else. We'll call this the 'proxy'. 3) Arrange DNS such that the name that server thinks it has (the HostName directive in Apache) actually goes to proxy. 4) Attack: a) Client connects to HostName, ends up talking to proxy. It sends ClientHello, but it doesn't necessarily receive an answer immediately. b) proxy makes connection to server over TLS. c) proxy sends something like GET /file/you/don't/want/shown HTTP/1.1 \n Host: server \n\n d) proxy then sends ClientHello from client and passes it to server, and transparently proxies the connection from here forward. e) server receives ClientHello and interprets it (per spec) as a request to renegotiate. f) (re)negotiation finishes, server thinks all data received can be treated as being under the same security veil, processes it (including prefix), and the attack is successful. Since there's no cryptographic verification of the prior state in the renegotiation (client thinks it's initial negotiation, server thinks it's a renegotiation, but there's no way within TLS to signal that), client and server then create new master_secrets. Then, server processes the entire request, including the prefix that the attacker injected. It has been suggested that this is an inherent flaw with how HTTP handles paths with different security characteristics, and I am inclined to agree -- a client/server pair that understands the difference between "pre-renegotiation data" and "post-renegotiation data" won't trip on this, even if renegotiation is "insecure". That's because such a pair would treat the data prior to the latest renegotiation's Finished messages as suspect (assuming that the client-server pair did mutual authentication), and generally (as a best practice) with suspect data from a potential attacker it's best to drop it. It is also, though, undeniably a flaw in the TLS specification that's amplified by the clients of the libraries that implement it -- because the clients don't understand the concept of "security veil", the TLS implementations tend to provide a raw stream of bytes (akin to a read()/write() pair) without the application necessarily being aware of the change. -Kyle H On Thu, Jan 7, 2010 at 12:50 PM, Lou Picciano <loupicci...@comcast.net> wrote: > Anyone have any ideas on this? > > Have recently updated an otherwise working environment to include openSSL > v0.9.8l. Suddenly, mod_ssl is reporting: > > Re-negotiation handshake failed: Not accepted by client!? > > Other than a refresh of CRL, this configuration has been running AOK through > openSSL 0.9.8k... > Before we embark on the complete rebuild of the server: Would a version of > mod_ssl compiled against 0.9.8k utterly choke on 0.9.8l? > > Many thanks in advance, Lou > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
