"kong_upstream" as server_name in SNI for upstream https

[konrade]

Summary

Upstream HTTPS request has SNI server_name set to "kong_upstream" when API is configured with upstream_url starting with https:// even if API is configured with preserve_host=true.

This confuses upstream Apache httpd (and probably other web servers too) since it does not match header "Host: " and it returns a 400 and logging:

[error] Hostname kong_upstream provided via SNI and hostname xxx provided via HTTP are different

My setup is (except other domain names):

• A wildcard certificate *.example.com added in Kong
• A SNI entry assigning above certificate to domain: test.example.com
• API entry registered looking like this:

{
  "name": "test",
  "hosts": ["test.example.com"],
  "upstream_url": "https://192.168.0.10",
  "https_only": true,
  "preserve_host": true
}

• Apache httpd (with SNI support) on 192.168.0.10 with two vhost configs (test.example.com, another.example.com) both bound to *:443.

When I packet sniff the communication I can see that Kong sends a TLS Client Hello with server_name set to "kong_upstream" when I curl https://test.example.com:8443 (which resolves to IP that Kong is listening on).

It feels like the correct behaviour should be that Kong sends the same name in SNI and Host header for upstream requests over HTTPS.

I'm running Kong 0.10.0rc4 (from released dpkg) on Ubuntu 16.04.02 and my /etc/kong/kong.conf looks like this:

# General
anonymous_reports=off
log_level = debug

# Nginx
proxy_listen = 0.0.0.0:8000
proxy_listen_ssl = 0.0.0.0:8443

# Datastore
database = postgres
pg_host = xxx
pg_user = postgres
pg_password = xxx
pg_database = postgres

# DNS resolver
dnsmasq = on

[konrade]

I think I've found what causes it and a quick fix that works in my setup at least.

The problem is in nginx-kong.conf (generated from kong/templates/nginx_kong.lua) where the section "upstream kong_upstream" together with the line "proxy_pass $upstream_scheme://kong_upstream;" causes Nginx to use "kong_upstream" as server_name in SNI towards upstream.

I solved it by overriding what server name Nginx should use in SSL connection to upstream server by using the proxy_ssl_name directive in nginx-kong.conf (had to change in the template since nginx-kong.conf gets generated when kong starts):

    proxy_http_version 1.1;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $upstream_host;
    proxy_set_header Upgrade $upstream_upgrade;
    proxy_set_header Connection $upstream_connection;

    proxy_pass_header Server;
    proxy_pass $upstream_scheme://kong_upstream;
    proxy_ssl_name $upstream_host; # <- Added for correct server name in upstream SNI

    header_filter_by_lua_block {
        kong.header_filter()
    }

[thibaultcha]

Hey,

Thank you very much for investigating this. We'll include this fix in an upcoming release. Feel free to propose a PR against release/0.10 or next!

[konrade]

I found out that my quick fix overriding server name with proxy_ssl_name breaks the certificate lookup process in kong/core/certificate.lua for requests where client does not provide any SNI.

[thibaultcha]

Can you provide more info as to what does it break exactly? Errors, or return values from the ssl_server_name() function maybe?

[pieterjvrensburg]

I just applied the fix from @konrade and it worked for me, without SSL certificate issues.

[konrade]

My followup problem with error in certificate lookup process went away once I configured my own default certificate i kong.conf (with config line: ssl_cert = ...).
Maybe this was only a issue when Kong was using default autogenerated certificate.

[harryparmar]

Confirming fix from @konrade works with default setup.

[p0pr0ck5]

This will be fixed in 0.10.2. Thanks @konrade for the original report and initial patch!