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/
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 know that modern web browsers cache https content by default. But when you use, say, CloudFlare on your https webpage can it ever cache the css/jpg files for the client? I'm expecting the answer is no as its encrypted, but maybe the datacentre is intelligent and can establish its own connection as a client, cache, then serve as a proxy or something using its own certificates. Thanks
Cloudflare is a content delivery network and not a simple load balancer. Because it is expected that they reduce the load on the original server they will cache also https traffic. This means that they will be a man in the middle and provide their own certificate for the site. For more information see their SSL-FAQ.
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.
I have a CloudFront destro in front of my asp.net application, serving dynamic content. All cache periods are set and everything looks ok.
I am using cloudfront mainly to accelerate the site for international visitors.
I have a registration page on the site that uses SSL. I understand that I can't use my own SSL with cloudfront, but is there a way that I can tell cloudfront to point the user to the origin when they navigate to one of the HTTPS pages?
The urls on your secure page must use the https prefix or the browser will complain about mixed-mode content. This means that the requests have to start their lives as https ones. This makes redirection in the manner you suggest impossible.
Your best bet is to have logic in your pages that determines the host portion of your url and protocol so that if it's a secure connection, all your content urls are prefixed with the secure host/protocol in the form https://[cloudfront-secure-hostname]/[your content]
If the connection is not secure, you return your standard CDN hostname using http.
The only down side is that a user will see requests going off to a domain other than yours. This shouldn't be too much of a problem though.
I have a website with only home page available through simple HTTP protocol.
All other pages are accessible only through HTTP over SSL(https://).
I'm using CDN for home page and very happy with it.
But for me it looks like using CDN for https pages is impossible because of security warnings, especially in IE. My files hosted at CDN are accessible though simple HTTP protocol.
What should I do? How this problem can be solved?
You need to get a CDN that supports serving files over HTTPS, then use that CDN for the SSL requests.
You can do this if their boxes have HTTPS support. What you can't do is use a subdomain of your own domain to cname against the cdn network. Because SSL doesn't work this way.
so https://cdn.tld/mydomain/path/to/file as a mechanism does work (because browsers will verify the cdn.tld ssl certificate correctly)
but https://cdn.mydomain.tld/path/to/file will not.
Two options, but in general I'd redirect all pages that don't need to be SSL'ed to their non-SSL equivalent and only use SSL when necessary.
Get a SSL certificate for your CDN host. It's just 30 bucks/year, but you need to take into account that this requires more configuration and depending on the traffic, this is also more expensive because the server requires more resources for SSL'd connections.
For the relevant pages, store the CSS/images/js files "local" on your own SSL host and use them when you need SSL. Of course you loose the speed etc. from the CDN, but that's a trade off. We opted for this because just our signup is SSL, 99.9999% of the time users spend on our website is on non-SSL links.