I'm adding a google load balancer and the ssl will take a while to provision and propagate. Is there a way that I can put up a server maintenance page while waiting for the propagation to complete?
I can put up a server maintenance page while waiting for the
propagation to complete?
No. Until the propagation completes, users cannot get past the load balancer to see your maintenance page.
Note: The HTTP and HTTPS listeners operate independently. This means that if you configure the HTTP listener before configuring the HTTPS listener, in most cases, HTTP traffic will continue to flow to the backends while the HTTPS listener is configured - unless your domain is using HSTS or permanent HTTPS redirects.
Related
I have a load balancer setup with two clusters, each with a few balancer members. What I need to do is send traffic from a web browser (or GET requests) to one cluster and traffic from anything else (like api calls, so python, postman, etc, or POST requests) to another cluster. The urls used for both requests are the same.
I also may be making this more complicated than it needs to be. I have one load balancer that sends the traffic to another load balancer that strips ssl for tcpdumps, and the 2nd load balancer sends the request on to the app. The problem with this is when viewed in a browser all of the links on the page are converted to http links when I need them to stay as https links.
What I would like is to have some way to determine which type of traffic (via browser or method) at load balancer one and if it's a browser or a GET send it to the app cluster, otherwise send it to the cluster of the second load balancer for capture (and then on to the app) OR have all links from the 2nd load balancer returned as https.
I'm presently using htaccess to force redirection to https for my website but I'm finding that redirected traffic is taking >1.5 seconds longer to receive the first file from the server than direct to https traffic.
What is the fastest way to force https for the whole site?
I believe that .htaccess is the fastest way to force https.
This is because .htaccess is a configuration on the web server (Apache), which is the first system to receive the http request.
Browser => DNS => Load Balancer => Web Server => Application
You could also force https at the application level but it would mean you have to go thru the server first. Unless you are using a load balancer, the web server is the first point contact a browser has with your https rules.
Of course, the fastest way would be to make sure all the links you are sending are in https so that the user never goes thru a redirect (301).
I not sure if this is possible (it wasn't last year according to the internet), but i'm hoping its available now.
Is there any way of using google load balancer to force https connection only, ie. get the load balancer to redirect http requests?
I can do it at the backend server, but i would rather have this handled by the load balancer.
Thanks in advance,
Max
I think not. As far as I know, forcing HTTPS is not a managed feature of Google Cloud Load Balancer. It will not redirect HTTP to HTTPS for you. You can either drop the support of HTTP, or do the redirection in the backend. But it's would be a nice feature if they have.
See https://cloud.google.com/compute/docs/load-balancing/http/
I'm setting up HTTPS Load Balancing (LB) on Google Compute Engine (GCE). Key components are outlined in the Overview Diagram.
After successfully creating a HTTP Backend Service where 1 of 1 (GCE) instance is healthy, I decided to do the same for HTTPS. I'm using the Developer Console UI to do this.
The Healtheck "wizard" provides a drop-down menu for protocol with the option HTTP and HTTPS:
The successful HTTP Heathcheck used the path :8080/admin/healthcheck.
Presumably the HTTPS Healtheck will use the path :443/admin/healthcheck. The problem is my HTTPS Healthchecks are failing. This was expected since when visiting https://[INSTANCE_IP]:443/admin/healthcheck in a browser, it could not connect. So I didn't expect the Healthcheck to mark the instance as healthy.
How can I connect to https://[INSTANCE_IP]:443/admin/healthcheck over TLS, do I merely need to upload a certificate and create a Certificate Resource in the Developer Console (I doubt it)?
I think it's a conceptual problem too.
The URL https://[INSTANCE_IP]:443/admin/healthcheck does exist, I think because the instance doesn't implement TLS, the Healthcheck fails.
What is the relationship between a uploading a certificate (i.e. creating Certificate Resource) and a specific GCE instance accepting HTTPS requests such that HTTPS HealthCheck pass?
After re-reading the documentation, it is stated:
The client SSL session terminates at the load balancer. Sessions
between the load balancer and the instance can either be HTTPS
(recommended) or HTTP. If HTTPS, each instance must have a
certificate.
It is the last sentence that I was trying to achieve because HTTPS Healthchecks use a HTTPS URL to check the 'health' of an individual instance:
https://[INSTANCE_IP]:443/admin/healthcheck
Since this was failing, I incorrectly assumed I needed to implement TLS on each instance for the Healthcheck to succeed. However, I do not require each instance to implement TLS (HTTPS), only the Load Balancer.
The final configuration I used involved creating a new HTTPS Target Proxy, which pointed to the same Backend Service used for the HTTP Target Proxy. In other words: 2 Target Proxies (HTTP and HTTPS), but only one Backend Service).
Since Healthchecks are employed by Backend Services, the only Healthcheck required was the (original) unsecure Healthcheck, i.e.
http://[INSTANCE_IP]:8080/admin/healthcheck
The next sentence is important to:
The Beta release of HTTPS load balancing only supports a single SSL
certificate with a single load balancing service.
If the beta release only supports a single SSL certificate, I assume this certificate belongs to the LB, and therefore, on the beta at least, it's not actually possible to secure individual instances.
I cannot find authoritative information about how WSS interacts with HTTPS proxies and load balancers.
I have a load balancer that handles the SSL (SSL off-loading), and two web servers that contains my web applications and handle the requests in plain HTTP. Therefore, the customers issue HTTPS requests, but my web servers get HTTP requests, since the load balancer takes care of the SSL certificates handling.
I am developing now an application that will expose WebSockets and SSL is required. But I have no clear idea about what will happen when the load balancer gets a secure HTTPS handshake for WSS.
Will it just relay the request as normal handshake to the web server?
WebSockets use a "Upgrade:WebSocket" HTTP header that is only valid for the first hop (as there is also "Connection:Upgrade", will this be a problem?
Cheers.
loadbalancers can normally deal with websockets - also including ssl offloading shouldn't be an issue - BUT you have to configure the LB to take care about HTTP and not only to take care about balancing the traffic based on Layer 3 infos - therefore, you have to ensure that the LB has to take care about the session state.
i don't know what LB you are using - but e.g. with F5 LBs you just have to assign a http profile to loadbalance websocket based apps.
If you want to do ssl offloading additionally - just assign an ssl client profile to your virtual server.
http://support.f5.com/kb/en-us/solutions/public/14000/700/sol14754.html
I would have thought SSL-terminating LBs handle WebSockets as well, but I had to realize I was mistaken, once I tried. So the answer for F5 LBs, as of January 2013, is: It won't work. The gist of the answer I was given over at serverfault:
As of December of 2012, BIG-IP doesn't support SSL offload of WebSocket traffic.