ssl_certificate_by_lua_file - set ciphers too?

[rkearsley]

Hello Currently using ssl_certificate_by_lua_file with great success, thank you! We have a request from one customer to only allow very secure ciphers, but the other customers would not like this. Is there a way to set the ciphers dynamically too?

Thanks Richard

[agentzh]

@lziest @ghedo Is it possible? ;)

My hunch is that it might be too late in this phase.

[rayward]

We have a similar requirement where some clients require stricter ssl. So we're also needing the ability to set ciphers (and the protocols, eg. tls 1.1, 1.2) dynamically on a per request basis.

[agentzh]

@rayward You are welcome to do experiments and contribute patches :)

[ghedo]

Sorry I'm a bit late :)

Yes, it is possible to set cipher suites inside the certificates callback, but you need some support from C. I made https://github.com/openresty/lua-nginx-module/pull/961 which adds a new FFI function to set SSL ciphers.

Once that's merged it should be trivial to add a Lua function to the ngx.ssl module.

[ghedo]

On the other hand it is not possible to enable/disable protocol versions, since the callback is run too late. And it's certainly not possible to set ciphers or protocols on a per-request basis (you can only do it during the initial connection handshake).

[rayward]

@ghedo thanks for jumping on this! per-connection rather than per-request works for us.

I wonder if it would be possible to support dynamic protocols with a change to the nginx/openresty core such that the IP (and SNI header?) of an incoming connection could be provided to a callback before the handshake is completed.

[ghedo]

Well, if all you need is the client or target server IP to make a decision then yes, you can do that after the TCP connection is established but before the TLS handshake starts, but you would need to modify the nginx code to do that (and I don't think the nginx and openresty developers would be much in favour of merging such changes).

As far as SNI goes, OpenSSL does provide a callback like you describe, but that too is called too late, after a version has already been picked by the server. To support what you need would also require patches to OpenSSL in order to add an additional callback there.

Maybe worth noting is that BoringSSL does provide a callback that can be used to set available protocols, howver it would need integration into ngx_lua (which doesn't support BoringSSL at all at the moment). But note that using BoringSSL in a production system is somewhat discouraged, due to the fast changing (and fast breaking) nature of the project.

[rayward]

Thanks for the insight, yeh I can understand that such a change would likely not go in. We'll have to stick with dynamically building nginx server blocks to meet our needs.