Nginx反向代理，当后端为Https时的一些细节和原理

我就是我 2024-04-01 16:07 79阅读 0赞

### 背景 ###

最近在写一个管理后台，在参考阿里云`CDN`交互的时候，其中一个叫**回源SNI**的参数项引起了我的注意，

![a2da241a9fb2352ddde226fda88879d0.png][]

虽然知道[SNI][]且工作中Nginx上游也有用Https的情况，但并未留意过需要做特别配置，感觉可能触发到知识盲区，一番查询后发现Nginx有一个`proxy_ssl_server_name`参数与此相似。

Syntax:	proxy_ssl_server_name on | off;
    Default:	
    proxy_ssl_server_name off;
    Context:	http, server, location
    This directive appeared in version 1.7.0.
    
    Enables or disables passing of the server name through TLS Server Name Indication extension (SNI, RFC 6066) when establishing a connection with the proxied HTTPS server.

当端服务器为Https，反向代理时是否开启`SNI`，它的默认值竟然是`off`。一个IP绑定多个域名很常见，为什么默认不启用呢？

光看文档我还觉得不够，还去看了下源码，[SNI][]的处理必调用`SSL_set_tlsext_host_name`函数，搜索`SSL_set_tlsext_host_name`函数就能快速定位相关逻辑。

![547754b72ed087ebb7a406edf777d58d.png][]

参数默认关闭，当开启时，在SSL握手的时候会把`HostName`传给上游服务器，以便上游服务器知道用哪个证书。

使用已经知道了，接下来来测试下。

### 验证 ###

将我自己的博客做上游服务器做测试，拓扑如下：

> \-> www.dianduidian.com -> blog.dianduidian.com

先用最简单的配置

server {
            listen       80;
            server_name  www.dianduidian.com;
            location / {
              proxy_pass https://blog.dianduidian.com;
            }
        }

没问题，能正常打开，我们抓包来看看Nginx是如何与上游服务器建立连接的。

![4515919d5b1e16b58d1b3b6e72aadf18.png][]

可以看到TLS握手阶段，Nginx在向上游服务器发送`Client Hello`消息时没有带上[SNI][]信息，由此可以确认**Nginx反向代理时，以HTTPS请求上游服务器时默认不启用`SNI`**。

继续来看看上游服务器返回的证书信息

![a1b1cfb94479a758863b7e8323b46a62.png][]

可以看到服务器返回的不是blog.dianduidian.com域名的证书而是nginx配置的一个默认证书，这是由于没有启用[SNI][]，所以TLS握手的时候，上游服务器不知道用那个域名的证书便使用了默认证书返回。

虽然证书返回的不对，但请求不受影响，我们推测**Nginx反向代理时，以HTTPS请求上游服务器时默认不验证上游服务器返回的证书**

通过查阅文档得知确实默认不验证上游证书

Syntax:	proxy_ssl_verify on | off;
    Default:	
    proxy_ssl_verify off;
    Context:	http, server, location
    This directive appeared in version 1.7.0.
    
    Enables or disables verification of the proxied HTTPS server certificate.

默认不验证证书情况。

那我们启用下看看会发生什么？

先获取下`CA`文件，

curl  https://curl.se/ca/cacert.pem  -o /etc/nginx/conf.d/cacert.pem

修改配置文件如下：

server {
            listen       80;
            server_name  www.dianduidian.com;
            location / {
              proxy_pass https://blog.dianduidian.com;
              proxy_ssl_verify on;
              proxy_ssl_trusted_certificate /etc/nginx/conf.d/cacert.pem;          
            }
        }

![ed70c506350f98ad9a49766430927082.png][]

502了，查看下日志，报`upstream SSL certificate verify error`错误

2022/05/18 16:52:14 [error] 20325#1337445: *23 upstream SSL certificate verify error: (18:self signed certificate) while SSL handshaking to upstream, client: 127.0.0.1, server: sni.dianduidian.com, request: "GET / HTTP/1.1", upstream: "https://47.100.x.x:443/", host: "sni.dianduidian.com"

可以看到启用上游证书验证后Nginx确实会证书上游返回的证书，但是通过上边我们抓包可以看到上游返回的是一个Nginx配置的一个默认证书，这个证书是我们自签的，CA验证自然通过不了，但是如果CA是合法的，证书的`CommonName`不一致又会怎样呢，会不会验证不过呢？这里测试话需要多张合法的证书，比较麻烦，我们直接从源码中寻找答案。

