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.
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 had studied on many sites but got confused about port 443
Anyone please provide me complete information on Port no 443.
Thanks for your response.
Is it only for http or also used for ssl or any other
A port can be used for basically anything that is to be exposed on the network, 443 is no different from any other port really. But, I'm guessing you don't want info about how ports work, but rather what port 443 is used for by most often.
Port 443 is the default port for secure HTTP aka https, that is, http with Transport Layer Security (earlier called Secure Sockets Layer). Just as with http, it's a port that web servers uses but unlike standard http enforces the usage of secure certificates, most often created by a Certificate Authority that is known by the web browsers as a secure authority.
So when connecting to a page via https instead of http, using a certificate which the browser (or computer) have either added as a safe certificate or have not. If not, it will tell you so and show an exception or warning (at least most browsers will do that).
TLS requires the certificates, and the reason is that the server encrypts the data that it sends to the client, and then the client decrypt it making the whole stream of data less easy to catch for someone whom should not have the data, i.e., a hacker or similar.
If you are running a webpage, you should make sure that you have valid certificates. Both Chrome and Firefox marks pages without TLS as unsafe and if you have any type of data transfer from page to server (say a form with data for the user to add for example) TLS is pretty much a must to make the data transfer safe.
TLS certificates used to be quite costly, but now a days there are services such as Let's Encrypt and Cloudflare which provides safe and free certificates, either as one you install on the server, or a shared certificate as in the "free" version from Cloudflare.
Personally I find it worth to create a self signed certificate (a certificate from my own Certificate Authority, not a big one which is validated by the browsers) for local development too and add it to the certificate storage so that even my localhost uses TLS, but that might be overkill in some cases.
TLDR;
The port 443 is often used for HTTPS (http with TLS), it's good. Use it.
In my Grails app (2.3.11), my login page sends an Ajax request to:
https://myurl/my-app/j_spring_security_check
but spring-security redirects to:
https://myurl:80/my-app/login/ajaxSuccess
This results in a timeout error (because port 80 is added on the URL).
This problem only occurs when my client accesses the application through their traffic manager(Big-IP); if they access the application directly through server IP, it works correctly.
Is there any configuration I can do in Grails to fix this problem? I'm not sure if this problem is related to the application or Big-IP.
These are my configs (Config.groovy) related to spring-security plugin:
grails.plugins.springsecurity.successHandler.defaultTargetUrl = '/login/authSucccessExtJs'
grails.plugins.springsecurity.successHandler.alwaysUseDefault = true
grails.plugins.springsecurity.failureHandler.defaultFailureUrl = '/login/authFailExtJs?login_error=1'
grails.plugins.springsecurity.password.algorithm = 'MD5'
The problem is your application is receiving http traffic because you are offloading ssl at the BIG-IP, so it returns http links to your client. There are a few potential solutions.
Configure grails to set all URLs to https, even though requests are http
Insert the header X-Forwarded-Proto: https (if grails honors this) at the BIG-IP via a local traffic policy or an iRule (you can test this from curl by inserting the header there to see if that helps)
Rewrite https to http URLs on BIG-IP in response traffic via a stream profile or an iRule. This can be very problematic with AJAX but otherwise will work, however, option 1 or 2 would be far more efficient and less maintenance.
On AWS OpsWorks. I'm using an ELB, which has my CA's SSL certificate.
The first point of access is always the load balancer (ELB). The ELB directs traffic to the instances. The instances each have a copy of the Rails app, Unicorn, etc.
One thing to note. The instances behind the ELB cannot be accessed directly.
At this point, do I need to force_ssl in Rails? I hear it's common enough to terminate SSL at the border (ELB).
As far as I've read, force_ssl gives the following:
Automatic redirect traffic from http to https.
Flagging cookies as secure and some added protection (i.e. against MITM attacks).
http://api.rubyonrails.org/classes/ActionController/ForceSSL/ClassMethods.html only indicates http to https redirection.
What does force_ssl do in Rails? second answer suggests that force_ssl does more than redirection.
If I decide not to use force_ssl, I can manage redirects by writing Nginx definitions.
Given the scenario, it feel like forcing SSL via Rails is obsolete, since the SSL negotiation is already happening in the ELB. Is it still necessary to force_ssl? Are there any added benefits?
if you're terminating SSL at the ELB level you don't want it. (you want to take http traffic and not be redirected).
bear in mind that in this case the traffic between the ELB and your backend instances will be over HTTP (i.e. not encrypted). this is fine for most cases.
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/