Our development team has spent countless hours setting up our individual Windows PCs to work with the corporate network. We work in a large company with tons of bureaucracy involved, which includes network access.
Youtube, Twitter, Facebook, and many programming/forums websites are blocked due to faulty filtering settings, so are many other useful sites for coding.
To get this policy fixed will take months. We are trying to use Ruby Gems, SVN, and GIT, and many other command line tools that won't work due to network restrictions.
Question: Is there a way to socksify the entire Windows environment, so we don't have to individually set the proxy for each individual app?
Our environment is Windows XP.
Thanks,
-John
San Jose, California
Most applications on Windows that use sockets, go through the standard WinInet stack. Setting a proper proxy for Internet Explorer actually sets it for the whole WinInet stack as well, so it should work for other apps as well.
Note however, that you need to explicitly open the Advanced dialog for the proxy settings in IE and uncheck the Use same proxy for all protocols checkbox to be able to enables SOCKS support. Otherwise, the proxy settings only affect couple of protocols, so you would still need to configure your tools to use http: instead of tool-specific protocols like svn:.
If one of you can share his or her net access from home and can operate a PC there as a "server", then you can set up a HTTP tunnel using SSH. See details here: http://www.buzzsurf.com/surfatwork/ or google "how to bypass firewalls at work".
Related
We have a product which relies on a thin client installed on users machine. We make an ajax get request to a domain pointing to local host which has a real ssl. This fails in edge, works in every other browser including IE11. Note that same works if there is no ssl involved. It also works on Windows 10 Home edition.
Adding a datatype, content-type or request method does not resolve this. Only way to fix this seems to be running following command.
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition ?
Microsoft Edge, and Windows 10 apps in general, use AppContainer Isolation:
Isolating the application from network resources beyond those
specifically allocated, AppContainer prevents the application from
'escaping' its environment and maliciously exploiting network
resources. Granular access can be granted for Internet access,
Intranet access, and acting as a server.
Your thin-client is running on win10 enterprise edge against an intranet ssl service (localhost), so access is by default restricted by this mechanism. With the command
CheckNetIsolation LoopbackExempt -a -n="Microsoft.MicrosoftEdge_8wekyb3d8bbwe"
you are disabling network isolation on that host for the loopback network adapter (localhost) for MS Edge so your app client (and any other locally sourced app) can run on it without restriction against any localhost service.
This fails in edge, works in every other browser including IE11.
They clearly wanted to improve the default security policy of previous versions. It's never too late, MS :) There is actually an Enhanced Protected Mode (EPM) that could prevent your app from running on IE too. Chrome has its Google Chrome Sandbox that can also be tuned like this. Safari and Firefox also have sand-boxing features although I am not familiar with their particularities.
Note that same works if there is no ssl involved.
Typically, if you are using ssl is because you are dealing with sensitive data and/or a critical service. If you are not it is ok to be more lax. Again, just a matter of security policy.
It also works on Windows 10 Home edition. If this is expected behavior, can someone explain why microsoft would block this on a enterprise version but it works on home edition?
Enterprise versions of any product are known to be more restrictive since their target users are more security concerned (IT people typically don't want to expose their company's intranet payroll db service to external attackers, and things like that). Also, in this case the default behavior can be easily defined/altered by experts on the IT department (check out domain security policies) so it's better to leave the default settings to "paranoid" mode and let the experts tweak according to the company's needs.
Note there are other mechanisms at work when you are running a thin client on the browser that make this kind of protection redundant (same domain policy, XSS protection and so on). Nevertheless one can never be too safe: There are ways to work around those defenses such as Self-XSS that require isolation between the browser and the local network to avoid compromising the system. In the end, less exposed surface means less attack vectors, so isolation is good if you can afford it :)
Research On Firefox Extensions Connections
I have read the FAQ's on Firefox Extensions (https://addons.mozilla.org/en-us/faq) and have looked at their community forums for information but wasn't able to find anything on how extensions actually connect and collect your data.
The closest I found was the Mozilla Wiki page on data collection (https://wiki.mozilla.org/Firefox/Data_Collection) but it only gives you the basic opt in/out data collection levels.
What I'm trying to understand:
If I'm using a manually configured anonymous proxy in Firefox, could the extension potentially send my actual IP address (not my proxy IP address) back to a third party?
Example: Translate Extension
For example, if I were to use the Google Translate for Firefox, would Google be able to see my original IP?
What I was thinking
Since the proxy is the only way for the browser to connect to the internet, the extension would have to use the proxy IP address to connect and thus, would only be able to see the proxy IP address. However, I would love to be sure that there is no back door or way of the extension revealing my original IP.
Any insight is greatly appreciated. We are not doing anything unethical, we just have to maintain separate IP usage for various clients and do not want to risk mixing their information. Thanks again.
Firefox extensions are usually not limited in what they can do, only extensions based on the WebExtensions framework are sandboxed - currently the majority of Firefox extensions is still either classic XUL-based extensions or based on the Add-on SDK, these don't have inherent restrictions. So in theory an extension can do lots of things in order to deanonymize you, for example:
Use nsIDNSService in order to retrieve your local IP address (usually, this address isn't valid outside your local network however).
Change browser settings, in particular disable your configured proxy server.
Use external command line tools in order to read out system information or send a request bypassing the browser.
Read files on your hard drive in order to find your name.
Note that Chrome also offers an API to modify browser's proxy settings extensions, and a similar API is planned for WebExtensions. So even sandboxing doesn't always protect against deanonymization, and you need to trust the extensions you are installing.
However, the extensions hosted on Addons.Mozilla.Org are usually reviewed by Mozilla (the ones that aren't reviewed yet have a yellow install button and a warning). One aspect that the reviewers look into is: does this add-on do what it claims to do or are there unexpected side-effects? Any unexpected functionality has to be strictly opt-in, with full explanation about the implications. This was introduced in 2009 as the No Surprises policy and works remarkably well. Chrome Web Store doesn't have any comparable policy.
I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
I do not have access to a network environment with a proxy server for reaching internet to test with. Therefor, I would like to ask you this newbie question:
-is it enough to set the proxy server settings in the network settings for the machine, or do I also need set the proxy server in meplayer (I noticed VLC e.g. had settings for it)?
what I am worried about is that if I also need to set it in mplayer, I have seen forum posts that there is (or was?) a bug in mplayer that made it impossible to use a proxy server if the audiostream requires authentication (which is the case in my application).
Thanks in advance
/j
Platform-independent media players (like VLC, Mplayer, ffmpeg) usually do not use the "system settings", which are basically Internet Explorer's settings.
You can easily test it at home, by installing a ready-made WAMP or LAMP package and enabling mod_proxy in Apache. Only do this behind a firewall if you do this for the first time, or else you can end up with creating an open proxy-server for the whole world.
I integrated a small http server in my software distribution, intended to allow access to my installed application from the customer's LAN.
Right now, the customer has to manually update the firewall's list of trusted applications. I want to either open a hole in the firewall at install-time, or to ensure that the firewall prompts the user to allow my web server as a trusted application, able to receive inbound traffic.
Any solution should work with the built-in Windows Firewall at minimum.
Suggestions?
I would start out by reading up on the following sections on MSDN. This should give you enough background to know what you need. In short you could be looking to talk to the INetFwMgr COM object.
XP
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366453%28v=vs.85%29.aspx
Vista or later INetFwPolicy2
http://msdn.microsoft.com/en-us/library/windows/desktop/ff956124(v=vs.85).aspx