[nginx] nginx使用SNI功能的方法

ⅰ亾dé卋堺 提交于 2019-12-02 03:09:53

概念

我们已经知道什么SNI,已经如果为用户配置SNI。

[nginx] nginx使用SNI功能的方法

 

问题

通过配置,可以发现,针对每一个SSL/TLS链接, nginx都会动态的查找与加载找到正确的证书。

那么在这个过程中,与没有SNI配置的情况下,有什么性能异同呢?

通过对这不部分的源码分析,将给出答案。

(不关注源码的话,可以直接翻到后文查看“结论”章节。)

 

 

分析

如上图所示

1 模块

nginx使用两个模块(这里只针对http进行分析,stream请自行类推),ngx_openssl_module 与

ngx_http_ssl_module。其中前者为核心模块。后者为http模块。

核心模块会被master进程调用ngx_ssl_init()函数进行加载,完成全局处理,包括对openssl的初始化。

http模块将由http框架完成处理,可以分为配置阶段与connection的解析阶段。

 

2  配置阶段

见图中的红框“流程二”。这个阶段就是逐行处理配置文件的阶段。在这个阶段里,merge ssl server config的时候,

http_ssl将判断是否配置了SNI功能。

 

如果没有配置,将调用ngx_ssl_certificate()函数加载证书链里边的所有证书

,将其读进内存并保存在全局配置文件的ctx结构体呢。ctx结构体是openssl api中的全局上下文,会作为参数传入

给openssl的api,openssl在处理连接是,会将ctx里的证书链拷贝(由SSL_new接口完成)到connect结构里,

openssl的connect结构的作用域是tls连接级别。

 

如果配置了SNI,http_ssl_module将不会加载证书链,而是将配置中的变量解析编译好备用,为运行时做好准备。

同时,还会通过openssl的SSL_CTX_set_cert_cb()函数设置一个回调函数 ngx_http_ssl_certificate(), 该函数会在

ssl握手之前进入,给用户一个修改证书信息的机会。该回调是在SSL_do_handshake()中完成的。

# man SSL_CTX_set_cert_cb
cert_cb() is the application defined callback. It is called before a certificate will be used by a client or server. The callback can then inspect the passed ssl structure and set or clear any appropriate certificates. 

 

3 请求阶段

如图红框“流程三”

在请求阶段,是否SNI是不被nginx感知的。所有与SNI相关的逻辑都会在前文设置的回调函数 ngx_http_ssl_certificate()

中完成。nginx框架与ssl模块只是正常的完了逻辑处理。

在回调函数中,首先会申请一个request结构体,作为中间存储。然后通过openssl的BIO接口完成证书链的加载,并关联至

openssl的connect结构里。然后,刚刚申请的request会被释放(这里边新建了一个pool,这个pool是从操作系统申请的内存)。

该过程与配置阶段共同复用了函数 ngx_ssl_load_certificate(), 整个过程都没有全局上下文ctx的参与,链接结束后证书链会被释放掉。

下次新的链接会重新再加载一次证书链。

 

4 openssl

分别观察有SNI和没有SNI的两个流程,将发现api的调用序列上有如下区别,关键在于是否使用ctx上下文。

无sni的时候,使用SSL_CTX_use_certificate()函数,有sni的时候,使用SSL_use_certificate()函数。

查找文档,对比一下区别:

# man SSL_CTX_use_certificate
The SSL_CTX_* class of functions loads the certificates and keys into the SSL_CTX object ctx. The information is passedto SSL objects ssl created from ctx with SSL_new(3) by copying, so that changes applied to ctx do not propagate to already existing SSL objects.

The SSL_* class of functions only loads certificates and keys into a specific SSL object. The specific information is kept, when SSL_clear(3) is called for this SSL object.

从侧面印证我们的分析结果,感兴趣的可以完整的阅读手册,这里不在赘述。

 

5 实验

截止到目前所有的分析都是基于nginx的,将openssl作为黑盒。并不能严谨的排除openssl为此做了特别优化,去防止多次加载

证书链的可能。 为了印证分析,做如下实验,配置SNI后,使用相同的证书多次请求。通过gdb观察,是否每次都进入回调函数并重新加载

