On 22 Jan 2013 14h34 CET, mdounin@mdounin.ru wrote:

Hello again Maxim,

> Hello!
>
> On Tue, Jan 22, 2013 at 02:11:59PM +0100, António P. P. Almeida
> wrote:
>
>> On 22 Jan 2013 12h21 CET, mdounin@mdounin.ru wrote:
>>
>>> Hello!
>>
>> Hello Maxim,
>>
>> Thank you for your reply.
>>
>>> On Tue, Jan 22, 2013 at 11:21:44AM +0100, António P. P. Almeida
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I've not yet ventured into Nginx C module coding, but I would
>>>> like to know if changing the current SSL module directives:
>>>> ssl_certificate and ssl_certificate_key, so that instead of
>>>> strings they can be variables (complex values) is feasible, or
>>>> due to the fact that SSL happens below the protocol layer, is
>>>> much more difficult, than, for instance, the recent
>>>> transformation in variables of the auth_basic module directives?
>>>
>>> It is going to be much more difficult, as you have to reload
>>> certificates and keys into SSL context before asking OpenSSL to
>>> establish connection, and you'll likely need at least some caching
>>> layer in place to make things at least somewhat reasonable from
>>> performance point of view.
>>>
>>> Besides that, the only connection-specific info available when
>>> establishing SSL connection is remote address (in all cases) and
>>> server name indicated by a client (in case of SNI). Which makes
>>> it mostly useless, as remote address destinction is mostly useless
>>> (and/or should be done at layer 3), and server{} blocks are here
>>> to handle server name distinction.
>>
>> It's precisely for SNI in mass SSL hosting. Wouldn't be much more
>> efficient if there was a callback that returned the host (SNI) and
>> that would select a proper (cert, key) pair so that instead of
>> reloading we could proceed without having to reload the config?
>>
>> I would like for something of the kind.
>>
>> map $sni_host $cert {
>> example.net example.net.pem;
>> example.com example.com.pem;
>> ...
>> }
>>
>> map $sni_host $privkey {
>> example.net key.example.net.pem;
>> example.com key.example.com.pem;
>> ...
>> }
>>
>> Then in the server block:
>>
>> server {
>> listen 80;
>> listen 443 ssl;
>> server_name *.example.*;
>>
>> ssl_certificate $cert;
>> ssl_certificate_key $privkey;
>>
>> ...
>> }
>>
>> Also this will avoid having a plethora of server {}.
>
> As long as there will be cache layer to avoid re-reading certs -
> it might be efficient enough to be usable. It will require much
> more code than just adding variables support though, and things
> like OCSP stapling won't be available. Overall I would recommend
> using server{} blocks instead.

Thank you Maxim. So the thing to consider here is to tune correctly
the SSL session cache from the Nginx configuration point of view. That
besides the cipher suite and OS tweaking (TCP stack and buffers).

Using an http level SSL shared session cache, of course.

Is that about it or there's more?

Thank you,
--- appa

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel