使用Nginx作为HTTPS正向代理服务器_服务器知识

NGINX主要设计作为反向代理服务器，但随着NGINX的发展，它同样能作为正向代理的选项之一。正向代理本身并不复杂，而如何代理加密的HTTPS流量是正向代理需要解决的主要问题。本文将介绍利用NGINX来正向代理HTTPS流量两种方案，及其使用场景和主要问题。

HTTP/HTTPS正向代理的分类

简单介绍下正向代理的分类作为理解下文的背景知识：

按客户端有无感知的分类

普通代理：在客户端需要在浏览器中或者系统环境变量手动设置代理的地址和端口。如squid，在客户端指定squid服务器IP和端口3128。

透明代理：客户端不需要做任何代理设置，“代理”这个角色对于客户端是透明的。如企业网络链路中的Web Gateway设备。

按代理是否解密HTTPS的分类

隧道代理：也就是透传代理。代理服务器只是在TCP协议上透传HTTPS流量，对于其代理的流量的具体内容不解密不感知。客户端和其访问的目的服务器做直接TLS/SSL交互。本文中讨论的NGINX代理方式属于这种模式。

中间人(MITM, Man-in-the-Middle)代理：代理服务器解密HTTPS流量，对客户端利用自签名证书完成TLS/SSL握手，对目的服务器端完成正常TLS交互。在客户端-代理-服务器的链路中建立两段TLS/SSL会话。如Charles，简单原理描述可以参考文章。

https://www.jianshu.com/p/405f9d76f8c4

注：这种情况客户端在TLS握手阶段实际上是拿到的代理服务器自己的自签名证书，证书链的验证默认不成功，需要在客户端信任代理自签证书的Root CA证书。所以过程中是客户端有感的。如果要做成无感的透明代理，需要向客户端推送自建的Root CA证书，在企业内部环境下是可实现的。

使用Nginx作为HTTPS正向代理服务器

为什么正向代理处理HTTPS流量需要特殊处理?

作为反向代理时，代理服务器通常终结 (terminate) HTTPS加密流量，再转发给后端实例。HTTPS流量的加解密和认证过程发生在客户端和反向代理服务器之间。

而作为正向代理在处理客户端发过来的流量时，HTTP加密封装在了TLS/SSL中，代理服务器无法看到客户端请求URL中想要访问的域名，如下图。所以代理HTTPS流量，相比于HTTP，需要做一些特殊处理。

使用Nginx作为HTTPS正向代理服务器

NGINX的解决方案

根据前文中的分类方式，NGINX解决HTTPS代理的方式都属于透传(隧道)模式，即不解密不感知上层流量。具体的方式有如下7层和4层的两类解决方案。

HTTP CONNECT隧道 (7层解决方案)

历史背景

早在1998年，也就是TLS还没有正式诞生的SSL时代，主导SSL协议的Netscape公司就提出了关于利用web代理来tunneling SSL流量的INTERNET-DRAFT。其核心思想就是利用HTTP CONNECT请求在客户端和代理之间建立一个HTTP CONNECT Tunnel，在CONNECT请求中需要指定客户端需要访问的目的主机和端口。Draft中的原图如下：

使用Nginx作为HTTPS正向代理服务器

整个过程可以参考HTTP权威指南中的图：

客户端给代理服务器发送HTTP CONNECT请求。

代理服务器利用HTTP CONNECT请求中的主机和端口与目的服务器建立TCP连接。

代理服务器给客户端返回HTTP 200响应。

客户端和代理服务器建立起HTTP CONNECT隧道，HTTPS流量到达代理服务器后，直接通过TCP透传给远端目的服务器。代理服务器的角色是透传HTTPS流量，并不需要解密HTTPS。

使用Nginx作为HTTPS正向代理服务器

NGINX ngx_http_proxy_connect_module模块

NGINX作为反向代理服务器，官方一直没有支持HTTP CONNECT方法。但是基于NGINX的模块化、可扩展性好的特性，阿里的@chobits提供了ngx_http_proxy_connect_module模块，来支持HTTP CONNECT方法，从而让NGINX可以扩展为正向代理。

环境搭建

以CentOS 7的环境为例。

1) 安装

