I have set up an application gateway(AG) to eventually protect my web app using this link but with the difference that the AG's public IP will forward the requests to my web app and I won't be using any jump box.
This diagram should give you a better idea.
Now on my web app, I have added couple of domains under the Custom domains and I don't have any SSL binding thinking that the AG will do the work. Basically I have added the SSL cert to the AG's Front End IP--->Listener. I also redirect the HTTP to HTTPs on AG using the listeners, and on the web app I am not forcing HTTPS.
My questions are:
Is this roughly the right way to protect a web app (Please note that in the future I intend to enable WAF and the DDOS protection on AG)?
Is having the AG do the encryption/decryption going to slow things down?
EDIT: I actually removed the two domains from the web app's custom domains and it seems to work fine without it but I still have the above two questions. :)
Yes, this is the way of doing it, if you want to can configure end-to-end ssl (a bit more secure)
Obviously it will, but negligible.
Related
We use Google App Engine and the provided load balancer to do SSL offloading for our API requests which are served by NodeJs. A third part is using Fortify to determine that even though it is https to the outside, because it is http inside the containers, it is considered a vulnerability.
Everything we read suggests setting the environment up this way.
Is this really a vulnerability and if so, how would we best mitigate against this without having to add paid certificates into our Node app.
Thanks in advance
Is this really a vulnerability and if so, how would we best mitigate
against this without having to add paid certificates into our Node
app.
Yes, the proxy of HTTPS to HTTP is a vulnerability as data is decrypted in transit. However, the connection between the frontend and your application is very hard to exploit outside the Google data center. I am not aware of a method to exploit this item.
In the cloud and on-premises data centers, proxying of HTTPS to HTTP is very popular. This offloads the CPU intensive process of encryption and decryption.
In security, there are almost always exceptions that need to be documented. This is one of them.
For the second part of your question, the proxy is HTTPS -> HTTP. This means that you cannot add your own SSL certificate to your backend code. If you did, you would have connection protocol errors.
If you must mitigate this problem, then you must select a different service and deploy your code with frontends/backends (web servers/proxies/load balancers) you configure and control.
I am creating a standard multi-tenant site that has the following structure:
example.com
tenant1.example.com
tenant2.example.com
The hosting is Azure web apps. Tenants are generated dynamically (there could be many) and the site includes real-time components, so utilises Azure SignalR. The site will have a wildcard SSL/TLS certificate to enable the subdomain structure.
Rather than going direct to the app service in one region, I'd like to put a load balancer in front of this and route traffic to regional clusters, or maybe even isolated instances for larger clients. It would also be good to have the DDOS protection that comes in-built with these things.
Azure Front Door was my first investigation, this can handle wildcard certificates but doesn't support SignalR.
Application Gateway was my next investigation, this can handle SignalR, but doesn't support wilcard certificates.
In terms of DDOS attacks, it seems we can enable a form of protection directly on the web apps. However, to me, this seems like it would throttle an attack rather than provide (low-cost) protection, as I believe a load balancer would.
How can I load balance this situation please?
I have started creating my own nodejs app (for the first time) that I hope to deploy at some point, perhaps to Heroku or another platform.
I need for my app to encrypt traffic namely for user passwords and sessions (note there is no other obviously sensitive data).
I started looking into serving my app using HTTPS (SSL) however I am now wondering if I need this. If my app is to be hosted and deployed using Heroku/other platform won't all requests be trafficked through their servers presumably using HTTPS by default? I am guessing that the request will then be routed using HTTP to my application, although I am struggling to understand how this works. Ultimately I would like to know if I can ignore worrying about paying for SSL certification and such like when it will not matter in this hosting environment?
Help much appreciated. Matt.
If you are using heroku then you must be using paid dyno( hobby or professional) and heroku provides free SSL to all paid dynos. Furthermore if you think that at some point you can switch hosting then there is always freessl available via Let's encrypt.
Heroku serves all requests with and without SSL in default herokuapp url.
Use cloudflare free plan. Open a free account in cloudflare, Copy the DNS. Then set the DNS in your domain service provider (godaddy or sth), then change the Cname config for the website inside cloudflare. Now you have a free certificate.
Given I have a HTTP (non-secure) web server up and running with the public address 111.111.111.11:80.
Are there any / what Microsoft Azure products, where I can setup my own custom domain (mydomain.com) as a HTTPS front/reverse proxy to my web server without buying my own certificate?
(Currently, I am using Cloudflare Crypto to achieve this, so I am investigating if Microsoft Azure can achieve this as well in an easy way)
As far as I know, the recommended Azure way to do this would be to use Application Gateway and a CNAME for the custom domain. This question also has some information on using a custom domain for Application Gateway.
However, if you want to use a custom domain, you will need to buy a certificate. You can do this through Azure as well. You can then use the certificate for the Application Gateway.
Edit: Sorry, Application Gateway does not seem to support the static public IP in your scenario. You would need to work around that. It might be easier to go a different route then...
I have a Node.js app that serves http requests. Users can signup, create an account and when they do, I generate a subdomain for them to use. eg username.example.com. This is fairly straight forward to do and can be served over ssl using a single certificate.
I would like to give the option for the user to use their own domain. From Node.js this isn't too difficult either. I can check the hostname and look up the account details from there.
I'm struggling to work out how to generate ssl's for these custom domains though.
Right now, my app runs on Heroku, but I also have a staging build on Google's App Engine, so I don't deal with the web server directly. In fact, I don't even know what it is, it could be Nginx or Apache.
To keep the conversation focused, let's stay I want to stick to app engine. When a user adds their own domain, I store it in the database. How would I auto generate an SSL for this?
I thought of general steps for this, but there is one showstopper which I'm not sure it is possible to workaround. The steps will be:
Map the user's domain to your application and configure the DNS records. You can do that with the gcloud commands: steps and general description outlined in this Mapping Custom Domains docs page (notice that you can switch between Console and GCloud in the boxes). There is also a possibility of doing that within the Cloud Console, however as you've mentioned you're interested in the programmatic approach. If you prefer to configure the custom domain from the API, the same functionality exists in App Engine Admin API with its REST resource for domain mappings.
Possible showstopper (source: Mapping Custom Domains) :
Verify that you are the owner of your domain through Webmaster Central
After that, App Engine provisions a managed certificate and then handles renewing/revoking it. Securing Custom Domains with SSL is still in beta, but it offers the functionality that you need.