Opened 3 years ago

Closed 5 months ago

#13 closed enhancement (fixed)

Proxy SSL Verify

Reported by: waloeiii.myopenid.com Owned by: somebody
Priority: minor Milestone:
Component: nginx-module Version:
Keywords: proxy ssl verify peer Cc:
Sensitive: no
uname -a: Darwin loe.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
nginx -V: nginx version: nginx/0.8.55 built by gcc 4.2.1 (Apple Inc. build 5666) (dot 3) TLS SNI support enabled configure arguments: --prefix=/opt/local --with-debug --with-cc-opt='-I/opt/local/include -O2' --with-ld-opt=-L/opt/local/lib --conf-path=/opt/local/etc/nginx/nginx.conf --error-log-path=/opt/local/var/log/nginx/error.log --http-log-path=/opt/local/var/log/nginx/access.log --pid-path=/opt/local/var/run/nginx/nginx.pid --lock-path=/opt/local/var/run/nginx/nginx.lock --http-client-body-temp-path=/opt/local/var/run/nginx/client_body_temp --http-proxy-temp-path=/opt/local/var/run/nginx/proxy_temp --http-fastcgi-temp-path=/opt/local/var/run/nginx/fastcgi_temp --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module --add-module=/Users/Andrew/Downloads/debuild/nginx/nginx-0.7.67/modules/nginx_upload_module-2.0.12c

Description (last modified by Maxim Dounin)

Proxy should be able to verify peer's SSL certificate.

Attachments (6)

proxy_ssl_verify-0.7.67.2.patch (4.8 KB) - added by waloeiii.myopenid.com 3 years ago.
proxy_ssl_verify_0.8.55.patch (4.8 KB) - added by waloeiii.myopenid.com 3 years ago.
proxy_ssl_verify-0.7.67.patch (4.8 KB) - added by waloeiii.myopenid.com 3 years ago.
proxy_ssl_verify-1.1.2.patch (7.5 KB) - added by waloeiii.myopenid.com 3 years ago.
nginx.conf (4.2 KB) - added by waloeiii.myopenid.com 3 years ago.
Configuration file to replicate the issue and desired behavior.
proxy_ssl_verify-1.1.3.patch (7.8 KB) - added by waloeiii.myopenid.com 3 years ago.

Download all attachments as: .zip

Change History (19)

Changed 3 years ago by waloeiii.myopenid.com

Changed 3 years ago by waloeiii.myopenid.com

Changed 3 years ago by waloeiii.myopenid.com

comment:1 follow-up: Changed 3 years ago by Maxim Dounin

  • Description modified (diff)
  • Status changed from new to accepted
  • Version 0.8.x deleted

Please see patch review in nginx-devel@ mailing list.

Changed 3 years ago by waloeiii.myopenid.com

comment:2 Changed 3 years ago by waloeiii.myopenid.com

I've updated to a patch against 1.1.2. But this code does not work, I cannot stop the async SSL handshake, SSL_get_verify_result() is always 0, the error appears to be cleared.

Changed 3 years ago by waloeiii.myopenid.com

Configuration file to replicate the issue and desired behavior.

comment:3 Changed 3 years ago by waloeiii.myopenid.com

I have posted a working patch against nginx 1.1.3.

Changed 3 years ago by waloeiii.myopenid.com

comment:4 Changed 3 years ago by waloeiii.myopenid.com

Updated nginx.

12:24:25 nginx (proxy_ssl_verify) → ~/local/nginx/sbin/nginx -V
nginx: nginx version: nginx/1.1.3
nginx: built by gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
nginx: TLS SNI support enabled
nginx: configure arguments: --prefix=/Users/Andrew?/local/nginx --with-debug --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module

comment:5 Changed 20 months ago by Daniel Kahn Gillmor

What's going on with this? This seems like a potentially serious security vulnerability.

Why offer an https connection to an origin server if you don't plan on validating the connection? It seems like one of two cases are possible:

  • the network between the nginx proxy and the origin server is trusted (meaning all machines on it are trusted). In this case, there is no need for an https connection (and in fact that connection is just unnecessary overhead)
  • the network between the nginx proxy and the origin server is not trusted. In this case, an untrusted machine could MITM the connection between the proxy and the origin server, and do so undetectably.

So it seems to me like nginx should either remove the capability to do https connections to the origin server when acting as a proxy, or it should enable proper verification of the origin server's identity for these connections.

Has this been issued a CVE yet?

Last edited 20 months ago by Daniel Kahn Gillmor (previous) (diff)

comment:6 follow-up: Changed 20 months ago by Mike Ashton

It's not quite that black and white. Your internal network might be trusted, but if you want your proxy to be relatively transparent such that your codebase perceives https requests as secure and http requests as not, you'll want a proxy to make an https connection to your backend servers in response to frontend https connections without necessarily bothering with verification.

Naturally, there are other approaches one can take to solving that problem, but I don't think it's entirely fair to divide the use cases into your two subsets.

comment:7 in reply to: ↑ 6 Changed 20 months ago by Daniel Kahn Gillmor

Replying to Mike Ashton:

Your internal network might be trusted, but if you want your proxy to be relatively transparent such that your codebase perceives https requests as secure and http requests as not, you'll want a proxy to make an https connection to your backend servers in response to frontend https connections without necessarily bothering with verification.

Sure, you could do that, but you could just as easily have your codebase perceive https requests and any requests from the local network as "secure", and other http requests as "not". That would be more efficient, simpler, and more honest from the perspective of what's happening here.

But let's say you decide you want to pursue the particular corner case you describe. In that case (where you understand the tradeoffs, and you've decided to pay the extra https overhead on your trusted network) you should be explicitly configuring your proxy server to skip https peer verification.

The default for https connections should be to require verification. The current setup encourages administrators to believe that their proxy connections are resistant to MITM attack when they actually are not.

comment:8 Changed 20 months ago by Daniel Kahn Gillmor

comment:10 Changed 20 months ago by Maxim Dounin

  • Sensitive unset

Current implementation of proxy_pass ensures eavesdropping protection with https, but obviously lacks MITM protection as there is no remote certificate verification. Claiming that providing eavesdropping protection is a vulnerability looks strange for me. But probably this needs to be better documented.

comment:11 in reply to: ↑ 1 Changed 20 months ago by Daniel Kahn Gillmor

Replying to Maxim Dounin:

Please see patch review in nginx-devel@ mailing list.

Here is the patch review Maxim refers to.

comment:13 Changed 5 months ago by Maxim Dounin

  • Resolution set to fixed
  • Status changed from accepted to closed

The proxy_ssl_verify support committed, see 060c2e692b96.

Note: See TracTickets for help on using tickets.