How can I make IIS and ASP.NET aware of SSL Offloading so that it uses correct protocol for Response.Redirect?
I am working with a client who is using F5 load balancer with SSL offloading. The IIS web site (and ASP.NET web app) are bound to HTTP, not HTTPS, and so whenever ASP.NET uses Response.Redirect(url) it results in 302 redirect to http instead of https
Obvious solution would be to bind to HTTPS in IIS, but client does not operate that way. They have numerous other applications (mostly on apache) and report that it works just fine (it is somehow aware of SSL Offloading). SSL terminates at the load balancer, meaning user-to-load balancer is HTTPS, and then load balancer-to-server is HTTP. And they want to keep it that way (makes it easier for IDS to detect attacks in encrypted payloads, IT can snoop on users, etc.).
We've tried URL Rewrite module (from Microsoft) with very limited success. Client's IT dept reports they have also tried some configuration with F5 but I am not familiar with this product and apparently neither are they. It would be much easier if we could just force a flag in IIS or something, but I have been looking over Msft docs with no answer found so far.
Looking for a solution that is applied only to IIS, please. Thanks!
Related
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've got an internal web application that's designed to work in concert with a server running locally on the client machine. (For the curious: the local server is used to decrypt data retrieved from the server using the client machine's GPG key.)
The internal web app is served over HTTPS while the local app is accessible via localhost. It used to be that I could make unencrypted AJAX requests from the page to localhost without any issues; but it seems that recently Chrome was updated to disallow HTTP requests to any destination from pages served over HTTPS.
I understand that in the vast majority of cases, HTTP requests from a page served via HTTPS constitute a security hole. However, since I have complete control over the endpoint in this case (i.e., localhost), it seems to me that it should still be perfectly safe to make HTTP requests to that one destination even when the host page has been served via HTTPS.
Is this possible? To whitelist localhost somehow?
Since you are in control of both the client and the server, it sounds like a good candidate for Cross-Origin Resource Sharing (CORS). The server will have to set a few response headers to give access to the client. You can learn more here: http://www.html5rocks.com/en/tutorials/cors/
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).
We have some legacy ASP.NET code that detects if a request is secure, and redirects to the https version of the page if required.
This code uses Request.ServerVariables["SERVER_PORT_SECURE"] to detect if SSL is needed.
Our operations team has suggested doing proxy SSL at the load balancer (F5 Big-IP) instead of on the web servers (assume for the purposes of this question that this is a requirement).
The consequence would be that all requests appear as HTTP to the web server.
My question: how can we let the web servers known that the incoming connection was secure before it hit the load balancer? Can we continue to use Request.ServerVariables["SERVER_PORT_SECURE"]?
Do you know of a load balancer config that will send headers so that no application code changes are needed?
Use an iRule to effectively add a custom element to the HTTP header and then detect it in the ASP.NET code via Request.Headers. Dig into the collection of the Request.Headers object as well as your F5 hardware may already be marking itself on one of the HTTP Headers anyway.
I am quite new to HTTPS and can not get my head around it.
Can someone suggest good starting point for learning about HTTPS, certificates and signing?
Possibly with a working example in ASP.NET with IIS.
If all you are trying to do is have your site in HTTPS there is no code needed. All you need to do is set IIS to serve pages with HTTPS.
If that is all you want, you are better off asking this question in http://www.serverfault.com.
To get you started, here's a link on how to set https in iis 7: http://learn.iis.net/page.aspx/144/how-to-setup-ssl-on-iis-70/
HTTPS is just normal HTTP traffic that is encrypted using SSL/TLS. The protocol is fairly straightforward. I wrote a detailed blow-by-blow of what happens at the start of a connection on my blog: The First First Few Milliseconds of an HTTPS Connection.
It's unfortunate that the APIs built on top of the protocol are often much more complicated.