对于新安装的环境，参考正常的安装步骤和安装这个模块的步骤(https://github.com/chobits/ngx_http_proxy_connect_module)，把对应版本的patch打上之后，在configure的时候加上参数--add-module=/path/to/ngx_http_proxy_connect_module，示例如下：

./configure

--user=www

--group=www

--prefix=/usr/local/nginx

--with-http_ssl_module

--with-http_stub_status_module

--with-http_realip_module

--with-threads

--add-module=/root/src/ngx_http_proxy_connect_module

对于已经安装编译安装完的环境，需要加入以上模块，步骤如下：

#停止NGINX服务

#systemctlstopnginx

#备份原执行文件

#cp/usr/local/nginx/sbin/nginx/usr/local/nginx/sbin/nginx.bak

#在源代码路径重新编译

#cd/usr/local/src/nginx-1.16.0

./configure

--user=www

--group=www

--prefix=/usr/local/nginx

--with-http_ssl_module

--with-http_stub_status_module

--with-http_realip_module

--with-threads

--add-module=/root/src/ngx_http_proxy_connect_module

#make

#不要makeinstall

#将新生成的可执行文件拷贝覆盖原来的nginx执行文件

#cpobjs/nginx/usr/local/nginx/sbin/nginx

#/usr/bin/nginx-V

nginxversion:nginx/1.16.0

builtbygcc4.8.520150623(RedHat4.8.5-36)(GCC)

builtwithOpenSSL1.0.2k-fips26Jan2017

TLSSNIsupportenabled

configurearguments:--user=www--group=www--prefix=/usr/local/nginx--with-http_ssl_module--with-http_stub_status_module--with-http_realip_module--with-threads--add-module=/root/src/ngx_http_proxy_connect_module

2) nginx.conf文件配置

