ASP.Net OData fails with SSL Termination in LB - asp.net

I have an issue using HTTPS to access an ASP.NET OData endpoint. The ASP.NET site is hosted via OWIN. I am using the NuGet package Microsoft.AspNet.WebApi.OData for the OData (v3) part. The SSL termination takes place outside of the server in a separate load balancer.
Accessing the OData endpoints with a REST-client (e.g. Postman) works fine: https://api.my-domain.com/odata/v3
But when I use an OData-client (e.g. Excel or PowerBI), the access fails with the generic message, that the host forcibly closed the connection.
Further I found that when I access the endpoint https://api.my-domain.com/odata/v3 via Postman, I receive some XML metadata, which refers to the normal http endpoint (see below snippet), which is blocked by the LB.
<?xml version="1.0" encoding="utf-8"?>
<service xml:base="http://api.my-domain.com/odata/v3" xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
<workspace>
...
Further I sniffed the traffic from Excel/PowerBI with Wireshark and found that the clients are using the normal http endpoint (as shown in above metadata) after the initial request with https. I am not familiar with the OData protocol details, but I guess the clients are determining the address by the metadata.
For validation I unblocked port 80 in the LB and voila, Excel/PowerBI can successfully connect, regardless if I use http or https for the initial request.
But how to solve this issue (I don't want to allow traffic on http). Is it possible to instruct the ASP.NET OData middleware to generate metadata with https URIs?

Related

There's a way to trace or log network with visual studio (or other app)?

I had some classes that make web request and I can't see the endpoint because its encapsulated in a dll.
so.. there's a way to trace/log this request (http, https) with their parameters?
I tried fiddler, changed the proxy of machine.config, but nothing works...
The scenario is:
Local IIS website that make http request to and remote URL encapsulated in DLL and i can't see or configure the endpoint.

How to force wso2 api manager keymanager component using http?

Currently in the gateway configuration I have to set the protocol to https like:
<ServerURL>https://10.130.10.110:9443/services/</ServerURL>
10.130.10.110:9443 is the https end point of the keymanager. If I switch to the http end point, the token validation will fail.
I searched all the WSO2 AM document and all the config sample are pointing to keymanager using https. It looks like the key manager only supports https, is it possible to change it to http? Because all the servers are deployed inside one VPC, there is no need to use http. The https is too heavy and the overall API gateway performance doesn't look good.
Thanks!

FiddlerCore: HTTP Tunnel Issue

I have an application, and I am trying to intercept its requests with FiddlerCore.
Using Fiddler, I see the requests as follows:
https://i.stack.imgur.com/bhUqK.png
(HTTP CONNECT tunnel into HTTPS request)
When using FiddlerCore, I am only seeing the initial HTTP CONNECT tunnel, and the application is not requesting. after that, stating:
Failed to connect to server.
This is the code I'm using in the BeforeRequest method:
if (oSession.HTTPMethodIs("CONNECT"))
{
oSession["x-replywithtunnel"] = "FakeTunnel";
return;
}
And the output from the FiddlerCore program (upon running the application):
https://i.stack.imgur.com/0Fc2q.png
The application is a Java application, which I had to create a keystore for using the FiddlerRoot certificate, and I am wondering if this is where the problem lies.
(Images as such since low reputation)
Solution: FiddlerCore uses a different SSL certificate than Fiddler itself.

Https communication on localhost in IIS using self-signed certificate

I have 2 sites running on the same machine, a client and an API.
Let's say the computer's IP is 10.10.10.10.
The API has a default page when you browse to it, the rest of the API is under 10.10.10.10/api.
The API has HTTP binding to port 80, and HTTPS binding to port 443.
The client has HTTP binding to port 8080, and HTTPS binding to port 64300.
Both HTTPS bindings use a self signed certificate I created via IIS manager.
Both sites have a HTTP to HTTPS redirect using "URL Rewrite".
When I try to browse either one of the apps, it works fine (gives the warning in the browser that you can skip).
When I do some action in the client which involves a HTTP request to the api using one of the following calls I get an error:
http://localhost/api/someMethod
http://localhost:80/api/someMethod
https://localhost/api/someMethod
https://localhost:443/api/someMethod
https://10.10.10.10/api/someMethod
The exception includes this error:
"The remote certificate is invalid according to the validation procedure"
I tried using the method described in this link (add the self-signed certificate to the Trusted Root Certificate Authorities folder) but it won't work.
Help please :D
found the answer.. posting if anyone else will get stuck on it.
It's pretty weird but the only thing that worked was to make the localhost http(s) request using the HOST NAME.
example:
https://the_name_of_the_computer:443/api/someMethod

ASP.NET Request.ServerVariables["SERVER_PORT_SECURE"] and proxy SSL by load balancer

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.

Resources