1218767 - Wrong system proxy detection on Windows when using a BIG-IP F5 VPN connection with non-ASCII chars

Status: NEW

(Core :: Networking: Proxy, defect, P3)

Description

[Mossroy]

Issue encountered with a BIG-IP F5 VPN client on Windows (Windows account with French regional settings), configured to use a local proxy PAC file (file://c:/.../proxy.pac). Firefox is configured to use the system proxy.

With this config, the F5 VPN Client creates a VPN connection named "Aller à server.tld au lieu d'appeler directement" (with a non-ASCII char in 'à').
It also configures this VPN connection to use the specified proxy.

The proxy configuration works correctly on Internet Explorer 11 and Chrome, but fails on Firefox (38.2.1 ESR and 40.0.2) : it uses a direct connection instead of using the proxy.

When configuring the Windows user with English (US) regional settings, the connection name generated by the F5 client is "Go to server.tld ..." (with only ASCII chars), and the proxy is correctly used by Firefox. So I suspect an encoding issue.


Steps to reproduce :
- install a BIG-IP F5 VPN server, and configure it so that clients will use a local proxy PAC file
- install the F5 VPN client (tested on version 7110.2014.807.1842) on a Windows computer (tested on 8.1), and put the proxy PAC file on it
- configure the regional settings of the Windows account to French
- connect to the VPN
- launch Firefox (and check the network settings are set to "use system proxy")

Actual behavior : Firefox does not use the proxy PAC, and tries direct connections for all URLs

Expected behavior : Firefox should use the proxy PAC, as Internet Explorer and Chrome do.


With the same computer, I don't have any issue with a Ciso Annyconnect VPN client. But it seems to use a different technology : it does not create a "network connection" but a "network device".

Comment 1

[Mossroy]

I had a look at what Firefox does with Process Monitor :
it reads the proxy settings in the Windows Registry, in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
The proxy setting is in a registry entry with the name of the Connection.

The problem is that there are two different entries in the registry for the VPN connection. If you use regedit, you have :
- one with a readable accent 'Aller à', and the proxy PAC setting is properly in it
- and another one with an unreadable accent 'Aller �', and no proxy PAC setting in it
See attached screenshot and registry export (I removed the name of the VPN server)

Process Monitor shows that Firefox reads both entries : first with the right accent, and then with the wrong accent.
And it seems to use the last value it reads, and so does not use any proxy.
If I copy the value from the right accent entry, and paste it in the wrong accent entry, Firefox correctly reads the system proxy setting.
So we have a workaround by manually adding the registry entry.

Comment 2

[Mossroy]

Attachment: Regedit snapshot

Comment 3

[Mossroy]

Attachment: Registry export

Comment 4

[Mossroy]

Attachment: Registry export (fixed)

Comment 5

[Mossroy]

I think the original problem is these duplicate registry entries, and they are (maybe indirectly) generated by Firefox itself. See the following steps to reproduce :
- start with a fresh Windows profile
- connect with the VPN client : it creates only one registry entry with a correct accent
- launch IE and/or Chrome : nothing is modified in the registry
- launch Firefox : the second registry entry appears (with the wrong accent)
- delete the registry with the wrong accent, and open any URL in Firefox : the registry entry re-appears

I had a look at the source code and saw that Firefox does not directly read the registry, but uses wininet.dll to do that. More precisely, it calls the InternetQueryOptionW function in toolkit/system/windowsproxy/nsWindowsSystemProxySettings.cpp.

I had a look at the source code of Chromium and they also use wininet.dll, but with a slightly different function : InternetQueryOption (without the trailing W, see https://chromium.googlesource.com/external/libjingle/chrome-sandbox/+/master/talk/base/proxydetect.cc ). Based on https://msdn.microsoft.com/en-us/library/windows/desktop/aa385101%28v=vs.85%29.aspx , the trailing W means Unicode version.

Maybe it could be related to the version (Unicode/ANSI) of the InternetQueryOption function?

Comment 6

[Mossroy]

Regarding the creation of the duplicate registry entry, I don't think Firefox does it directly because I found another way to make it appear :
- start with a fresh Windows profile
- connect with the VPN client : one registry entry appears with correct accent
- open Internet explorer, go in its Internet Options. In the "Connections" tab, choose the connection of the VPN, and click on Parameters (not the global network parameters, the parameters of the connection itself) : the duplicate registry entry appears at this moment (with the same wrong accent and the empty content). And the user interface displays no proxy (which corresponds to the empty content of the newly created entry)
- Still in the sale user interface, fill in a dummy proxy PAC URL for this connection : it is saved in the registry entry with the wrong accent
- Close the Internet Options, and open a URL in Internet Explorer : it does not use the dummy proxy PAC URL we just entered, but instead the one from the registry entry with the right accent

So it looks like if the "Internet Options" User Interface of IE has exactly the same behavior as Firefox. But Internet Explorer itself does not.
Could it be a bug in Windows itself?
NB : c:\windows\System32\wininet.dll and c:\windows\SysWOW64\wininet.dll are in version 11.0.9600.18036

Comment 7

[Mossroy]

Attachment: patch_proxy_encoding_InternetQueryOption.patch

I applied the attached patch to test what I said in Comment 5.

It's unfortunately not solving the issue, but it's changing a bit the behavior of the registry keys : instead of creating a registry entry with the connection name and wrong accents, it creates a registry entry with "_" name (underscore), with the same empty value as before.
But Firefox still does not use the proxy PAC.

Comment 8

[Mossroy]

Another workaround we have is to use autoconfig to set the proxy PAC manually, instead of relying on the system proxy settings

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 11

[BMO Automation]

Moving bug to Core/Networking: Proxy.