Web proxy support, proxy authentication, and troubleshooting

Understanding Web Proxies

Proxy servers have many forms and uses.  At a high level, a proxy server simply acts as an intermediary by: receiving a request from a client, forwarding it to a server, receiving the response from a server, and forwarding the response back to the requesting client.  Web requests, which include things like navigating to a web address (such as http://www.softwarekey.com) in your web browser, can similarly use a web proxy.  Because they focus on web (HTTP) requests specifically, web proxies can be leveraged to help secure a network, monitor Internet usage/activity, filter what Internet content may be accessed (similar to parental controls), provide anonymity, and more...

The visual shown above outlines how a web proxy would typically work with a licensed application accessing SOLO Server (to activate, verify the status of the license, deactivate, etc...).  The steps below describe the corresponding numbers in the diagram above.

1. The client (the workstation running a licensed application in the above example) initiates a web request.
2. The web proxy server receives the request. If the policy set on the web proxy server permits, the request is forwarded to the destination on the Internet (which is SOLO Server in this example).
3. SOLO Server receives the request, processes it, and responds.
4. The web proxy server receives the response.  If the policy set on the web proxy server permits, the response is forwarded to the workstation that initiated the request in step 1.

In steps 2 and 4 above, we outline that something may only happen "if policy set on the web proxy server permits."  To help explain this effectively, it is best to first understand the many many kinds of environments that often leverage web proxies:

• Hotels, which may want to track and/or bill your Internet usage along with your room and room service fees.
• Hospitals, government, military, and industrial (factory) sites/locations often employ web proxies to strictly limit Internet access on personnel computers and equipment to protect against incoming attacks, and to prevent information from inadvertently leaking out to the Internet.
• Public WiFi and networks (at locations such as public libraries, airports, restaurants, shopping centers, etc...) often employ web proxies to filter content.

Some commonly used web proxy server software includes: Squid, Microsoft Forefront Threat Management Gateway (formerly Microsoft ISA Server, Microsoft Proxy Server). There are also many web proxy services on the Internet (also known as "open proxies") that may be used.

Note: Reverse proxies are not included in this article, as they are not applicable in this context. These are sometimes used where a large/highly-trafficked web site is hosted for purposes such as load balancing requests between multiple web servers, off-loading encryption, etc...

Understanding Policy and Authentication

Next, here are some examples of the kinds of policies that could be employed at places that use web proxies:

• Requests made to list of select web sites are explicitly prohibited, but requests to any other web sites are permitted.  This is also known as a black-list.
• Requests made to list of select web sites are explicitly permitted, but requests to any other web sites are prohibited.  This is also known as a white-list.
• Internal network servers that house very sensitive or secret information all reside on certain IP addresses (or subnets) on the network.  As such, all traffic going from those computers (or that network segment) to any Internet location is prohibited.  (Imagine this in a hospital scenario, where medical imaging equipment needs to be strictly secured to maximize patient privacy.)
• Specific users or groups of users have access to very sensitive or secret information.  As such, some or all traffic going to any Internet location is prohibited for those users. If some Internet access is permitted, responses that contain certain types of content (such as executable files, zip files, etc...), or responses that exceed a certain length, may be prohibited. (Imagine this in a government or military site, where sensitive information needs to be strictly secured.)
• In order to track a user's Internet usage, a user must first be authenticated so that the user's identity is known.  As such, only authenticated users may access some or all Internet content.  Anonymous usage is prohibited.  In such a scenario, the user can be prompted to enter authentication credentials by the web browser; or the web proxy server redirects the browser to a page that may require the user to agree to terms or a contract and/or requires user to authenticate.  (Imagine this at a hotel, where your room number must be verified, and you must agree to legal terms and conditions, before you are allowed to connect to the Internet through the hotel network.)

There are many ways a web proxy server may support or require authentication:

• The web proxy server may redirect the user's browser to a page in the browser. This page can help network administrators enforce legal agreements between with the user by forcing the user to agree and authenticate before allowing traffic from that user to pass through the proxy.
• The web proxy server may respond to a request with an HTTP 407 status code, which indicates to the software (typically a web browser) that proxy authentication is required.  After receiving an HTTP 407 response, the software/browser should prompt the user for a username and password, and authenticate the user with the proxy using an appropriate method (Basic, NTLM, Digest, Negotiate, etc...).  User accounts may be configured either on the web proxy server itself, or the web proxy can be configured to authenticate network/domain users.
• Referencing the point immediately above, when a web proxy server requires Active Directory/LDAP domain users to authenticate, it is possible to completely avoid the need to prompt a user for credentials by using the negotiate method.  In this scenario, an API such as GSS-API or SSPI (on Windows) is leveraged to authenticate using the user account that is running the application (a browser, a licensed application, etc..) on the workstation.

Understanding Client Proxy Configuration

A workstation or the applications running on a workstation must be aware of a web proxy server in order to use it as possibly required by a network and its policies.  On Windows 8.1 and earlier, the most common way to configure this was to open Internet Explorer, click the Tools/Internet Options menu, click the Connections tab, click the LAN Settings button, and enter the proxy server information.  On Windows 10, this is typically done by clicking the Settings button in the Start Menu, clicking the Network & Internet button, clicking Proxy on the left, and entering the configuration. One significant benefit to configuring a client system this way is that it allows most applications to automatically detect and use these settings.

Another significant benefit to configuring Windows proxy settings this way is that it dramatically simplifies supporting Proxy Auto-Configuration (PAC) scripts.  PAC scripts can be stored on servers managed by network administrators, which can often assist network administrators with managing proxy configuration remotely (without configuring each Windows system individually).  Additionally, PAC scripts may have their own rules about when a proxy should be used (e.g. they can be configured to completely bypass a web proxy server for certain sites).

Web Proxy Support with Protection PLUS

Different versions of Protection PLUS have different levels of support for web proxies, which is summarized below.

Applications Licensed with Instant Protection PLUS 3

• Can auto-detect and use Windows/Internet Explorer client proxy configuration when set as described above.
• Cannot use proxy authentication due to the many challenges.
• Cannot provide users running the licensed application with a dialog where proxy information may be entered manually.

Applications Licensed with Protection PLUS 4 SDK

• Can auto-detect and use Windows/Internet Explorer client proxy configuration when set as described above.
• Cannot use proxy authentication due to the many challenges.
• Can accept proxy information manually entered by users.  The application can leverage its own dialog for gathering this information, or in some cases, it may leverage APIs to use a pre-made dialog to gather this information.

Applications Licensed with Protection PLUS 5 SDK

• Can auto-detect and use Windows/Internet Explorer client proxy configuration when set as described above.
• Can support most methods of proxy authentication.
• Can support integrated authentication so as to avoid prompting users for credentials.
• Can leverage sample code that has built-in dialogs and support for using web proxies and proxy authentication.
• Can leverage thorough documentation on how to implement proxy support with PLUSManaged (for .NET applications) and PLUSNative.

Common Troubleshooting Steps

As you can see from the plethora of high-level details, web proxies and clients that use them can be configured in a nearly infinite number of ways. As a result, troubleshooting proxy related issues with licensed applications can sometimes be a challenge.  Here are some starting points to help narrow-down the cause of such issues:

• Start by having the user navigate to SOLO Server using Internet Explorer (Windows 8.1 or earlier) or Edge (Windows 10 or later), which can provide some insight into whether or not the browser prompts the user to authenticate first. You can start by making sure the user has all browser tabs and windows closed, opening a fresh browser window, and then navigating to the appropriate address:
  • SOLO Server Shared URL: https://secure.softwarekey.com
  • SOLO Server Dedicated URL or self-hosted SOLO Server: https://[your_SOLO_Server_domain_name]
• If the user can reach SOLO Server, they should simply see the text "OK" in the web browser. If the user cannot reach SOLO Server using a web browser, this could be a general connectivity issue, or it could be a policy issue.
• If the user can reach other popular web sites (such as google.com, microsoft.com), but cannot reach SOLO Server, then it is possible that policy is blocking access to SOLO Server. Have the user contact their IT department. SOLO Server uses standard ports: 443 for HTTPS and 80 for HTTP.
• If the IT department responds indicating they feel there should be no problem reaching SOLO Server, or the problem persists, and you have active maintenance, contact us for further assistance.