How can we make sure all requests are routed through cloudflare seevers only?
I currently setup dns in cloudflare in proxy mode. I set a custom domain mapping on cloud run and pointed dns records for my custom domain to ghs.googlehost.com.
Wondering how to make sure the traffic is received only from cloudflare to avoid abuses.
Update
There is another question about origin pulls but the answer mentions its only possible through OAuth which is not in detail.
You cannot achieve your goal without inserting a proxy that you must build. Google Cloud authorization is OAuth. Cloudflare's servers do not implement OAuth authorization headers.
You should implement OAuth at your clients. However, that will provide for authorization but not selectively from Cloudflare.
Related
From my research I'm not getting an answer after referencing:
Custom SSL doesn't show when using CloudFlare
How to append SSL Origin Certificate with CloudFlare's Root Certificate?
Assets not loaded when using CloudFlare SSL
Cloudflare SSL issue: Request origin does not match request base_url
CloudFlare SSL refused on HTTP access
Wildcard SSL Certificates, Custom Domain Names, and Cloudflare
In my domain register I point my domain nameservers to Cloudflare and under Cloudflare's Crypto set SSL to Full. When I add the URL under Client ID for web application -> Restrictions -> Authorized JavaScript origins and Authorized redirect URIs should I be using HTTP, HTTPS, or both?
My understanding Cloudflare's SSL is a shared SSL and not a dedicated SSL. From Google's documentation I am unaware or able to find when using the Google Login API if the API will work successfully using a shared SSL.
The app is a web application written in Node using Google's Login API and hosted with a custom domain on Heroku. I am able to get the application to work locally and with Heroku's generated URL but I'd like to also implement Cloudflare I'm just unsure what is the correct way to use a shared SSL.
So to sum up, if I own the domain foobar.com in Google's Restrictions should I be using:
http://foobar.com
http://www.foobar.com
or
https://foobar.com
https://www.foobar.com
if the SSL is a shared SSL from Cloudflare?
It depends how do you want to expose your domain to users. Both protocols http/https can be allowed.
However you are trying to use "Google's Login API" = probably Open ID Connect client (SAML client is different), which needs encryption -> so actually, you need to allow only https protocol and then you will have safe configuration.
Ant-Media-Server is running on an IPAdress without any domains. We just set up this server to be used for streaming in order to use it from different domains pointing to different servers.
Since all of our domains use ssl, we face the typical connection problem:
mixed Content: The page at 'https://SOMEDOMAIN.com/QUERY' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://1.2.3.4:56'. This request has been blocked; this endpoint must be available over WSS.
Ant-Media already offers tutorials on how to install a Let's Encrypt SSL Certificate but sadly it is not available for pure IP-Addresses.
Apart from the Ant-Media Service, the server doesn't has any NGINX, NodeJS, Apache or other http Servers installed - the plan was just to use it for streaming by calling the IP-Address.
Do you have any ideas on how to solve that problem?
Unfortunately, this is not possible.
The goal of having a SSL is ensure you are requesting the right domain name besides encrypting the content between your users and your server.
Here are some alternatives:
create an endpoint in your own app that proxies data to your server.
Instead of playing the IP address, you can play:
/your-proxy-url?stream=http://yourIp.com:port/....
Note that using a proxy will make all the traffic pass through your web app.
As a reference, if you are using PHP on your website, you can have some ideas from here: https://gist.github.com/iovar/9091078
Create a reverse-proxy in front of your web app that redirects the traffic to your IP address.
Both solutions does not change your Ant Media Server, just adds a new resource between your users and your streaming server - adding the SSL on it.
More of a theoretical question, but I'm really curious!
I have a two part application:
Apache server hosting my UI
Back-end that services all http requests from the UI
The apache service proxies all http requests from the UI to the server. So, if the user is reasonably adept, they can reverse engineer our API by inspecting the calls in the browser's developer tools.
Thus, how do I prevent a user from using the server API directly and instead force them to use the UI?
The server can't determine whether a call came from the UI or not because a user can make a call to myapp.com/apache-proxy/blah/blah/blah from outside of the UI, apache will get the request and forward it to the server, which will have no idea it's not coming from a UI.
The option I see is to inject a header into the request from the UI, that indicates the origin of the request as the UI. This seems ripe for exploitation though.
To me, this is more of a networking question since its something I'd resolve at the network level. If you run your backend application in a private network (or on a public network with firewall rules) you can configure the backend host to only accept communication from your Apache server.
That way the end-user can't connect directly to the API, since its not accessible to the public. Only the allowed Apache server will be able to communicate with the backend API. That way the Apache server acts as an intermediary between the end-user (client side) and the backend API server.
An example diagram from AWS.
You could make the backend server require connections to be authenticated before accepting any requests from them. Then make it so only the Apache server can successfully authenticate in a way that end users cannot replicate. For example, by using SSL/TLS between Apache and the backend, where the backend requires client certificates to be used, and then issue Apache a private certificate that the backend will accept. Then end users will not be able to authenticate with the backend directly.
So I'm working on something in C# that uses the JSON API from CloudFlare to automate the process of adding DNS records. However the website shows a grey cloud that must be clicked to orange to enable their service. I was wondering if there was a way of doing this in C# since I can't see the functionality in their API.
Ah! Found a solution to my problem. CloudFlare don't mention in their API that you can specify the proxied mode to true in the JSON data you send in the POST request to create the DNS record.
I have 2 web roles in a cloud service; my API and my Web Client. Im trying to setup SSL for both. My question is, do I need two SSL certificates? Do I need 2 domain names?
The endpoint for my api is my.ip.add.ress. The endpoint for my webclient is my.ip.add.ress:8080.
Im not sure how to add the dns entrees for this as there is nowhere for me to input the port number (which I have learned is because its out of the scope of the dns system).
What am I not understanding? This seems to be a pretty standard scenario with Azure Cloud Services (it is set up this way in the example project in this tutorial, for instance http://msdn.microsoft.com/en-us/library/dn735914.aspx) but I can't find anywhere that explains explicitly how to handle this scenario.
First, you are right about DNS not handling port number. For your case, you can simply use one SSL certificate for both endpoints and make the two endpoints have the same domain name. Based on which port is used by user request, the request will be routed to the correct endpoint (API vs. Web Client). Like you said this is a relative common scenario. There is no need to complicate things.
Let's assume you have one domain www.dm.com pointing to the ip address. To access your Web API, your users need to hit https://www.dm.com, without port number which defaults to 443. To access your web client, your users need to hit https://www.dm.com:8080. If you want users to use default port 443 for both web api and web client, you need to create two cloud services instead of one, then web api on one cloud service and web client on the other cloud service. Billing wise, you will be charged the same as one cloud service.
Are there any reasons you want to make 2 different domains and in turn 2 SSL certificates? If so, it is still possible. Based on your requirements, you may have to add extra logic to block requests from the other domain.