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.
Related
When sending data from a server / device through HTTP, to a destination that is enforced by https, is that data encrypted in transit?
HTTP -> HTTPS
Or does the source and the destination both have to enforce HTTPS?
A protocol is the language between a client and the server. This language might have features including ones related to security. HTTP is basically for browsers requesting web resources from web servers without any encryption, authentication or integrity protection. HTTPS is the same, but one that provides these features (HTTPS is actually HTTP, protected by TLS).
Each tcp connection between components uses one protocol (it's sometimes a little more difficult than that, but let's stick with this, it's good enough for now). In case of web components, it's typically either http or https. Each resource that is downloaded (a page, an image, a javascript file, any resource) is typically downloaded in its own separate connection. Whether that will be http or https depends on how the page references it.
So in practice, if you have a look at a html page that you downloaded over http, it can still reference resources with https urls, in which case those will be downloaded by your browser via https. It can also happen the other way round, a page downloaded over https can reference resources over plain http, but your browser will then warn you.
In short, your question doesn't make sense because you don't "send data through http, to a https destination". If the destination is https, the connection will be using https. In a web application, the page itself can be downloaded via http (in which case the html code and any data embedded in the html itself will not be protected against man-in-the-middle attackers), but it can reference further resources, images, css, javascripts via https, which your browser will then download securely.
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!
My application is based on Spring framework and is used to transmit very confidential data.During testing of the application with with proxy tools like Fiddler, Paros Proxy etc. it was found that these tools are intercepting the request data, and data is easily modified before reaching the server.
My application is not currently not integrated with SSL . We will implement SSL /HTTPS. but is this because SSL has not been integrated ?
Is it normal for Proxy tools to intercept the data from a web application with out HTTPS ?
There are two things here.
1) If you don't use SSL the communication is not encrypted, which means that anybody who is able to intercept the traffic, will be able to see the content. You don't necessarily need a proxy for that.
2) With an intercepting HTTP proxy you can see SSL encrypted traffic as well. What the proxy does is building two separate SSL tunnels one between the server and the proxy and one between the client and the proxy. This way the proxy itself can see the whole traffic. Of course the proxy can only provide a fake SSL certificate which will trigger a notification in the browser for the user, but he will probably ignore it.
Yes. If you don't use https, Proxy see everything that the application send or received.
To prevent that, you must use https.
To prevent sslstrip you must use HSTS.
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
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/