Event 1065 - Web Proxy Error Handling Changes
- Logged Message
- What Is It?
- When Is This Event Logged?
- Example
- Remediation
- Related topics
Logged Message
Windows Internet Explorer 8 blocks content returned by a proxy if a tunnel is not established in response to a CONNECT request, or displays the content in a context based on the hostname of the proxy rather than in the context of the origin server.
What Is It?
The motivation for this feature is to help address a security issue that exists when a Secure Hypertext Transfer Protocol (HTTPS) connection is not successfully established between a browser and server. Explaining this is more easily done with an example.
Let's assume that a browser requests a page from a secure site (for instance, https://www.woodgrovebank.co.uk). Let's also assume that there is a proxy between the browser and that site. The proxy's job is to mediate the establishment of a secure tunnel between the browser and the target server (once established, the proxy doesn't have access to the encrypted traffic flowing between the two). If the proxy fails, and the secure connection is not successfully made all the way to the target server, then the proxy returns an error to the client. It is common in such cases for the proxy to return a webpage to the browser with information about the error.
Windows Internet Explorer 7 would simply render the page returned from the proxy and execute that page in the context of the target server. Internet Explorer 8 has a feature that ensures that the secure connection is made all the way to the target server. If it isn't, then no page is displayed.
To facilitate this new feature, Internet Explorer 8 includes a modification to Microsoft Win32 Internet (WinInet): if the connection isn't established all the way to the target server, then the WinInet connection returns nothing back to the caller (the caller in this case, is the browser). When the browser detects that the connection failed at the WinInet level, it downgrades the protocol to http and changes the host name in the Address bar to be the name of the proxy. So the user starts by browsing to https://www.woodgrovebank.co.uk. But after the connection fails the user sees http://AddressOfProxyServer in the Address bar. Additionally, no content is rendered to the user—even an error page returned from the proxy.
In this way, any potentially malicious page returned from the proxy is not rendered for the user. And since a page from the proxy is never processed, it would not gain access to cookies belonging to the target domain that the user was trying to connect to.
When Is This Event Logged?
When Windows Internet Explorer fails to make a secure connection to a target server, this event is logged. Internet Explorer detects the event by the failure to create an Secure Sockets Layer (SSL) tunnel to the origin server through the proxy.
Example
To recreate this scenario you can use Fiddler. Fiddler is a Web Debugging Proxy that logs all HTTP(S) traffic between your computer and the Internet. You can also manipulate the traffic sent between the browser and Web server.
Once you have installed Fiddler, perform the following tasks:
Start Fiddler. It is accessible as a menu item called Fiddler2 found in the Windows Internet Explorer Tools menu.
In the Fiddler window, on the Rules menu, click Customize Rules. This opens Microsoft Notepad with the CustomRules.js file. You can edit this file.
Find this function in the text file:
static OnBeforeRequest(oSession: Session)Place these lines before any other code in the method:
if (oSession.HTTPMethodIs("CONNECT")){ oSession["ui-color"]="orange"; oSession["ui-bold"]="true"; oSession.oRequest.FailSession(404, "Blocked", "Fiddler blocked CONNECT request."); }Save and close the file.
Attempt to browse to a secure website using HTTPS protocol. The attempt fails and the event is logged.
Basically we've inserted code into Fiddler instructing it to always return failure from any connection attempt. This simulates a proxy that fails to make a connection.
Be sure to remove this code before you use Fiddler again or any connection attempt will fail.
Remediation
There is no workaround to this feature. You should be aware of it and design your site accordingly.
There are two feature keys that may be useful to temporarily configure. Even with the feature key settings, the content renders in a synthetic context based on the name of the proxy rather the name of the origin server.
Enabling the following feature key causes WinInet not to discard any content returned from the proxy (by default, WinInet returns nothing when it fails to connect all the way to the origin server):
FEATURE_RETURN_FAILED_CONNECT_CONTENT_KB942615
Enabling the following feature key causes the browser to display the content—but in a synthetic context derived from the proxy name (by default, the browser displays nothing when it fails to connect all the way to the origin server).
FEATURE_SHOW_FAILED_CONNECT_CONTENT_KB942615