Support SNI-based routing without TLS termination

[morningspace]

Summary

According to @hbagdi, the current Kong implementation does not support TLS passthrough for HTTPs upstream service, while this appears to be a common scenario for some other reverse proxies such as nginx, haproxy that natively support.

Also, to terminate TLS to retrieve SNI looks a bit odd, but that is understood since TLS passthrough is missing at the moment.

Right now, Kong can do either of the two things:

• Send all traffic on on a specific port to an upstream service
• Terminate TLS connection on a specific port, and then route traffic to different upstream services based on the SNI

Kong cannot sniff SNI, not terminate the TLS and route traffic to an upstream service.

More details could be found at: https://discuss.konghq.com/t/does-kong-ingress-controller-support-tls-passthrough-for-https-upstream-service/6268

[hbagdi]

other reverse proxies such as nginx

I'm not an Nginx ninja by any means, but can you elaborate on how you can accomplish this using Nginx? From what I understand, this is not possible in Nginx.

[morningspace]

Hi @hbagdi , just to clarify if any misunderstanding here. BTW: I'm not a Nginx ninja also:-)

When you said "this is not possible in Nginx", do you mean to put Nginx in front of a set of HTTPs services(as upstream)? Or, you mean the SNI w/o terminating TLS?

My understanding is that in Nginx (so does HAProxy), it will generally take it as TCP traffic by using stream block. And if it requires SNI, ssl_preread_server_name can help w/o terminating TLS. Here are some materials after I did a quick google:

• https://stackoverflow.com/questions/38371840/ssl-pass-through-in-nginx-reverse-proxy
• https://serverfault.com/questions/999728/nginx-selective-tls-passthrough-reverse-proxy-based-on-sni

And, for HAProxy, here're online slides I created a couple of years ago which include sample configuration for TLS passthrough:

• https://morningspace.github.io/lab-load-balancing/slides/#/3/11

Let me know if there is anything I missed.

[hbagdi]

Thanks for the explanation, @morningspace.

What you said in your latest comment is correct. I may (or may not) have wrongly understood your original post.

There are a few possibilities when we are mixing HTTP, TLS and optional termination:

1. Terminate TLS, parse the HTTP request, perform all the HTTP magic and then forward traffic to the upsteram service. In this mode, the proxy has an understanding of the HTTP and TLS protocol-level details of the connection.
2. Terminate TLS on a port, forward traffic as is to an upstream service. In this mode, the proxy has no understanding of the bytes stream encapsulated inside the TLS stream, meaning you can't perform HTTP manipulation for some traffic and not for other traffic.
3. Do not terminate TLS and forward traffic based on SNI in the TLS handshake. (This is the functionality that you are referring to). In this mode, the proxy can't even decrypt the encrypted byte stream flowing back and forth.
4. Do not terminate or interpret anything in the TCP byte stream. Simply pass all the traffic that the proxy recieves on a specific TCP port to an upstream service. In this mode, the proxy has no understanding of even TLS.

With Nginx and Kong, you can't mix and match any of these on the same port. Meaning, if you configure a port to do (1), then you can't do (2) at the same time on the same port. The same holds true for (1) and (3). You have to pick one mode and stick to it on a specific port.

Nginx is capable of doing (3) but Kong cannot do that (yet). All other modes are supported by Kong and Nginx.

[morningspace]

@hbagdi

mix and match any of these on the same port

Yeah, that's also my understanding:-)

So, it appears this git issue could be transformed into a feature request for option (3). I'd be happy to dive into it when I have time.

Before that, I have one more question, with (2)/(4) in place, what other benefits Kong could bring to us? Assume some basic logging capability is applicable, is rate limiting also available? What about other features?

Also, for above options, I'd think it'd be nice if there're docs with reference examples for people to better understand the ideas and how to configure it using Kong.

[hbagdi]

Before that, I have one more question, with (2)/(4) in place, what other benefits Kong could bring to us? Assume some basic logging capability is applicable, is rate limiting also available? What about other features?

Most reverse proxies like Kong add value when they have visibility into the L7 protocol. That is way more powerful than L4 proxy capabilities, at least as far as the application layer is concerned.

With (2) and (4), you can perform load balancing of L4 connections to multiple instances of your application server using Kong. You might get some basic logging out of Kong as well. Rate-limiting is not supported out of the box but you could do a basic IP-based rate-limiting as well.

[morningspace]

Awesome, thanks @hbagdi for your kindly sharing on this. I will find time to look at the SNI implementation in Kong, and update here later!

[linuxbsdfreak]

+1 for this feature

[mayocream]

+1 for this feature

[sanjog152]

+1 for this feature