Return proxy certificate instead of destination server certificate

[nithinbandaru1]

I am not really sure if this can be a valid scenario for forward proxies with limited knowledge on them.

I have client C and server S and proxy A.

• Client C sends HTTP connect to proxy A and destination as S with Proxy Authorization header.
• Proxy A validates authorization header and creates TCP tunnel to server S and sends 200 to client C and this results in creation of HTTP tunnel (Not really a tunnel but a layer under 2 TCP tunnels with proxy in between acting as relay).
• Client now requests encryption of this HTTP tunnel (Not sure if there will be some other HTTP method call for this, but assuming that will be happen in subsequent calls from client C like Client Hello etc, Not really sure). Here ideally server S will provide its certificate to client for creating SSL layer.
• Once this is done then end to end communication is encrypted which will be make it impossible to read subsequent messages.
• I am just wondering if we could send proxy SSL certificate on SSL request by intercepting it, so that data can be intercepted, validated and then forwarded to server S with doing correct SSL encryption. Proxy certificate is trusted by client and I am guessing client will not check if domain matches, making the SSL successful.

I am thinking most of corporate proxies work this way, but not really sure if that is correct. It sounds like a man in the middle attack here but probably valid for some controlled environments!!

[jingjingxyk]

#93

#78

[ssfang]

I found the code in the following configuration example is written with listen 3128 ssl;.

configuration example for CONNECT request in HTTPS

server {
    listen                         3128 ssl;

    # self signed certificate generated via openssl command
    ssl_certificate_key            /path/to/server.key;
    ssl_certificate                /path/to/server.crt;
    ssl_session_cache              shared:SSL:1m;

    # dns resolver used by forward proxying
    resolver                       8.8.8.8;

    # forward proxy for CONNECT request
    proxy_connect;
    proxy_connect_allow            443 563;
    proxy_connect_connect_timeout  10s;
    proxy_connect_data_timeout     10s;

    # defined by yourself for non-CONNECT request
    # Example: reverse proxy for non-CONNECT requests
    location / {
        proxy_pass http://$host;
        proxy_set_header Host $host;
    }
}

But it cannot work.

After trying to modify the following code in src\http\ngx_http_request.c, as

void
ngx_http_process_request(ngx_http_request_t *r)
{
    ngx_connection_t  *c;

    c = r->connection;

#if (NGX_HTTP_SSL)
#if NGX_HTTP_PROXY_CONNECT
    if (r->http_connection->ssl && NGX_HTTP_CONNECT != r->method) {
#else
    if (r->http_connection->ssl) {
#endif

The client browser still saw the certificate of the destination server instead of the one specified by the ssl_certificate directive .

[matthew-pakulski]

While you can't easily change the tls traffic being tunneled, what you can do is you can adjust the proxy_connect_address. This directive can send the traffic to another destination instead of where the proxy user specified. That destination can be the local nginx server. You can create a server block in nginx, which acts like your typical reverse proxy, where you can present your own certificate, terminate the tls session, then have that traffic proxy_pass up to its original destination (or any other destination you want).

Here's a snippet which when paired with this proxy module will redirect traffic through the proxy to the two docker.io hostnames to the local nginx/openresty instance which then presents your custom server certificate to the client, then forwards the request to the real docker.io hostname. For proxy requests to other hostnames, by default, it does not reroute the target host.

I use this tactic to configure docker client with the HTTPS_PROXY which reroutes all of its image pulls to various container registries to my local cache container registry. It also requires the client to trust the certs your reverse-proxy provides.

# Proxy connect block
map $connect_host $target_host {
  hostnames;
  docker.io            127.0.0.1:8443;
  registry-1.docker.io 127.0.0.1:8443;
  default "";
}
server {
    listen 3128;
    proxy_connect;
    proxy_connect_address $target_host;
    resolver ${NGINX_LOCAL_RESOLVERS} valid=300s;
}

# reverse-proxy
server {
  listen              8443 ssl;

  server_name         docker.io registry-1.docker.io;

  ssl_certificate     /path/to/your/docker.io/server.crt;
  ssl_certificate_key /path/to/your/docker.io/server.key;

  location / {
    proxy_pass https://$host;
  }
}