We're running Apache 2.2.22 with OpenSSL 0.98, one of our Citrix NetScaler Hosts cannot send a client certificate after handshaking SSL as we have to set SSLInsecureRenegotiation off as a security standard.

Is there anyway to dynamically set this directive based on Remote_Addr? I have tried so many settings but as designed I guess, there doesn't seem to be a way of selectively allowing SSLInsecureRenegotiation for one user agent or IP?

We've already patched to latest NetScaler 10, but after the SSL initial handshake a renegotiation request is sent back from Apache to the NetScaler because as a client cert is required for a LocationMatch, this is never responded to leading Apache to terminate session. - http://tools.ietf.org/html/rfc5746#section-3.5 . We're told by Citrix that downstream rules are normally on a "trusted" network, and not supported using the client method, is it possible to differentiate between requests and how the SSLInsecureRenegotiation directive is called by host identity of some sort or IP?

1 Answer
1

I could be incorrectly understanding the mod_ssl docs (but I don't believe I am) but if you have linked your Apache version to OpenSSL 0.98m or later and the client is also using a patched TLS implementation, the SSLInsecureRenegotiation directive set to Off should have no effect on those client connections.

Are you terminating SSL between client and NetScaler or is it passing through to the Apache servers and terminating there? Some load balancers behave like reverse proxies and if you're terminating ssl at the load-balancer, the load-balancer needs to be configured to accept the renegotiated connection attempt.

The easiest way to tell if it is your load-balancer causing this is to bypass the load-balancer and fire the request off directly against your apache server. If you succeed, the load-balancer's virtual server and/or ssl/tls configuration needs to be looked at. If that fails (and you are sure you are using a client with a patched TLS implementation), then there is still something wrong with the apache server configuration. You probably don't even need to test the directory requiring the client cert, just fire up openssl s_client -connect <host> <port> and press R, then enter. If it succeeds, it's probably the load-balancer. Based on a yahoo search, it looks like you can tell what the netscaler's policy is for handling renegotiated connections by running a show ssl parameter on the netscaler.

Hi, Many thanks for your reply, Citrix have basically said that when netscaler acts as a client, it never sends the extension as the backend zone is assumed to be on a secure network, it's not something that they have enabled or support running in client mode. - IE/Latest Browser - HTTP to NetScaler alias - HTTP-HTTPS rewrite + client certificate to Apache.. I believe the NetScaler doesn't reply as being able to securely renegotiate and the session is terminated. Is it possible to set this directive on (or other settings) if the client comes from a particular host identity?
–
ev4nsjJan 28 '13 at 14:49

I don't believe it can be set anywhere lower than virtual server level, which is why I'm thinking it needs to be addressed at the load-balancer, (despite what Citrix might say). They seem to have quite a few different values that TLS Renegotiation that can be set, including disabling renegotiation support between client and server altogether. Maybe posting this question over on serverfault will help?
–
mahnscJan 28 '13 at 18:55

Hi, problem is more that SSL offload is designed to operate in front of web servers, not clients end but unfortunately our project went ahead regardless. Citrix have not fully implemented RFC 5746 extension to prevent man-in-the-middle attacks out the backend as they consider the backend behind the Netscaler (Logical in this reversed context) a trusted channel, with a 3rd party hosting Apache with the strict security rules for all traffic. I could probably convince them to set a special case for our host, but can't find a way of setting the directive in-session.
–
ev4nsjJan 29 '13 at 9:40