TCP+SNI support on the same port as HTTPS

[mildred]

I have a use case where I need to route on port 443 two type of services:

• services that are already using https. fabio would just need to use SNI to forward the TCP connection to them
• services which are plain HTTP, fabio need to wrap a SSL connection around that

I understand that fabio can do both, but not on the same port. Would it be possible to do that? Basically, it would need to :

• read SNI information
• check if the underlying service talks https, if so, proxy the TCP stream
• if the underlying service only talks unencrypted http, wrap the http in SSL using a certificate from the store

[magiconair]

Why do you want to use plain HTTP on port 443?

[mildred]

Sorry, I didn't explain correctly.

There are two use cases:

• public port 443, HTTPS
• fabio SNI+TCP proxy
• private service, HTTPS, random port

and

• public port 443, HTTPS
• fabio HTTPS wrapping
• private service, unencrypted HTTP, random port

There is no plain HTTP on port 443.

[mildred]

To know if a private service is talking HTTP or HTTPS, we could define a consul tag that would let us differentiate between the two. For example, if a service is registered in consul with the tag ssl, then fabio wouldn't try to find a certificate for this service and forward the whole TCP stream. If the tag ssl is absent, then fabio would manage the encryption with the external client and talk unencrypted with the internal service.

[magiconair]

OK, I figured as much.

The problem is that in order to distinguish TCP+SNI from HTTPS I can only look at the hostname to make the routing decision since for TCP+SNI I cannot decrypt the traffic. In that case you could just setup two listeners on fabio for two different ip addresses for the two hostnames.

[magiconair]

@mildred Would the proposed solution with the two listeners solve your problem?

[magiconair]

@mildred ping

[mildred]

The problem is that in order to distinguish TCP+SNI from HTTPS I can only look at the hostname to make the routing decision since for TCP+SNI I cannot decrypt the traffic.

Correct

In that case you could just setup two listeners on fabio for two different ip addresses for the two hostnames

The problem is in case the two hostnames are linking to the same public IP. That's the main use case of virtual hosts, saving on public IPs.

[magiconair]

@mildred so based on the hostname you either want fabio to pass through the encrypted traffic or decrypt it and forward it as a regular HTTP request. Is that correct?

[mildred]

correct

[magiconair]

Wouldn't it be simpler to just use two different ip addresses for this or is that not possible? You already have the different host names.

[mildred]

As I said, the IP address is public and I only have one.

Bit it is still possible to have another frontend that does this. This is what I am currently doing, especially considering I also need to add basic authentication for some endpoints. Currently, I am using haproxy where I generate automatically the configuration file

[magiconair]

OK, but ip addresses aren't that scarce that you could not get another one or can't you? I'm just wondering whether this feature is an edge case which is solved better in infrastructure than in code. Do you know if any other proxy provides this feature?

[mildred]

Perhaps I'm trying to use fabio for something it is not designed for. My setup is only a single physical server. No VM, no infrastructure as code here. Deployment is manual. The system boundary is the physical machine itself.

If you say this is out of scope for fabio, I would completely understand, even though I would expect this to be useful for some other use cases.

I also know infrastructure as code is very interesting, but I'm not using it where it matters. I much prefer small systems owned by the people themselves instead of relying on third party services.

[magiconair]

What I'm saying is that if you get a second ip address for your server your problem is solved as far as I understand it since you already have two different hostnames. You just need one to point to the TCP+SNI listener and the other one pointing to the standard HTTPS listener.

[mildred]

Yes, it would work, but it would impact outside of the system boundary (need to allocate and route another IP address, and leak internal details to the DNS zone). Having a HAProxy configured to distinguish between the hostnames that it needs to encrypt itself and the hostnames that it forwards with the SSL layer intact is also a good solution that I prefer since it impact less outside of the system boundary.