Last year, I wrote about how the new Microsoft Edge’s adoption of the Chromium stack changed proxy determination away from the Windows Service (WinHTTP Proxy Service) to similar but not identical code in Chromium. This change mostly goes unnoticed, but it can have performance and functionality implications.

In today’s post, I want to explore another side-effect of changing away from the Windows stack– the impact on Proxy Authentication.

Background

When the client is configured to route its traffic through an authenticating proxy server, the proxy responds to any request that does not contain a Proxy-Authorization request header with a HTTP/407 response that demands credentials, specifying the desired authentication scheme using a Proxy-Authenticate header:

The client is expected to resend the request with the requested credentials added in the Proxy-Authorization header.

Browsers tend to support four methods for authentication: the same four used for plain HTTP authentication: Basic, Digest, NTLM, and Negotiate (NTLM+Kerberos). The NTLM and Negotiate schemes are generally much preferred, as they can be configured to authenticate silently without showing a prompt to the user. However, depending on configuration (e.g. not in the right zone, or when the user’s Windows Login Credentials are not the ones the proxy requires), the user might see a proxy-authentication prompt in the browser.

Browser Credential UX

The prompt differs depending on the client; Google Chrome, and until recently Microsoft Edge, show an auth “bubble” anchored to the bottom of the browser address bar UI. In contrast, the latest versions of Edge and Internet Explorer show the battleship gray Windows Hello modal dialog box:

While these experiences are all conceptually similar, they differ in very important ways. First, note that Internet Explorer’s option shows a “Remember my credentials” checkbox while Chrome/Edge do not. Proxy credentials saved by Internet Explorer will be reused without prompting, across browsing sessions and across other applications that use the WinHTTP Proxy Service.

In contrast, in Chrome and older Edge, the proxy credentials prompt is integrated with the browser’s Password Manager. If the user accepts the followup prompt to save the proxy credentials, those credentials will autofill the dialog in future browser sessions. Notably, however, the proxy authentication is not automatic– the user must manually click the Sign in button once per browser session.

Storing a credential in your Edge profile’s password manager only applies to that one browser profile– other profiles and apps do not have access to the credential.

In Edge 88+, this password manager integration was lost in the switch to use the Windows Hello prompt for NTLM/Negotiate. A new policy (WindowsHelloForHTTPAuthEnabled) added to Edge 90 changes Edge’s proxy credentials dialog back to the older dialog.

Other App Credential UX

Support for manually-authenticating proxies outside of browsers has always been terrible, and many Win8 applications didn’t even bother to handle it. Sadly, that shortcoming remains in Windows 10, where you can’t even use the Windows Store when a proxy needs credentials that are not supplied automatically. An generic error page is shown:

However, as mentioned earlier, around IE11 a change was made to push proxy authentication creds entered in Internet Explorer’s proxy authentication prompt into the Windows Credential Manager (CredMan):

As seen in the Control Panel view (Persistence: Enterprise):

Even if you untick the “Remember my credentials” box on the prompt, the entered creds are still remembered for the Windows session (Persistence: Login Session):

As a consequence, users can “unbreak” various Windows scenarios by just using the browser to populate the Credential Manager with the proxy credentials.

We’ve lost that workaround in the new world, because Chromium’s password manager is not integrated with CredMan (for a number of sane reasons).

Surface Hub

The Microsoft Surface Hub is a “whiteboard computing” device designed for corporate conference rooms and the like. By default, the Windows logon session on the device uses an account named ComputerName\SurfaceHub, and that account is very unlikely to be supported by an authenticating proxy. To support it, Windows’ Settings applet on Surface Hub has a custom option:

However, this option doesn’t presently do anything for Chromium’s network stack. When Edge gets a Proxy-Authorization: Negotiate challenge from the proxy, it will respond with the credentials for the SurfaceHub account rather than the machine credentials, and the login will likely fail. At present, we don’t have a great workaround for this: it’s probably possible to write a browser extension (catching the onAuthRequired event and responding with non-default credentials) but this won’t pick up the Windows settings.

Other Brokenness

• We recently fixed a bug in Edge Canary where the browser would crash on startup if the user was behind a manually-authenticated proxy server. A network request triggered very early in browser startup wasn’t prepared for an auth challenge.
• If you have the Microsoft Office Chrome extension installed, it can (for reasons unknown) automatically cancel the manual proxy authentication dialog before the user has a chance to submit credentials.

In conclusion: Two decades in, support for proxy authentication remains a mess. The feature is required by the networks of some corporate titans (and thus support continues to limp along), but many corner cases remain broken. Consider carefully whether proxy authentication needs to be a part of your network strategy.

-Eric