I am having a problem with an old school asp.net site that has been moved behind a SSL terminated loadbalancer. All traffic to IIS is coming from the load balancer as port 80 http traffic. IIS is rendering all the script/image/link urls into http://....
The problem for us is the client browers are seeing pages with absolute URLs containing http protocol links within a https:// page. The browsers are warning about mixing secure and insecure content.
How can this be fixed so that the links are generated with https:// instead of http://
Thanks in Advance
bille
We solved our issue. The problem turned out to be the load balancer configuration. The client is very compartmentalized and denied us access to the LB swearing that the config was correct. After proving to them that telnetting into 443 was being blocked for some stuff we were allowed access to the LB. In addition to just being set up wrong (cut and paste) the LB url rewrite rules were messed up. Fixing those all is good.
Related
we have activated HTTP Strict Transport Security in production. It works well. But now, when wanting to use a subdomain to develop, the website is automatically redirected to https:
https://dev.tokeeen.com/app_dev.php/my-habits
Event if the host is set to 127.0.0.1
127.0.0.1 dev.tokeeen.com
Is there something to avoid this behavior? Of course I don't want to force the host for the main domain.
You are currently setting this on your main site:
Strict-Transport-Security max-age=63072000; includeSubDomain
If you change this to remove the includeSubDomain bit then it will only apply to your top level domain and not the dev sub domain:
Strict-Transport-Security max-age=63072000;
You then need to visit your production site to load this header and overwrite the existing one in your browser’s cache.
However this is less secure (for example someone could set up www.tokeeen.com and pretend to be your site with a bit of DNS manipulation for example).
But to be honest you should just use https on you’re dev site. The Internet is moving towards HTTPS and many new features do not work under plain HTTP. Additionally what you are developing is not similar to your production site so if you include http:// links instead of https:// for example you’ll suddenly see this failing when you release to production.
You look to use LetsEncrypt on your site so the cert is free. Do yourself a favour and just get another free one for your dev subdomain.
You have to get yourself a wildcard certificate as the ssl certificate is only for that domain. That's the whole point of having a secure site.
I'm not sure what server system you are using but in case you don't want to use wildcards and are ok with less secure, you can bind the other domains to
port 80 with the binding type http`
On my Ubuntu deployment server Nginx is dropping a custom request header (a token), only if the request is coming from Microsoft Edge or Internet Explorer. Requests coming from Firefox, Chrome or Safari just work fine.
I've done a tcpdump to check the difference between the incoming requests, and the requests look exactly the same (only the User-Agent is different, which seems normal). All the browsers are sending the token to nginx
Because my header contains an underscore, I have in nginx.conf the line
underscores_in_headers on;
I am logging the header in access log of nginx,and it shows up for all browsers but IE.
Nginx is proxying to a Python Flask application, using gunicorn. In the Flask application I immediately log the incoming requests and the token is disappeared if the browser is IE. So apparently nginx drops the header before sending it to gunicorn.
Any advice what can cause this.
TLDR: Do you use a WAF? Maybe a WAF as a service?
I'd suggest you investigate your full infrastructure/routing topology. There may be load balancers/things in the path that you're not taking into account.
We literally just ran into this exact same issue at my work and your post was the only thing on the internet that sounded like our problem. We ended up figuring out the root cause.
Here's a simplified version of our topology from a DNS routing perspective:
newwebsite.company.com --> Web Application Firewall as a Service (if this fails it fails open) --> Nginx+ (with WAF plugin) --> Kubernetes Nginx Ingress Controller --> Custom Angular Javascript frontend hosted on Nginx Pod
legacywebsite.company.com --> F5 load balancer --> Windows IIS Web Server.
(There was a section of the new site that used the same backend server of the legacy website, and we'd see hidden 500 errors if we used Chrome Developer Tools.
We checked IIS logs and found out headers with underscores were getting stripped from the clients HTTP request b4 they'd get to the backend IIS server/we found out that we had to add underscores_in_headers on; to every Nginx Load Balancer in the path and that fixed it! ... or so we thought. It turned out the problem was fixed for every browser except for Internet Explorer / Microsoft Edge. (Your exact scenario)
The crazy thing is if you were on the one url path of the new site that would forward your traffic to the old site's load balancers, then you were going through a crazy amount of load balancers. (The nginx pod that hosted the Angular Javascript frontend would redirect you to the F5 load balancer). We discovered the root cause by process of elimination to get rid of that crazy amount of load balancers in the routing in a way that involved minimal testing. I edited my hostfile for newwebsite.company.com to bypass the WAF as a Service and point straight to the Nginx+ LB acting as a WAF, and it started working/no more 500 errors for IE/Edge.
Our theory is that our WAF as a Service was stripping out a HTTP header that has an underscore (which Win IIS web servers use), and they were only stripping out this HTTP header for Edge/IE. So we've got a ticket with them explaining the situation and directions for reproduceability.
Having problems accessing the admin over https when it's setup behind CloudFront Flexible SSL.
The admin works fine when accessing over http, but as soon as I change to secure https it ends up in a redirect loop.
I'm adding the following line to wp-config.php to force SSL in the admin.
define('FORCE_SSL_ADMIN', true);
This is due to the fact that CloudFlare's Flexible SSL operates as a reverse proxy and connects to the WordPress installation via http. Wordpress thinks you're connecting via http and does a redirect to the https resource. The browser requests the https resource from CloudFlare and CloudFlare again requests the resource over http from the WordPress server, resulting in another redirect.
Fortunately there's a solution. CloudFlare sends an http header X-FORWARDED-PROTO that is the protocol used in the connection from the browser to the CloudFlare server. We can use this to tell WordPress that even though the request is happening over http, the link to the browser is over https.
In the wp-config.php file add the following line:
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on';
It's also crucial that the above line comes before the following line:
require_once(ABSPATH . 'wp-settings.php');
After making that modification the redirect loop will stop and you'll be able to use the admin again.
This ultimately applies to all reverse proxy servers, not just CloudFlare.
In my case we getting this problem because I configure CloudFront origin incorrect.
cloudfront-> origin -> Origin Protocol Policy -> Match Viewer
after this setting my website working fine
in my case, another source of problems was (I know sounds silly) the DefaultRootObject.
I had this error on my CloudFront and WordPress and was the issue of my Too Many Redirects nightmare. I'm posting that because someone falls into the same stupid error like me.
Cheers
We have two Windows 2008 R2 serveres set up with a Cisco Ace-30 load balancer, and a few MVC and WebForms apps (.net 4.5 and 4.5.1) with federated authentication (thinktecture). The load balancer is configured with ssl, but the traffic from load balancer to web servers is on http. The problem I'm trying to solve is that the part of the url is case sensitive. Take this urls:
https://my-server.temp.net/MyApp/ (working)
https://my-SERVER.temp.net/MyApp/ (working)
https://my-SERVER.temp.net/MyApp/DEfault.AsPX (working)
https://my-server.temp.net/myapp/ (not-working, that is no response)
In the load balancer, I've disabled the default case sensitivity, and from what I've read there's no such setting in IIS. I've tried creating a static website (no auth) and this works as expected:
https://my-server.temp.net/StaticSITE/ (working)
https://my-server.temp.net/staticsite/ (working)
I've also tried setting up a url rewrite rule, and once that rule is applied the the timeout appear. My guess is that it is IIS that rewrites the incomming http request to a new http request, and the load balancer does not recognize its the https request that has been modified. But I'm guessing and beyond my comfort zone here.
So now I'm a bit confused and unsure what's causing the url to be case sensitive. Is it:
The load balancer
IIS
The authentication
Something else
I would be really happy for any ideas or debugging tips
Thanks
Larsi
ok, I figured out the problem (or atleast a solution). The IIS was sending a redirect and that redirect was to a http address.
So when we configured the load balancer to redirect http to https everything works as expected. My guess is that the federation was causing the IIS to do an extra redirect when the casing was not correct, but that's just a thought.
Anyway - http to https redirect on load balancer solved it.
Larsi
I have an IIS6 ASP.NET 2/3.5 site that ALWAYS seems to be caching anything that goes through a https request. HTTP requests always work the same, but i see old/invalid data on https requests.
I see this a lot with pages where i'm doing http rewriting--but in general, it almost seems like the site has one set of values it shows to http requests and another to https requests-- without having any backend code that renders differently based upon the scheme.
Any ideas? Does IIS have a weird ssl caching option i'm not aware of?
The ports were set up wrong in IIS-- although the domain was correct because i was using port 443 it got forwarded to another site (because of host headers setup).