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
Related
I've got Fiddler to decrypt https traffic. which works just fine.
http://fiddler2.com/documentation/Configure-Fiddler/Tasks/DecryptHTTPS
But there are some requests that are shown as "Tunnel to" port 443. Also the protocol of these requests are shown as HTTP instead of HTTPS. I do not see the decrypted content of these requests.
on the response details pane, it's shown as below:
Can someone let me know how I can get fiddler to decrypt these tunnelled requests too. Also appreciate if you could provide me some details about what's going on in this case.
Cheers
As noted in the inspector description the line Tunnel to example.org:443 is the first line of a successful captured HTTPS call.
It is notes as HTTP because at that time the HTTPS channel has not been established yet.
If afterwards no further HTTPS requests to that server are shown this means that the program performing the request has not accepted the presented server certificate generated by Fiddler and therefore the HTTPS requests failed.
There are two possible explanations:
The program performing the requests does not trust the Fiddle root CA certificate.
For programs that don't use the Windows certificate store (e.g. Firefox) you have to export this root ca certificate from Fiddler and install it manually into the program's certificate trusted store (list of trusted root-CA certificates).
A second possibility is that the site is certificate pinned. For web browsers this can happen is the web site uses the HSTS configuration.
Recently I have been working on a website project that allows users to login with their Discord accounts to browse the website with their account.
The website utilizes the Flask-Discord library, Quart as my WSGI web framework, Hypercorn as my production server and Nginx as a proxy to pass web requests to my Hypercorn socket. I have set up an SSL certificate using Certbot-Nginx with Let Encrypt as the Certificate Issuer. However, after users are redirected to the Discord login page, the user logs into Discord and the callback is requested to my Quart Server I am receiving the following error:
oauthlib.oauth2.rfc6749.errors.InsecureTransportError: (insecure_transport) OAuth 2 MUST utilize https.
The website is set up and working correctly with a domain setup with noip temporarily and the SSL certificate valid, making all requests redirect to HTTPS instead of HTTP.
Is it possible that because the SSL certificate is set up with Nginx that the Python OAuth2 library is just unaware of the SSL certificate? It seems unlikely considering all requests are being redirected to HTTPS.
I've found plenty of people recommending to prevent such an error to just change the OAuth environment variables to allow for insecure transport but I don't want to compromise the security of the website.
Any ideas as to why this might be happening would be extremely helpful.
Thanks
This is happening because requests coming from Nginx reverse proxy is in HTTP form. Since you're running Quart app locally at say http://127..0.0.1:5000 and when Nginx makes requests to this URL, its starts with http. So insecure transport is done only from Nginx to your Quart app. You can supress this by setting "OAUTHLIB_INSECURE_TRANSPORT" = "true". More highlight on this: https://github.com/thec0sm0s/Flask-Discord/issues/3#issuecomment-676567390
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.
I have a ASP.NET MVC site set up in IIS7 on Win2K8 with a single SSL binding on Port 443. The team in charge of the server only has port 443 open for security reasons, but this shouldn't be any issue because that's the only binding I have and I'm not making any regular HTTP calls on port 80.
When I call my site, my main login page (using forms authentication) comes up in the browser (over HTTPS) which looks fine. However, as soon as I try to login I get the following error:
[SocketException (0x274d): No connection could be made because the target machine actively refused it 10.x.123.123:80]
Ok that is the correct IP assigned to the site, but I'm not making any calls on port 80. Why would I get this error if all I need is a SSL binding on port 443? Am I required to have port 80 open as well? I'm not making any calls internally that use port 80, unless MVC is doing something I'm unaware of that requires port 80.
When digging into the code it turns out that our service turned around and made additional REST calls to other parts of the same service using a HTTP url, thus causing the error.
Since I configured IIS to only allow SSL traffic and I had internal calls to a HTTP URL the error was generated. The root cause was that I forgot we were making RESTful calls within the code and those URLs had to be updated to their respective HTTPS counterpart.
I have multiple sites running on my IIS, now for one of the websites (SiteB) we need to support ssl requests. I have enabled it editing bindings for the website, but the problem is when I selected protocol SSL editing bindings HostName field is disabled, being unable to set hostname to respond to https request, this causes that all sites of my IIS if are requested with https:// loads web site of siteB.
For example my bidings are the next
Site A
IP Port HostName
* 80 www.sitea.com
Site B
IP Port Hostname
* 443 www.siteb.com
* 80 www.siteb.com
If I type https://www.siteb.com in my browser it works correctly, but if I type https://www.sitea.com in the browser, siteb webpage is loaded with the hostname of sitea.
How Can I make that only https://www.siteb.com responds to https requests on my IIS?
I have tried with command appcmd too but It't doesnt work.
appcmd set site /site.name:{sitB} /bindings.[protocol='https',bindingInformation='*:443:*'].bindingInformation:*:443:siteB.com
Thanks for your help.
The Root Problem
This unexpected behavior isn't because of IIS so much as it is because of the web encryption protocols.
The two major web encryption protocols are SSL and TLS. Both of these protocols negotiate a secure connection before passing any request information to the server. This means that, on secure requests, servers don't actually learn the hostname until after the secure connection is made.
An extension to TLS and SSL has been created to address this limitation. It's called SNI (Server Name Identification). The problem is that this extension needs to be supported on both the server and client machines. Currently the client browser support is somewhat spotty. See the SNI article for a browser list.
IIS's Handling Of The Problem
It is because of the above mentioned hostname limitation that IIS doesn't allow you to bind hostnames to HTTPS bindings. There is no way for IIS to route HTTPS requests to a particular hostname since it doesn't know the requested hostname when it first begins to negotiate the connection.
Once IIS has negotiated a secure connection with a client and learns that their requested hostname is for a site other than the one with the HTTPS binding (e.g. a request for https://sitea.com) IIS can either return a failure code or try to fail gracefully. IIS chooses the latter and tries to fail gracefully by serving up the site with the HTTPS binding even though the user is requesting a different site.
Solutions/Workarounds
Create a rewrite rule to redirect all HTTPS requests for nonsecure websites to HTTP.
Upgrade to IIS 8 to use the SNI extension. Then ask visitors to upgrade to browsers that suport SNI.
Have your secure site return an error message when it receives a request for a different domain.
Bind by IP address instead of hostname since IIS can route HTTPS requests by IP address
References
Most of my information came from the Wikipedia article on SNI
We run webservers with multiple sites requiring SSL with no problem.
If I understand your problem correctly - you'll need to set up a binding instead of a host name - which won't work. So, for each SSL-enabled site we host, we require a distinct external IP address. Then, enter that IP address as the binding when setting up the site in IIS.