I have drawed the following chart to help explain our situation:
We have an API running on the KESTREL WebServer in the back end. This is running as several instances in docker containers. In front of this, we have a HAProxy Load Balancer which directs the traffic to the Kestrel server with the least connections.
All of this so far is only available internally on our network.
We have one server accessible from the internet, running IIS on port 80 and 443.
In IIS we have added a SSL Certificate which encrypts the communication between the end user and our first entry point.
Is there any further need to encrypt the communication between IIS which proxies the request to our HAProxy on the internal network, and from there on, necessary to encrypt communication from HAProxy to the backends?
As far as my knowledge goes, the only benefit of this, would be that nobody on the internal network at our office can listen to the connections going between the servers, but please correct me if I am wrong here.
Related
I'm trying to configure load balancer to serve in HTTPS with certificates provide by Lets Encrypt, even though I couldn't do it yet, reading this article gives steps how to configure
Self-signed certs
Network Load-Balancer w/ TLS backend
HTTPS Load-Balancer w/ non-TLS backend
HTTPS Load-Balancer w/ TLS backend
As I'm intersting only in HTTPS, I wonder what is the difference between this two:
HTTPS Load-Balancer w/ non-TLS backend
HTTPS Load-Balancer w/ TLS backend
But I meant not the obvious reason that is the first one is not encrypted from load balancer to backend, I mean in performance and HTTP2 conection, for example will I continue to get all the benefits from http2 like multiplexing and streaming? or is the first option
HTTPS Load-Balancer w/ non-TLS backend
only an illusion but I won't get http2?
To talk HTTP/2 all web browsers require the use of HTTPS. And even without HTTP/2 it's still good to have HTTPS for various reasons.
So the point your web browser needs to talk to (often called the edge server), needs to be HTTPS enabled. This is often a load balancer, but could also be a CDN, or just a single web server (e.g. Apache) in front of an application server (e.g. Tomcat).
So then the question is does the connection from that edge server to any downstream servers need to be HTTPS enabled? Well, ultimately the browser will not know, so not for it. Then you're down to two reasons to encrypt this connection:
Because the traffic is still travelling across an insecure channel (e.g. CDN to origin server, across the Internet).
Many feel it's disingenuous to make the user think they are on a secure (with a green padlock) then in fact they are not for the full end to end connection.
This to me is less of an issue if your load balancer is in a segregated network area (or perhaps even on the same machine!) as the server it is connecting to. For example if the load balancer and the 2 (or more) web servers is is connecting to are both in a separate area in a DMZ segregated network or their own VPC.
Ultimately the traffic will be decrypted at some point and the question for server owners is where/when in your networking stack that happens and how comfortable you are with it.
Because you want HTTPS for some other reason (e.g. HTTP/2 all the way through).
On this one I think there is less of a good case to be made. HTTP/2 primarily helps high latency, low bandwidth connections (i.e. browser to edge node) and is less important for low latency, high bandwidth connections (as load balancer to web servers often are). My answer to this question discusses this more.
In both the above scenarios, if you are using HTTPS on your downstream servers, you can use self-signed certificates, or long lived self-signed certificates. This means you are not bound by the 30 days LetsEncrypt limitations, nor does it require you to purchase longer certificates from another CA. As the browser never sees these certificates you only need your load balancer to trust them, which is in your control to do for self-signed certificates. This is also useful if the downstream web servers cannot talk to LetsEncrypt to be able to get certificates from there.
The third option, if it really is important to have HTTPS and/or HTTP/2 all the way through, is to use a TCP load balancer (which is option 2 in your question so apologies for confusing the numbering here!). This just forwards TCP packets to the downstream servers. The packets may still be HTTPS encrypted but the load balancer does not care - it's just forwarding them on and if they are HTTPS encrypted then the downstream server is tasked with decrypting them. So you still can have HTTPS and HTTP/2 in this scenario, you just have the end user certificates (i.e. the LetsEncrypt ones) on the downstream web servers. This can be difficult to manage (should the same certificates be used on both? Or should they have different ones? Do we need to have sticky sessions so HTTPS traffic always hits the sae downstream server). It also means the load balancer cannot see or understand any HTTP traffic - they are all just TCP packets as far as it is concerned. So no filtering on HTTP headers, or adding new HTTP headers (e.g. X-FORWARDED_FOR with the orignal IP address.)
To be honest it is absolutely fine, and even quite common, to have HTTPS on the load balancer and HTTP traffic on downstream servers - if in a secure network between the two. It is usually the easiest to set up (one place to manage HTTPS certificates and renewals) and the easiest supported (e.g. some downstream servers may not easily support HTTPS or HTTP/2). Using HTTPS on this connection either by use of self-signed certificates or CA issued certificates is equally fine, though requires a bit more effort, and the TCP load balancer option is probably the most effort.
when https is used on openshift, is my tomcat behind an apache server?
I mean does my clients connect to my tomcat directly or they connect to the apache server, and then the apache server connect to my tomcat through AJP connector?
If apache is the man in the middle, then I will not get my clients' IP address directly, but with x-forward http header. And I lose the control over certificate verification and trust management. At present, I am using mochahost's server. https does not get to my tomcat, but intercepted by an apache. I hate this.
Previously, I used another hosting service, even 2 apache servers are at front of my tomcat server. Even more ridiculous that 2 apache servers and my tomcat servers are on the same machine. This kind of configuration can only show the system architecture does not have the right ability to manage the whole thing.
By the way, I am talking about the Bronze/Silver plan. I guess Openshift is not different though I have not tried it yet. Anyone has a clear answer to my question?
https is against the man in the middle, but with tomcat server, in this world, there is no service that you can avoid the man in the middle. It is not because technology does not allow, but the people in charge does not really understand the thing, so not able and not willing to provide the right service.
I want to ask: if you use tomcat server, is there any hosting service provider who does not act as a man in the middle? No. There is none on this world at present (May 2014)!
jack
There is an apache reverse proxy located in front of your tomcat instance that does ssl termination. The Apache instance is at the node level, then tomcat runs on your gear.
I'm in the process of creating a website using the ASP.Net MVC 4 framework. I'm having difficulty getting SSL working with that (or any sort of basic) site.
I purchased an SSL certificate for the domain in question (let's just call it "example.com"). I have gone into IIS, and have configured the https binding for the Default Web Site for port 443. If I open the non-SSL version of the site, it works. (In this case, the site is the stock, basic IIS start page). If I attempt to access the site over https, it times out and fails to display the page.
I've verified using netsh that port 443 is open, and that there is nothing else listening on the port. I've double checked to make sure that Windows Firewall is allowing traffic on port 443, and it is. If I fire up Wireshark and listen for traffic on port 443, then attempt to access the web page, I get the following:
I'm not an expert at interpreting these results, but it would seem that something is still blocking the outbound connection. Again, the regular http web page loads fine, but the https version of the same page times out.
I'm about at my wits end trying to figure this out. Any ideas what might be going on here?
Either something is blocking the connections on port 443 on their way to the server or something is blocking the responses. From the wireshark screenshot I see that the server and your client are in separate networks, so there is obviously at least one router in between, maybe other firewalls too. You might check with traceroute or tracepath how far your request travels (e.g. specify port 80 in one try and port 443 in another try and compare) and where the filtering device might be.
This took a bit of digging, but I finally figured it out.
It would appear that, by default, https access to an Amazon EC2 instance is blocked. This explains why it didn't matter what I did in IIS, it wouldn't work. This would also explain why having the correct binding, having the proper ports open on the firewall, and anything else I tried didn't work. It had to do with Amazon, and how they've got things configured on their end.
To enable traffic on port 443, I did the following:
In the Amazon web console (https://console.aws.amazon.com/ec2), click on the Security Groups link on the left
Under the security group that your instance is running, set up a new Inbound rule to allow HTTPS traffic from any IP.
Set up a new Outbound rule to allow HTTPS traffic to any IP.
It wasn't necessary to delete/recreate/restart the instance. As soon as I applied the rules, I tried hitting the https site in my browser on my local machine, and it worked.
Steffen, thanks for the help.
(Related: HTTPS setup in Amazon EC2)
I am getting into load balancing and how security with SSL certificates can be integrated with a load balancer.
Let's say that I want to expose several copies of the same RESTful web service over Amazon Elastic Load Balancer. All should be fine and smooth up until now. However, security has not yet been taken into consideration.
Now, let's say that we want the communication to be secured with an SSL certificate, so we go ahead and buy a certificate. We will have several IP addresses which are all exposing the same RESTful server with the load balancer. These IP addresses will all get mapped to the same domain name (https://thedomain.com). This way, the clients always connect to the same domain. It is then up to the load balancer to redirect to the web service which is getting the least traffic.
The main question is, is it possible for such an architecture with a single SSL certificate? As if this is so, it would be possible to extend the amount of services dynamically without having to change the security.
It is then up to the load balancer to redirect to the web service which is getting the least traffic.
AFAIK, the ELB supports only RoundRobin and Stick sessions. So what you said above will not happen.
is it possible for such an architecture with a single SSL certificate?
You can install the SSL certificate on the ELB and let it do the SSL termination. The traffic between ELB and your Web Nodes will be un-encrypted then. You should explore AWS VPC where you can have a public facing ELB and your Web Nodes will be within Private subnet.
Also, ELB supports TCP load balancing. In this case, you install the Certificate on the Web Nodes and ELB will accept traffic on port 443 from internet and will simply forward it to port 443 on web nodes wherein web nodes have to do SSL encryption/decryption.
Hope this helps.
I need a Reverse Proxy to front both Lablz Web server and SSL VPN Adito (SSL Explorer fork) by sitting on one IP/port. Failed to achieve that with Nginx. Failed to use Adito as a generic reverse HTTP proxy.
Can HAProxy fall back to being a TCP proxy if it does not sense HTTP traffic?
In other words can it fall back to Layer 4 if its Layer 7 inspection determines this is not HTTP traffic?
Here is my setup
EC2 machine with one public IP (Elastic IP).
Only one port is open - 443.
Stunnel is sitting on 443 and is passing traffic to HAProxy (I do not like to use Stunnel but HAProxy does not have full support for SSL yet, unlike Nginx).
HAProxy must be configured to pass some HTTP traffic to one server (Apache server which fronts the SVN server) and the rest of the HTTP traffic to our Lablz Web/App server.
All non-HTTP traffic must be forwarded to Adito VPN.
This traffic is:
VNC, NX, SMB
... and all other protocols that Adito supports
I can not rely on source IP address or port to split traffic into HTTP and non-HTTP.
So, can such config be accomplished in HAProxy? Can any other reverse proxy be used for this? Let me know if I am not thinking right about HAProxy and an alternative approach is possible.
BTW, Adito SSL VPN is amazing and if this setup works we will be able to provide Lablz developers with a fantastic one-click single-login secure VNC-over-HTTPS access to their boxes in the cloud.
No solution exists for this but via Adito - please prove me wrong. But please do not say that VNC over SSH is better. Yes, VNC-over-SSH is faster, more secure, but also is much harder (for our target user base) to setup and presumes that user is behind the firewall that allows outbound traffic on port 22 (not always the case).
Besides, Adito is much more than the remote access gateway - it is a full blown in-browser VPN, a software distribution platform and more. I am not associated with Adito guys - see my Adito post on our Lablz blog.
OK, first off, I'd use a simple firewall to divide all HTTP from NON-HTTP traffic. What you need is packet inspection to figure out what it is that is coming in.
Neither haproxy or nginx can do that. They are both made for web traffic and I don't see how they could inspect traffic to guess what it is that they are dealing with.
Update: Looked into this it a bit and with iptables you could probably use string matching to devide the traffic. However, that's all tricky, especially with the encrypted nature. A friend of mine discovered l7-filter and this looks like what you need. Let me know if this helps.