APIs need ability to set ssl_verify_client per Location

[Greg Smethells]

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

​http://trac.nginx.org/nginx/ticket/317

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.

[Maxim Dounin]

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).

[Greg Smethells]

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?

[Greg Smethells]

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.

[Maxim Dounin]

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.

[Greg Smethells]

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?

[Greg Smethells]

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.

[Greg Smethells]

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