server{

listen443;

#dnsresolverusedbyforwardproxying

resolver114.114.114.114;

#forwardproxyforCONNECTrequest

proxy_connect;

proxy_connect_allow443;

proxy_connect_connect_timeout10s;

proxy_connect_read_timeout10s;

proxy_connect_send_timeout10s;

#forwardproxyfornon-CONNECTrequest

location/{

proxy_passhttp://$host;

proxy_set_headerHost$host;

}

使用场景

7层需要通过HTTP CONNECT来建立隧道，属于客户端有感知的普通代理方式，需要在客户端手动配置HTTP(S)代理服务器IP和端口。在客户端用curl 加-x参数访问如下：

#curlhttps://www.baidu.com-svo/dev/null-x39.105.196.164:443

*Abouttoconnect()toproxy39.105.196.164port443(#0)

*Trying39.105.196.164...

*Connectedto39.105.196.164(39.105.196.164)port443(#0)

*EstablishHTTPproxytunneltowww.baidu.com:443

>CONNECTwww.baidu.com:443HTTP/1.1

>Host:www.baidu.com:443

>User-Agent:curl/7.29.0

>Proxy-Connection:Keep-Alive

*ProxyrepliedOKtoCONNECTrequest

*InitializingNSSwithcertpath:sql:/etc/pki/nssdb

*CAfile:/etc/pki/tls/certs/ca-bundle.crt

CApath:none

*SSLconnectionusingTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

*Servercertificate:

*subject:CN=baidu.com,O="BeijingBaiduNetcomScienceTechnologyCo.,Ltd",OU=serviceoperationdepartment,L=beijing,ST=beijing,C=CN

...

>GET/HTTP/1.1

>User-Agent:curl/7.29.0

>Host:www.baidu.com

>Accept:*/*

...

{[datanotshown]

从上面-v参数打印出的细节，可以看到客户端先往代理服务器39.105.196.164建立了HTTP CONNECT隧道，代理回复HTTP/1.1 200 Connection Established后就开始交互TLS/SSL握手和流量了。

NGINX stream (4层解决方案)

既然是使用透传上层流量的方法，那可不可做成“4层代理”，对TCP/UDP以上的协议实现彻底的透传呢?答案是可以的。NGINX官方从1.9.0版本开始支持ngx_stream_core_module模块，模块默认不build，需要configure时加上--with-stream选项来开启。

问题

用NGINX stream在TCP层面上代理HTTPS流量肯定会遇到本文一开始提到的那个问题：代理服务器无法获取客户端想要访问的目的域名。因为在TCP的层面获取的信息仅限于IP和端口层面，没有任何机会拿到域名信息。要拿到目的域名，必须要有拆上层报文获取域名信息的能力，所以NGINX stream的方式不是完全严格意义上的4层代理，还是要略微借助些上层能力。

ngx_stream_ssl_preread_module模块

要在不解密的情况下拿到HTTPS流量访问的域名，只有利用TLS/SSL握手的第一个Client Hello报文中的扩展地址SNI (Server Name Indication)来获取。NGINX官方从1.11.5版本开始支持利用ngx_stream_ssl_preread_module模块来获得这个能力，模块主要用于获取Client Hello报文中的SNI和ALPN信息。对于4层正向代理来说，从Client Hello报文中提取SNI的能力是至关重要的，否则NGINX stream的解决方案无法成立。同时这也带来了一个限制，要求所有客户端都需要在TLS/SSL握手中带上SNI字段，否则NGINX stream代理完全没办法知道客户端需要访问的目的域名。

环境搭建

1) 安装

对于新安装的环境，参考正常的安装步骤，直接在configure的时候加上--with-stream，--with-stream_ssl_preread_module和--with-stream_ssl_module选项即可。示例如下：

./configure

--user=www

--group=www

--prefix=/usr/local/nginx

--with-http_ssl_module

--with-http_stub_status_module

--with-http_realip_module

--with-threads

--with-stream

--with-stream_ssl_preread_module

--with-stream_ssl_module

对于已经安装编译安装完的环境，需要加入以上3个与stream相关的模块，步骤如下：

#停止NGINX服务

#systemctlstopnginx

#备份原执行文件

#cp/usr/local/nginx/sbin/nginx/usr/local/nginx/sbin/nginx.bak

#在源代码路径重新编译

#cd/usr/local/src/nginx-1.16.0

#./configure

--user=www

--group=www

--prefix=/usr/local/nginx

--with-http_ssl_module

--with-http_stub_status_module

--with-http_realip_module

--with-threads

--with-stream

--with-stream_ssl_preread_module

--with-stream_ssl_module

#make

#不要makeinstall

#将新生成的可执行文件拷贝覆盖原来的nginx执行文件

#cpobjs/nginx/usr/local/nginx/sbin/nginx

#nginx-V

nginxversion:nginx/1.16.0

builtbygcc4.8.520150623(RedHat4.8.5-36)(GCC)

builtwithOpenSSL1.0.2k-fips26Jan2017

TLSSNIsupportenabled

2) nginx.conf文件配置

NGINX stream与HTTP不同，需要在stream块中进行配置，但是指令参数与HTTP块都是类似的，主要配置部分如下：

stream{

resolver114.114.114.114;

server{

listen443;

ssl_prereadon;

proxy_connect_timeout5s;

proxy_pass$ssl_preread_server_name:$server_port;

}

使用场景

对于4层正向代理，NGINX对上层流量基本上是透传，也不需要HTTP CONNECT来建立隧道。适合于透明代理的模式，比如将访问的域名利用DNS解定向到代理服务器。我们可以通过在客户端绑定/etc/hosts来模拟。

在客户端：

cat/etc/hosts

...

#把域名www.baidu.com绑定到正向代理服务器39.105.196.164

39.105.196.164www.baidu.com

#正常利用curl来访问www.baidu.com即可。

#curlhttps://www.baidu.com-svo/dev/null

*Abouttoconnect()towww.baidu.comport443(#0)

*Trying39.105.196.164...

*Connectedtowww.baidu.com(39.105.196.164)port443(#0)

*InitializingNSSwithcertpath:sql:/etc/pki/nssdb

*CAfile:/etc/pki/tls/certs/ca-bundle.crt

CApath:none

*SSLconnectionusingTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

*Servercertificate:

*subject:CN=baidu.com,O="BeijingBaiduNetcomScienceTechnologyCo.,Ltd",OU=serviceoperationdepartment,L=beijing,ST=beijing,C=CN

*startdate:5月0901:22:022019GMT

*expiredate:6月2505:31:022020GMT

*commonname:baidu.com

*issuer:CN=GlobalSignOrganizationValidationCA-SHA256-G2,O=GlobalSignnv-sa,C=BE

>GET/HTTP/1.1

>User-Agent:curl/7.29.0

>Host:www.baidu.com

>Accept:*/*

{[datanotshown]

*Connection#0tohostwww.baidu.comleftintact

常见问题

1) 客户端手动设置代理导致访问不成功

4层正向代理是透传上层HTTPS流量，不需要HTTP CONNECT来建立隧道，也就是说不需要客户端设置HTTP(S)代理。如果我们在客户端手动设置HTTP(s)代理是否能访问成功呢? 我们可以用curl -x来设置代理为这个正向服务器访问测试，看看结果：

#curlhttps://www.baidu.com-svo/dev/null-x39.105.196.164:443

*Abouttoconnect()toproxy39.105.196.164port443(#0)

*Trying39.105.196.164...

*Connectedto39.105.196.164(39.105.196.164)port443(#0)

*EstablishHTTPproxytunneltowww.baidu.com:443

>CONNECTwww.baidu.com:443HTTP/1.1

>Host:www.baidu.com:443

>User-Agent:curl/7.29.0

>Proxy-Connection:Keep-Alive

*ProxyCONNECTaborted

*Connection#0tohost39.105.196.164leftintact

可以看到客户端试图于正向NGINX前建立HTTP CONNECT tunnel，但是由于NGINX是透传，所以把CONNECT请求直接转发给了目的服务器。目的服务器不接受CONNECT方法，所以最终出现"Proxy CONNECT aborted"，导致访问不成功。

2) 客户端没有带SNI导致访问不成功

上文提到用NGINX stream做正向代理的关键因素之一是利用ngx_stream_ssl_preread_module提取出Client Hello中的SNI字段。如果客户端客户端不携带SNI字段，会造成代理服务器无法获知目的域名的情况，导致访问不成功。

在透明代理模式下(用手动绑定hosts的方式模拟)，我们可以在客户端用openssl来模拟：

#openssls_client-connectwww.baidu.com:443-msg

CONNECTED(00000003)

>>>TLS1.2[length0005]

160301011c

>>>TLS1.2Handshake[length011c],ClientHello

0100011803036b2e7586526cd5a580d7

a461656d725333fb33f043a3aac24ae3

47849f698bd60000acc030c02cc028c0

24c014c00a00a500a300a1009f006b00

6a006900680039003800370036008800

8700860085c032c02ec02ac026c00fc0

05009d003d00350084c02fc02bc027c0

23c013c00900a400a200a0009e006700

40003f003e0033003200310030009a00

99009800970045004400430042c031c0

2dc029c025c00ec004009c003c002f00

960041c012c008001600130010000dc0

0dc003000a0007c011c007c00cc00200

05000400ff01000043000b0004030001

02000a000a0008001700190018001600

230000000d0020001e06010602060305

01050205030401040204030301030203

03020102020203000f000101

140285606590352:error:140790E5:SSLroutines:ssl23_write:sslhandshakefailure:s23_lib.c:177:

---

nopeercertificateavailable

---

NoclientcertificateCAnamessent

---

SSLhandshakehasread0bytesandwritten289bytes

...

openssl s_client默认不带SNI，可以看到上面的请求在TLS/SSL握手阶段，发出Client Hello后就结束了。因为代理服务器不知道要把Client Hello往哪个目的域名转发。

如果用openssl带servername参数来指定SNI，则可以正常访问成功，命令如下：

#openssls_client-connectwww.baidu.com:443-servernamewww.baidu.com

总结

本文总结了NGINX利用HTTP CONNECT隧道和NGINX stream两种方式做HTTPS正向代理的原理，环境搭建，使用场景和主要问题，希望给大家在做各种场景的正向代理时提供参考。

作者：怀知

使用Nginx作为HTTPS正向代理服务器

延伸 · 阅读

Ubuntu虚拟机多网卡配置

甲骨文(Oracle Cloud)永久免费VPS云服务器支持日本韩国美国等地附

十大常见的服务器管理软件

高防服务器租用防御措施常见的硬防与软防

物理服务器对比云服务器有那些差别之处？

高防CDN和高防IP是什么？有什么不同

Docker容器化部署尝试——多容器通信(node+mongoDB+nginx)

vmware虚拟机安装win7操作系统的教程图解

云服务器是什么，云主机干什么用的？

2020最新好用的web服务器软件推荐

服务器操作系统有哪些?

web服务器配置（图文详解）

企业如何选择阿里云服务器配置?

五大免费主机管理系统优缺点对比及推荐

2019最新三款Windows下连接Linux的ssh软件下载推荐

服务器常用管理软件盘点

Nginx服务器究竟是怎么执行PHP项目