I am useing quintolabs qlproxy for web filtering. How can I whitelist onedrive so it stays syncronized? What are the URLs and IPs to Whitelist?
Seems the issue is that OneDrive application uses SSL Pinning and thus does not accept mimicked SSL certificate from your Squid proxy. A similar issue for Dropbox is explained at http://docs.diladele.com/faq/squid/dropbox.html.
This same error will be present in all SSL inspecting web filters. For example from the message at Sophos (astaro) UTM support forum it seems the list of domain names to exclude is quite large (see https://www.astaro.org/gateway-products/network-protection-firewall-nat-qos-ips/56579-microsoft-onedrive.html):
skyapi.live.net
storage.live.com
skydrive.live.com
shared.live.com
onedrive.live.com
Please note the list may not be complete. The best is to fire up the WireShark or (better) Microsoft Message Analyzer on the machine where OneDrive is installed and try to see what domain names are sent to the proxy upon start of OneDrive application. Then exclude these from ssl bump.
Related
I am trying to have links in my emails from my application register as SSL/HTTPS secure links. This helps deliverability and other things email clients may do treating links as http vs https.
Our application is using SendGrid to send emails, which also supports click tracking on our links for us. In order to do this SendGrid, and most other email sender services replace the original link we put in, which was an https://blahblah.com link with their own link, http://clicktrack.sendgrid.net or something that is not https, but rather http.
SendGrid supports "white labeling" the click tracking link with something like
http://subdomain.blahblah.com and also https version if we set it up properly. SendGrids requirements for https/ssl link are shown here
https://sendgrid.com/docs/Classroom/Build/Add_Content/content_delivery_networks.html
Basically they are asking us to setup a CDN or other server that will host our SSL certificates, terminate the SSL, and then forward the request on to their servers. Once that is in place they can "turn on" ssl on their end for our email links.
I tried setting this up in AWS CloudFront with the origin as sendgrid.net and the distribution having our SSL certificate and a route 53 CNAME pointing to our distribution. So the subdomain.blahblah.com points to distribution CDN, CDN points to sendgrid, and all should work.
Testing this though it does NOT work. If I go to the http version of subdomain it does work, CDN forwards properly. AWS support has suggested it was an issue related to host headers and the CDN not being able to validate the origin when I had a 2nd CNAME for the origin on my subdomain2.blahblah.com. That led me to remove 2nd cname and direclty put sendgrid as origin, but that hasn't worked and they haven't provided a solution yet. I get error like this..
ERROR
The request could not be satisfied.
CloudFront wasn't able to connect to the origin.
Generated by cloudfront (CloudFront)
Request ID: pl1bS3OObC6mUd2vyyhM6bNFt3xyLsfzVIqNmiPkEO7mQgJyQCn_pA==
Any ideas welcome or a different way to do this?
The issue was in behaviors I was forwarding all headers. Should NOT forward "Host" header in this situation or the origin ssl call will break as it wont match expected. AWS support did finally figure this out and recommend to me :)
I'm trying to set a web service that needs the user's Google Latitude info, so I'm using Google OAuth to get the user authorization stuff.
However, when trying to set the redirection URI in the Google APIs Console for a web application client ID I get a message error if I try to set it to 'http://PUBLIC_IP/'.
I need to test it with non local users (thus localhost can't be used), so I would like to know if having a web domain is mandatory in order to use Google's OAuth. If not, how can I solve this issue?
This is not currently supported. I filed a feature request and will update on progress.
Update: Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can use xip.io to work around it.
For example: '192.168.0.50.xip.io:3000' will resolve to '192.168.0.50:3000'
I ran into this issue too and so I entered a URL with a .com extension and also entered it into my /etc/hosts file. Works like a charm.
It totally sucks that my entire app now has to be developed on an apparently 'live' domain though.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
You can use a dynamic DNS. I used ddns.net which offers a free solution. Basically, you enter your FQDN as this: yourcompany.ddns.net as your domain. When looked up for an IP address, the .net domain points to ddns; when ddns.net is looked up, it looks up in its database for your company, returns the IP. So mine looks like this: https://wigwam.ddns.net and everything works fine. You don't need to buy a domain, you can substitute your known IP, and Google is happy with that.
Your IP must be static, of course.
Yes, as of now you still need to have a domain name to use Google OAuth in your application. If you have a static public IP and don't want to buy a domain name, you could use a free subdomain from FreeDNS to link to your public IP. Seemed to work well enough for me with a Django app.
Echoing what Breno said in response to his earlier comment:
Apologies for the lack of updates here. Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can read more about Google's app verification requirements [1] and Google's policies requiring secure handling of data [2].
[1] https://support.google.com/cloud/answer/9110914?hl=en
[2] https://developers.google.com/identity/protocols/oauth2/policies#secure-response-handling.
xip.io is not working anymore as an alternative you can use nip.io the same way for example:
10.0.0.1.nip.io:8000 will resolve to 10.0.0.1:8000
It seems like xip.io is down, but there are alternatives such as sslip.io and nip.io. However, I couldn't get either of these to work.
I ended up hosting the main file server on the main machine, and ran said server on a 192.168.1.xx IP address. I then ran servers on each of the test machines (including a second server on the main machine), all of which were on the localhost address. Any requests that the localhost servers received were then passed off to the 192.168.1.xx server, which allowed testing on all of the devices.
This should also work with public facing IP addresses.
I'm trying to secure my website with https. I managed to add the certificates and all that stuff but in some parts of the website i get this message "this website contains interactive content that isn't encrypted (such as scripts)". Any ideas on how to fixed this?
The website runs on localhost.
I am using Apache on OS X Mavericks
You have resources on your website (javascript for example) that isn't sent through a HTTPS request, but rather a regular HTTP request.
Try storing the resources on your own website instead of requesting them from a different one.
yes. When you use https ALL pictures, SSC, and JS files should be loaded from your machine
I'm trying to set a web service that needs the user's Google Latitude info, so I'm using Google OAuth to get the user authorization stuff.
However, when trying to set the redirection URI in the Google APIs Console for a web application client ID I get a message error if I try to set it to 'http://PUBLIC_IP/'.
I need to test it with non local users (thus localhost can't be used), so I would like to know if having a web domain is mandatory in order to use Google's OAuth. If not, how can I solve this issue?
This is not currently supported. I filed a feature request and will update on progress.
Update: Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can use xip.io to work around it.
For example: '192.168.0.50.xip.io:3000' will resolve to '192.168.0.50:3000'
I ran into this issue too and so I entered a URL with a .com extension and also entered it into my /etc/hosts file. Works like a charm.
It totally sucks that my entire app now has to be developed on an apparently 'live' domain though.
I used my public hostname. It helps if you have a static IP address. I used http://www.displaymyhostname.com/ to get my hostname. I plugged it straight into the Authorized JavaScript origins field when I created a new Web Application Client ID.
P.S. My hostname looked something like this: 111.111.111.111.static.exetel.com.au
You can use a dynamic DNS. I used ddns.net which offers a free solution. Basically, you enter your FQDN as this: yourcompany.ddns.net as your domain. When looked up for an IP address, the .net domain points to ddns; when ddns.net is looked up, it looks up in its database for your company, returns the IP. So mine looks like this: https://wigwam.ddns.net and everything works fine. You don't need to buy a domain, you can substitute your known IP, and Google is happy with that.
Your IP must be static, of course.
Yes, as of now you still need to have a domain name to use Google OAuth in your application. If you have a static public IP and don't want to buy a domain name, you could use a free subdomain from FreeDNS to link to your public IP. Seemed to work well enough for me with a Django app.
Echoing what Breno said in response to his earlier comment:
Apologies for the lack of updates here. Essential app verification activities have continued to make support of IP address-based apps unlikely. These verification activities are necessary to provide protections against abuse of user accounts. In addition, the cost of setting up dedicated domains has been reduced significantly since this feature was requested. Please read other responses here about possible options.
You can read more about Google's app verification requirements [1] and Google's policies requiring secure handling of data [2].
[1] https://support.google.com/cloud/answer/9110914?hl=en
[2] https://developers.google.com/identity/protocols/oauth2/policies#secure-response-handling.
xip.io is not working anymore as an alternative you can use nip.io the same way for example:
10.0.0.1.nip.io:8000 will resolve to 10.0.0.1:8000
It seems like xip.io is down, but there are alternatives such as sslip.io and nip.io. However, I couldn't get either of these to work.
I ended up hosting the main file server on the main machine, and ran said server on a 192.168.1.xx IP address. I then ran servers on each of the test machines (including a second server on the main machine), all of which were on the localhost address. Any requests that the localhost servers received were then passed off to the 192.168.1.xx server, which allowed testing on all of the devices.
This should also work with public facing IP addresses.
I'm working on a web application that uses the google earth plugin. Recently, a new requirement to have non-public users logon was added, which meant that some users were now using the site over https. Among the things that broke in testing were the custom placemark icons (They were working using http).
The icons are hosted on the same server which servers the page.
Here are the urls for each of the protocols.
http - http://localhost/Images/yellow.png
https - https://localhost/Images/yellow.png
I can follow that link and the image will appear as you would expect.
The images hrefs are declared as icon styles in dynamically generated kml.
I want to avoid loading the images over http because I think that will cause internet explorer to present the user with a mixed content warning.
How do I get the images to load properly while using https?
I have been wrestling with this myself -- the short answer is that this won't work. If the content is served off of an HTTPS site that generates any kind of error/prompt (authentication, invalid certificate, etc.) the plugin will simply not load the content.
Interestingly, the desktop client works fine and prompts the user for credentials if necessary. However, neither client will allow content to be served off of site with an untrusted certificate.
The only workaround that I have found is:
Use a trusted HTTPS certificate on the server hosting the content (either trust the certificate on the client systems or just use a real certificate.)
Do not use HTTPS basic auth as that will always generate 401/Challenge responses which the web browser client will simply ignore
If authentication is a requirement, use NTLM authentication and common (e.g., domain) logins. If you load the plugin in Interent Explorer (or in a .NET WebBrowserControl) the authentication will be handled properly and the images will show up.
I was at a Google Earth administrator's training last week and the trainer confirmed this "bug". It is supposed to be fixed in the next version of the plugin (it may actually be fixed already -- what version of the plugin are you using?)