-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCP+SNI support on the same port as HTTPS #169
Comments
Why do you want to use plain HTTP on port 443? |
Sorry, I didn't explain correctly. There are two use cases:
and
There is no plain HTTP on port 443. |
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 |
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. |
@mildred Would the proposed solution with the two listeners solve your problem? |
@mildred ping |
Correct
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. |
@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? |
correct |
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. |
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 |
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? |
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. |
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. |
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. |
I don't think you're leaking anything here since you're already exposing different hostnames for the different routes. So people will see that - if they care - and whether they resolve to the same or different IPs is not an issue IMO. Virtual hosting is an optimization strategy for saving IPv4 address space not an architecture style. You wouldn't request this feature if you had IPv6 or if you had a /24 routed to your server for example. But in the end this is about solving a problem. I understand now what you are trying to do and my suggestion is to get a second ip for your server and be done with it. At this point I don't see an easy way of doing this with the code I have which means I'd have to do some digging. Since there is a solution to your problem I'd rather focus on other things first for which there isn't a solution yet (e.g. access logging, path stripping, ...) I'll keep this in mind since I think it is an interesting challenge nevertheless and might be useful to accept just any protocol on a given port. |
I've decided not to add this feature. If there are more people requesting this I might reconsider this at a later point. |
Hello, i'm trying to reopen this issue for a different use case. I've setup a fabio and try to have SNI and HTTPS on the same port. The idea is that some micro services are served only with FQDN (myservice.domain.com) so SNI is OK for that, and some have path based routing (api.gw.com/locate/v1 or api.gw.cm/deal/v1.2 etc ...) I can not use both of those system with fabio because SNI take the lead above HTTPS. So i need 2 ports to do that and it's not so easy because developpers need to know the ports of the fabio. I would prefer to use the 443 for the both (like a nginx or haproxy). Is it possible to fabio to check the table a little differently : If fabio has a request, check the SNI hostname, if you find a exact match, do with SNI and if not, check the global url to find match example : src : tomcat.demo.com/ dest : http://192.168.1.2:32225 --> with SNI One other thing, if i use the same port for HTTPS and SNI and set proto=https and tlsskipverify=true, SNI is used rather that HTTPS and HTTPS upstream ... |
The TCP+SNI proxy mode is a pass-through TCP proxy which uses the SNI header for routing without decrypting the connection. It decodes the first packet to look at the SNI header and then uses that to forward the raw TLS packets including the ClientHello to the upstream server. Therefore, your tomcat would need to handle the TLS negotiation as well and would have access to the same certificates. Is that what you are after? What you are trying to do should work with the normal HTTP routing and a TLS listener since fabio will decrypt the message and can look at the request. Maybe I'm missing something here. |
Does this look fixed in version 1.5.14 with #784 |
I have a use case where I need to route on port 443 two type of services:
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 :
The text was updated successfully, but these errors were encountered: