Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#498 closed enhancement (duplicate)

APIs need ability to set ssl_verify_client per Location

Reported by: Owned by:
Priority: major Milestone:
Component: nginx-core Version:
Keywords: Cc:
uname -a: Linux gsmethells 2.6.32-279.el6.x86_64 #1 SMP Thu Jun 21 07:08:44 CDT 2012 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.4.1


Our API and service design requires that there be a single server on a single (TLS) port and that clients are verified but only if sending requests to "/private/*.wsgi" and not our "/api/*.wsgi" public API location. A request to allow ssl_verify_client to be set per location would solve this issue cleanly. A ticket to address it was present in ticket 317; however, the response to

is insufficient to satisfy such needs since the author makes an over-simplication that client certificates apply to an entire server and a user of nginx would never need to apply client certificate verification at a granularity below that level. While server certificates may be applied to an entire server or not, client certificates do not follow this same paradigm. It is very common for only portions of a site to require authentication.

To circumvent this feature omission, our project is currently forced to not leverage the client verification portion of the TLS protocol! Instead, the project has implemented a proprietary verification solution at the WSGI layer, which from a rigorous stand point, is non-optimal when one is already present in TLS.

Apache allows per location SSL client verification while nginx lacks this feature. I believe nginx would be greatly improved by adding this feature as well.

Change History (7)

comment:1 Changed 5 years ago by mdounin

  • Resolution set to duplicate
  • Status changed from new to closed

As already said in ticket #317, there are no plans to add per-location client certificate verification. One of the possible solutions, already suggested in ticket #317, is keep servers which require client certificates separate from ones which don't. Obviously it will require changes in your setup to keep servers separate.

In a particular case of API, using ssl_verify_client optional may work for you (with an additional check of the $ssl_client_verify variable).

comment:2 Changed 5 years ago by

ssl_verify_client optional is broken with respect to WebSockets?. iOS 7 (mobile) Safari will NOT connect a WebSocket? if ssl_verify_client is set to OPTIONAL or ON.

I understand you have no such plans, but what is the technical reason for wanting to avoid doing it?

comment:3 Changed 5 years ago by

From a business perspective, where we install a medical server on-site at the customer, it is not feasible to have more than one server (physical or virtual). Of course, physical costs more money so that's out. Another virtual server means either different FQDNs for different purposes and with users (and UX in general) that is not going to result in a successful, easy-to-use product or opening up more than one port but opening up one port is already a large hurdle as-is with most hospitals. It's a lose-lose proposition.

The flexibility for design is significantly improved when the granularity for when client cert verification is done can be on either a per server or per location basis. I can only assume this flexibility gain is not in doubt; therefore, there is some technical reason why all designed are forced into doing this only at the server granularity.

comment:4 Changed 5 years ago by mdounin

Technical reasons are quite simple - client certificates are requested during SSL handshake, and when this happens a request location isn't yet known. In theory, there is renegotiation which allows to do another handshake when needed and request a certificate. But this approach implies lots of things to care about as various SSL parameters may change, potentially requiring quite a different processing in various places - in particular, configuration-controlled processing like server rewrites. Teaching nginx to do so would be a pain, and may also lead to various attacks in addition to one already linked above.

comment:5 Changed 5 years ago by

What is the nginx's group's stance on RFC 5746 then? If it alleviates the technical concerns, then the "pain" you speak of is simply a rejection of the additional complexity, which honestly, to me feels like a poor reason to not hang on to this enhancement idea. I understand it may not happen in the near future regardless, but what is so wrong with putting this idea in the enhancement backlog for when the RFC comes to fruition?

comment:6 Changed 5 years ago by

Is there any technical solution to our problem using nginx as the basis: the constraints are there is to be one "server { ... }" section thus one "server_name" and one "port" (our technical constraints for all practical purposes given our highly regulated environment) where ssl_verify_client can be used (likely set to "optional") such that both regular TCP sockets and WebSockets? will connect successfully to the port and the resulting request environment (python WSGI) will know both whether a client cert was provided and if it was verified successfully?

At the moment, the latest iOS Safari fails to connect a WebSocket? if ssl_verify_client is set to "optional" when it ought to connect and forward it upstream to tornado. So, at the moment, the answer is 'no'. Perhaps this is simply due to this bug, which I will submit separately.

We also intended to support Chrome and Mozilla for this web app which uses JSON-RPC over Secure WebSockets? to achieve client-server interaction with no page reload.

comment:7 Changed 5 years ago by

Ticket 499 now covers this ssl_verify_client issue and explains the design issues in more detail.

Note: See TracTickets for help on using tickets.