proxy_ssl_certificate not exchanging client certificates
mdounin at mdounin.ru
Thu May 7 13:31:51 UTC 2015
On Wed, Apr 29, 2015 at 05:09:26PM -0400, lieut_data wrote:
> Thanks for getting back to me so quickly!
> Maxim Dounin Wrote:
> > What nginx doesn't support (or, rather, explicitly forbids) is
> > renegotiation. On the other hand, renegotiation is required if
> > one needs to ask for a client certificate only for some URIs, so
> > it's likely used in your case. You should see something like "SSL
> > renegotiation disabled" in logs at notice level.
> Yes, this is exactly the problem. With your hint, I commented out the
> relevant code in ngx_ssl_handshake and ngx_ssl_handle_recv -- and proxying
> worked flawlessly. (Interestingly, I never saw the log you identified
> because of SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS having been set on the openssl
> connection object.)
> I think I understand the gist of why nginx forbids client-initiated
> renegotiation (denial of service concerns? security concerns?), but I'm not
> well-versed in openssl enough to know if the same concerns apply to
> server-initiated renegotiation with nginx as the client, especially when it
> applies to cipher renegotiation as noted above.
> Would nginx be open to a patch that would make this use case feasible?
> Perhaps as a modification to only disable these renegotiations when nginx is
> the server in the SSL equation?
The renegotiation is disabled for security reasons since
CVE-2009-3555. While CVE-2009-3555 is believed to be mitigated by
Secure Renegotiation extension, renegotiation itself, even secure,
still allows various bad side effects if allowed: in particular,
peer credentials and/or ciphers used may be changed unexpectedly.
I don't think we care much about the above happening on an
upstream connection though, so patches are welcome. (Actually,
original patch I submitted back in 2009 did not touch upstream
connections at all, but Igor decided to disable renegotiation
More information about the nginx