证书链。

616         if (ngx_strncmp(cert->data, "data:", sizeof("data:") - 1) == 0) {
(gdb) n
627             if (ngx_get_full_name(pool, (ngx_str_t *) &ngx_cycle->conf_prefix, cert)
(gdb) 
634             bio = BIO_new_file((char *) cert->data, "r");
(gdb) 
635             if (bio == NULL) {
(gdb) 
643         x509 = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);
(gdb) bt
#0  ngx_ssl_load_certificate (pool=0x55825f636240, err=0x7ffd32750868, cert=0x7ffd32750900, chain=0x7ffd32750870) at src/event/ngx_event_openssl.c:643
#1  0x000055825ed31d79 in ngx_ssl_connection_certificate (c=0x55825f64c0c0, pool=0x55825f636240, cert=0x7ffd32750900, key=0x7ffd32750910, passwords=0x55825f0df860 <empty_passwords.29651>) at src/event/ngx_event_openssl.c:546
#2  0x000055825ee378ef in ngx_stream_ssl_certificate (ssl_conn=0x55825f632c70, arg=0x55825f63def0) at src/stream/ngx_stream_ssl_module.c:530
#3  0x00007efed0277b3c in tls_post_process_client_hello () from /opt/openssl/lib/libssl.so.1.1
#4  0x00007efed026d362 in state_machine () from /opt/openssl/lib/libssl.so.1.1
#5  0x00007efed0265991 in SSL_do_handshake () from /opt/openssl/lib/libssl.so.1.1
#6  0x000055825ed33f27 in ngx_ssl_handshake (c=0x55825f64c0c0) at src/event/ngx_event_openssl.c:1683
#7  0x000055825ed34671 in ngx_ssl_handshake_handler (ev=0x55825f66dec0) at src/event/ngx_event_openssl.c:1992
#8  0x000055825ed2dae8 in ngx_epoll_process_events (cycle=0x55825f62d4a0, timer=60000, flags=1) at src/event/modules/ngx_epoll_module.c:957
#9  0x000055825ed185cf in ngx_process_events_and_timers (cycle=0x55825f62d4a0) at src/event/ngx_event.c:242
#10 0x000055825ed2a4d4 in ngx_worker_process_cycle (cycle=0x55825f62d4a0, data=0x0) at src/os/unix/ngx_process_cycle.c:759
#11 0x000055825ed26305 in ngx_spawn_process (cycle=0x55825f62d4a0, proc=0x55825ed2a3d4 <ngx_worker_process_cycle>, data=0x0, name=0x55825ee6e4fb "worker process", respawn=-3) at src/os/unix/ngx_process.c:199
#12 0x000055825ed29018 in ngx_start_worker_processes (cycle=0x55825f62d4a0, n=1, type=-3) at src/os/unix/ngx_process_cycle.c:359
#13 0x000055825ed284fb in ngx_master_process_cycle (cycle=0x55825f62d4a0) at src/os/unix/ngx_process_cycle.c:131
#14 0x000055825ecdf1d9 in main (argc=1, argv=0x7ffd327511a8) at src/core/nginx.c:382
(gdb) 

(留个调用栈,方便以后看。)

通过实验,证书每次都会通过api BIO_new_file 进行重新加载,除非该函数做了优化,否则每次链接的每个证书将发生磁盘IO操作。

 

结论

配置了SNI功能之后,nginx对TLS链接请求的处理将产生性能损失。损失的粒度为每链接级别。

每个tls链接将多发生:一次内存申请与释放;一组加载证书链上全部证书的磁盘IO。

 

改进方案

我认为内存的申请可以忽略,因为原本处理request的时候也是需要想OS申请内存的。比较关键的在于磁盘IO。

第一个方案,可以将所有证书放置在内存文件系统中,此方案不需要调整代码。

第二个方案,重写ngx_http_ssl_certificate(), 虽然证书是动态选择的,但是只要在备选集合确定的情况下,我们依然

可以进行预加载,去除掉运行时的IO。引入的限制为:1备选集合不能实时变更,2证书集合元素数量需要设置上限。

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!