I need to add all traffic generated by google analytics to a "free of charge" traffic whitelist for mobile devices. But that whitelist does not support HTTPS connections.
Do Google Analytics send requests to somewhere, anytime, through SSL/HTTPS?
Is there a way to prevent it from exchange any traffic between the client and the server through SSL? So that no request on the webpage is made on HTTPS?
Thanks
Assuming you are using Analytics.js, the requests should handle both http and https. Looking at the documentation here:
"By default, tracking beacons sent from https pages will be sent using https while beacons sent from http pages will be sent using http. Setting forceSSL to true will force http pages to also send all beacons using https."
Related
TL;DR: How to authenticate against NGINX if auth headers are not supported on client side?
I am building an IoT-related project using NGINX as a reverse proxy for the server side services and 1NCE as the LTE carrier for the mobile devices. All traffic is authenticated based on HTTPBasicAuth over SSL-encrypted connections and handling "normal" requests works as desired.
As mobile service might be interrupted and the Internet connection might be lost, I want to send SMS for critical status reports and alarm notifications. 1NCE supports SMS mobile originated SMS (MO SMS) which are handled by the 1NCE's internal infrastructure and forwarded to a configurable API endpoint. So, MO SMS are not delivered to a specified phone, but forwarded via an API request which I need to process on my side.
According to 1NCE's SMS documentation and in consultation with their customer support, SMS forwarding does not support any authentication headers. SMS forwarding can only be done by specifying an HTTPS URL (including the desired API endpoint) and a port. The incoming SMS is then wrapped in a request to the given URL and sent in the request body.
I want to add authentication to the SMS forwarding endpoint (receiving forwarded SMS on my side) as well and am currently wondering about how I could achieve this. NGINX supports authentication on subrequest which could be used to evaluate incoming requests by an internal service. So my first idea was to add some credentials to each SMS (as I am also responsible for the SMS sending part of the code on the mobile devices, I could implement whatever is needed) and check those credentials with an internal service called by NGINX's subrequest. However, this does not seem to be doable. According to this SO question GET requests are used for the internal subrequests hence any body of the incoming POST request is discarded. Therefore, the credentials of the forwarded SMS would also be not available to my internal auth service. Extending NGINX's auth capabilities by writing an custom Lua-based plugin was my second idea, but this does not only seem to be not feasible but is also not supported by the NGINX instance I am using (Lua modules are disabled, switching to openresty seems to be a big thing).
My last idea would be to forward all incoming requests to a Python web service (written in Flask, other services I am using are also written in Flask) and parsing the forwarded SMS in Python. Based on the result of the credential evaluation I could return an 401/Unauthorized status code if credentials provided in the SMS (which is part of the request body) are invalid and process the request otherwise. However, I think that this approach is quite ugly as all incoming requests need to be passed to Flask and invalid requests are not rejected at the level of my Reverse Proxy.
Do you have any ideas about how to approach this issue? What would be a considerable approach with regards to "best practises"? Can I extend NGINX in a way to solve this or should I completely drop NGINX in favor of a "better" proxy?
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.
I'm using SSL in my whole site so I get errors when I pull video streaming content from my azure media services account. All of the urls I get for origin server streaming content when I publish are http. I need them to be https. Is there anyway I can configure the origin service or something I can do before I publish to make the service serve these requests with SSL?
Unfortunately Windows Azure Media Services (WAMS) doesn't support Https.
The formats for streaming, like HLS, are actually transfer formats like Http. HLS doesn't by nature support HTTPS. Instead it has other content protection mechanisms, WAMS uses HLS + 128-bit AES. All of the content transferred in the stream is encrypted by AES.
Depending on your security requirements, you shouldn't need to serve the requests with https. The request that retrieves the origin locator url should be https already, the request that stores it in your database should be https, the request that provides the url to a client should be https, so with the default AES encryption it's entirely secure.
I have a problem with my app that I want to use as sink for the push POST requests. I programmed it in Java as a straight forward servlet, I verified that I can send POST requests to it, but the test push from my consumer’s admin page says 404.
Is it possible that I can’t run the push sink on another port than 80? My secure Tomcat port is 8888. I don’t see any calls from the Foursquare servers in my Tomcat access log.
Thanks!
As stated in Realtime API self signed certificate 4sq seems currently not to be able to send POST requests to other ports than 443 (standard SSL).
I worked around this by using the mod_jk connector to let Apache2 send requests to a special directory directly to Tomcat7. This works for me.
I need to implement some search functionalities in my app and want to use Google SSL.
https://encrypted.google.com
Can the ISP still see what you are searching by analyzing the querystring? If so then what's the point of this service?
When using SSL (https) all traffic including the query string is encrypted. All that ISP can see is host address and TCP port number. If the page that you are viewing contains insecure content (http) you should be warned by your browser.