static void
    ngx_http_upstream_ssl_handshake(ngx_http_request_t *r, ngx_http_upstream_t *u,
        ngx_connection_t *c)
    {
        long  rc;
    
        if (c->ssl->handshaked) {
    
            if (u->conf->ssl_verify) {
                rc = SSL_get_verify_result(c->ssl->connection);
    
                if (rc != X509_V_OK) {
                    ngx_log_error(NGX_LOG_ERR, c->log, 0,
                                  "upstream SSL certificate verify error: (%l:%s)",
                                  rc, X509_verify_cert_error_string(rc));
                    goto failed;
                }
    
                if (ngx_ssl_check_host(c, &u->ssl_name) != NGX_OK) {
                    ngx_log_error(NGX_LOG_ERR, c->log, 0,
                                  "upstream SSL certificate does not match \"%V\"",
                                  &u->ssl_name);
                    goto failed;
                }
            }
    
            c->write->handler = ngx_http_upstream_handler;
            c->read->handler = ngx_http_upstream_handler;
    
            ngx_http_upstream_send_request(r, u, 1);
    
            return;
        }
    
        if (c->write->timedout) {
            ngx_http_upstream_next(r, u, NGX_HTTP_UPSTREAM_FT_TIMEOUT);
            return;
        }
    
    failed:
    
        ngx_http_upstream_next(r, u, NGX_HTTP_UPSTREAM_FT_ERROR);
    }

![0924159d2ce70c093e5cc8d5d1e342c2.png][]

从源码中可以看到，**开启上游证书验证后不仅会验证证书颁发机构的合法性，且会比对证书中`commonName`，即验证`commonName`的一致性**。

下面来打开`SNI`

网站正常打开，这会抓包看看

![bf62c675f2c78d845062cea37bc6e009.png][]

可以看到TLS握手阶段，Nginx在向上游服务器发送`Client Hello`信息中的扩展部分多出来一个`server_name`，告诉上游服务器应该用哪个证书信息响应。可以看到这里`Server Name`传的是`blog.dianduidian.com`，但是上边配置中我们并没有指定传哪个域名，这一块的逻辑是怎样的呢？

查阅文档得知其实是有另外一个参数`proxy_ssl_name`控制

Syntax:	proxy_ssl_name name;
    Default:	
    proxy_ssl_name $proxy_host;
    Context:	http, server, location
    This directive appeared in version 1.7.0.
    
    Allows overriding the server name used to verify the certificate of the proxied HTTPS server and to be passed through SNI when establishing a connection with the proxied HTTPS server.
    
    By default, the host part of the proxy_pass URL is used.

可以看到默认为`$proxy_host`，我们试着修改下

抓包看看

![88b36985a41121126ee7b2752547df5e.png][]

可以看到`Server Name`已经修改成www.baidu.com了。

### 总结 ###

Nginx作用反向代理与上游服务器使用HTTPS建连时，

1.  **默认不启用`SNI`，使用`proxy_ssl_server_name on;`参数启用；**
2.  **默认不验证上游服务器返回的证书，使用`proxy_ssl_verify on;`**
3.  **开启上游证书验证后Nginx会使用配置文件中指定的CA验证上游服务器返回证书的合法性，同时也会比对证书中的CommonName信息。**

### 参考 ###

[Module ngx\_http\_proxy\_module][Module ngx_http_proxy_module]

[c - How to implement Server Name Indication (SNI) - Stack Overflow][c - How to implement Server Name Indication _SNI_ - Stack Overflow]

[ssl - How to update cURL CA bundle on RedHat? - Server Fault][ssl - How to update cURL CA bundle on RedHat_ - Server Fault]

[OpenSSL-SNI\_Remy1119的博客-CSDN博客\_openssl sni][OpenSSL-SNI_Remy1119_-CSDN_openssl sni]

[nginx documentation][]

[a2da241a9fb2352ddde226fda88879d0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/9217eb6d3e68498bb7de46e0739492a6.png
[SNI]: https://en.wikipedia.org/wiki/Server_Name_Indication
[547754b72ed087ebb7a406edf777d58d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/2b5e9b613890444188d7ba4b82de68d1.png
[4515919d5b1e16b58d1b3b6e72aadf18.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/ef15c21ff853447aa9ae9faf06b195e1.png
[a1b1cfb94479a758863b7e8323b46a62.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/6c2698e4d59341ad9b18e39bc5944198.png
[ed70c506350f98ad9a49766430927082.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/d272d762d38249c987c948d7b5eb1cdf.png
[0924159d2ce70c093e5cc8d5d1e342c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/73e48573501b4905a5f60228fcdff481.png
[bf62c675f2c78d845062cea37bc6e009.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/07f07127205d410ebf936e2a07d53433.png
[88b36985a41121126ee7b2752547df5e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/b4a5a3ad0116487887a159852d2f80c4.png
[Module ngx_http_proxy_module]: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_name
[c - How to implement Server Name Indication _SNI_ - Stack Overflow]: https://stackoverflow.com/questions/5113333/how-to-implement-server-name-indication-sni
[ssl - How to update cURL CA bundle on RedHat_ - Server Fault]: https://serverfault.com/questions/394815/how-to-update-curl-ca-bundle-on-redhat
[OpenSSL-SNI_Remy1119_-CSDN_openssl sni]: https://blog.csdn.net/u011130578/article/details/77979325
[nginx documentation]: http://nginx.org/en/docs/