I would like to know some connections that depart from my application.
So I use a proxy (in particular I'm using Charles for OSX) This works fine.
I have noticed that some of these connections are HTTPS (TLS). This is ok, but for these connections, I can only see the base URL and not the complete URL that is invoked. For example I can read: https://www.thewesite.com:443
I would expect not to see the body of the request but at least the header, and then also the whole URL I would expect to see it.
is that correct? is there a way to display the complete URL?
Since URL and the rest of the HTTP header are inside the encrypted connection you would need to enable SSL Proxying (that is Man-In-The-Middle attack) for the specific hosts. See http://www.charlesproxy.com/documentation/proxying/ssl-proxying/
Related
From the Electron renderer, I am accessing a local GraphQL endpoint served by a Django instance on my computer, which I'd like to do over HTTP, not HTTPS. But Electron's Chromium seems to intercept my fetch request and preemptively return a 307 redirect.
So if my fetch request is POST to http://local.myapp.com:3000/v1/graphql, then Chromium returns a 307 and forces a redirect to https://local.myapp.com:3000/v1/graphql, which fails because my server is listening on port 3000 and for my use case I can't do a local cert for local.myapp.com.
Theoretically the first insecure request should be hitting an nginx docker container listening on port 3000 without any SSL requirement. And nginx is proxying the request to a Hasura container. But I'm not even seeing the requests in the nginx access logs, so I'm pretty sure the request is being intercepted by Chromium.
I believe this StackOverflow comment summarizes well why this is happening: https://stackoverflow.com/a/34213531
Although I don't recall ever returning a Strict-Transport-Security header from my GraphQL endpoint or Django server.
I have tried the following code without success to turn off this Chromium behavior within my Electron app:
import { app, } from 'electron'
app.commandLine.appendSwitch('ignore-certificate-errors',)
app.commandLine.appendSwitch('allow-insecure-localhost', )
app.commandLine.appendSwitch('ignore-urlfetcher-cert-requests', )
app.commandLine.appendSwitch('allow-running-insecure-content', )
I have also tried setting the fetch options to include {redirect: 'manual'} and {redirect: 'error'}. I can prevent the redirect but that doesn't do me any good because I need to make a successful request to the endpoint to get my data.
I tried replacing the native fetch with electron-fetch (link) and cross-fetch (link) but there seems to be no change in behavior when I swap either of those out.
Edit: Also, making the request to my GraphQL outside of Electron with the exact same header and body info works fine (via Insomnia).
So I have a couple of questions:
Is there a way to programmatically view/clear the list of HSTS domains that is being used by Chromium within Electron?
Is there a better way to accomplish what I'm trying to do?
I think the issue might be from the server, most servers don't allow HTTP in any possible way, they'll drop the data transfer and redirect you to HTTPS and there's a clear reason why they would do that.
Imagine you have an app that connects through HTTPS to send your API in return for some data, if someone just changed the https:// to http:// that'd mean the data will be sent un-encrypted and no matter what you do with your API key, it'll be exposed, that's why the servers don't ever allow any HTTP request, they don't accept even a single bit of data.
I could think of two solutions.
Chromium is not the reason for the redirect, our Django instance might be configured as production or with HTTPS listeners.
Nginx might be the one who's doing the redirecting (having a little bit of SSL def on the configuration)
Last but not least, just generate a cert with OpenSSL (on host http://local.myapp.com:3000/) note: include the port and use that on your Django instance. You can trust the certificate so that it could work everywhere on your computer.
I have implemented services calling with http.
now services layers is moving to https.
At client side do i need to change any thing or
rename all url http to https
Need small clarification on this.
There is nothing special that you need to do. Just change "http://" to "https://" and your connection will be secured by SSL.
You can, optionally, add steps to validate the authenticity of the certificate being used (eg CA validation). But simply adding the "s" will ensure that the traffic is encrypted.
You should not change http scheme to https on client application. The way is that when your client app comes to your http (80) port your should redirect it to https (443) port by putting Location header in HTTP response.
In next versions of your client app you may have to change your protocol directly to https in order to avoid unnecessary traffic and server requests.
Using fiddler I can intercept an ajax post request and with request composer I can resend the same request, causing the server to respond it normally. It doesnt matter if protocol is http or https (fiddler deciphers HTTPS traffic), with tools like Fiddler it is just possible.
On web applications side is it possible to understand or prevent such requests? How?
No. There's no way to prevent this. URLs are meant to be accessed. If it shouldn't be accessed, don't put it online or require some method of authentication. Some clients may pass an identifiable User-Agent header that can be restricted, and Fiddler probably does as well. However, the whole point of tools like Fiddler is to be able to make any type of custom request, which includes this User-Agent string. So, even if you block the default User-Agent, there's nothing stopping the user of Fiddler from changing the User-Agent to something that won't be blocked.
I am trying to check the incomming request to my server. Another server which has hosted MVC application. An action method is sending some data to my server. I am using Fiddler. But somehow it is not showing the incoming request.
Below mentioned are my settings in Fiddler Custom Rules..
static function OnBeforeRequest(oSession: Session) {
if (oSession.host.toLowerCase() == "IP Address:8888")
oSession.host = "IP Address:82";
}
Below mentioned are my Fiddler Options.
Am I missing anything ?
It sounds like you're trying to use Fiddler as a reverse proxy. You should read the steps at http://www.fiddler2.com/r/?reverseproxy. The biggest thing to understand is that when running as a reverse proxy, you only see traffic in Fiddler if the client's URL is changed to point at Fiddler.
If it is ssl connection then you need to enable option 'capture https connection' from 'https' tab. Did you try to invoke request from other browser like chrome ? Does fiddler capture anything?
You don't need custom rule for this case. It should work if you enable these settings. I have faced only some problems in other browsers like FF.
I'm not sure I can answer your question fully without knowing a few additional pieces of information.
If the request being made is not a HTTP request, Fiddler will not be able to handle it.
Also, if you're using the loopback address localhost then Fiddler may not be able to find it.
If we have something like this url:
https://www.example.com/Some/Page/index.html?id=15
I know that example.com will be sent as plain text, but /Some/Page/index.html?id=15 is sending securely.
Now, my question is, if we have something like this:
https://somesubdomain.example.com/Some/Page/index.html?id=15
May attackers know that I'm visiting somesubdomain.example.com? or they just can know I'm visiting example.com?
In other words, is subdomain part of url sending securely?
If the client is using Server Name Indication (most modern web browsers/platforms do), the host name (not the rest of the URL) will be visible in clear in the handshake in the server name indication extension, so both www.example.com and somesubdomain.example.com will be visible.
If the client isn't using SNI, an eavesdropper would still see the server certificates and the target IP address(es). Some certificates can be valid for multiple host names, so there may be some ambiguity, but this should give a fairly strong clue to the eavesdropper.
In addition, the same eavesdropper might be in a position to see the DNS requests (unless you've configured the hosts explicitly in your hosts file perhaps).
In general, you shouldn't assume that the host name you're trying to contact is going to be hidden. Whether it's a subdomain isn't relevant, it's the full host name as it's requested by the client that matters.
When using https all traffic between http client and server is encrypted. That does not mean it is safe, but it is encrypted according to what you refer here. Something a network sniffer can see is the ip address you communicate with. That is regardless of what network name had been resolved to that address.
Simply try yourself and use a network sniffer. I recommend wireshark.