Category: computers

In Windows / Internet Explorer the options for different security protocols (eg: TLS 1.2, SSL 3.0, etc) are stored in HKEY_CURRENT_USER\Sofware\Microsoft\Windows\CurrentVersion\Internet Settings|SecureProtocols using a bit field. I wasn’t having much luck finding the specific values documented, only this German TechNet blog post detailing the resulting settings. So, I made my own. Here it is in C format:

/* HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings|SecureProtocols for different SSL/TLS settings. */

#define SSL_2.0 8 /* 000000001000 */
#define SSL_3.0 32 /* 000000100000 */
#define TLS_1.0 128 /* 000010000000 */
#define TLS_1.1 512 /* 001000000000 */
#define TLS_1.2 2014 /* 100000000000 */

This also applies to Internet Explorer 9, but I haven’t checked other versions.

Leave a Comment

Since OpenBSD moved the bridge commands into ifconfig(8) I hadn’t been able to find quick info on creating a bridge(4). Presuming you’ve got some em(4) interfaces (for naming purposes) here’s all you need to do:

ifconfig em0 up
ifconfig em1 up
ifconfig em2 up
ifconfig bridge0 create
ifconfig bridge0 add em0
ifconfig bridge0 add em1
ifconfig bridge0 addspan em2
ifconfig bridge0 up

This will result in em0 and em1 bridged together, and a copy of all frames that it sees going out to em2 for monitoring.

After this, if you want it to come up every time you boot the machine, do this:

Create three files, /etc/hostname.em0, /etc/hostname.em1, and /etc/hostname.em2 all containing the single line:

up

Create one file, /etc/hostname.bridge0, containing the following lines:

add em0
add em1
addspan em2
up

Reboot the computer and netstart(8) will use these files to create the bridge for you.

One very important point to note if using this to troubleshoot 802.1x: this sort of bridge cannot be used to troubleshoot 802.1x because it does not pass LLDP frames, nor does it drop/raise the link, which switches commonly use as a trigger for initiating client authentication. For situations like this a tap such as the NetOptics TP-CU3 is much more useful.

Leave a Comment

When troubleshooting issues with proxy auto-config (PAC) files and WinHTTP on Windows 8.1 you may wish to view the cached PAC files which the WinHTTP Web Proxy Auto-Discovery Service have written to disk. These cached PAC files can be found in c:\Windows\ServiceProfiles\LocalService\winhttp and are named with a nine digit number and a cache extension (eg: 1667635681.cache). There is also a cachev3.dat file which appears to contain the download location of the PAC file, the MIME type of the file, and the download date/time.

This can be discovered by using Process Monitor with a filter of Path contains winhttp when the WinHTTP Web Proxy Auto-Discovery Service is started (net start WinHttpAutoProxySvc).

1 Comment

Beware: The use of Fiddler to troubleshoot Internet Explorer issues can complicate the use of the Local intranet zone by effectively disabling the intended behavior of the Include all sites that bypass the proxy server setting. KB174360 describes the Local intranet zone as follows:

By default, the Local Intranet zone contains all network connections that were established by using a Universal Naming Convention (UNC) path, and Web sites that bypass the proxy server or have names that do not include periods (for example, http://local), as long as they are not assigned to either the Restricted Sites or Trusted Sites zone.

When Fiddler is enabled, proxy settings on a client machine are changed to direct all traffic to 127.0.0.1 as seen above. This results in no websites automatically matching the Local intranet zone because none bypass the proxy server.

While troubleshooting a suspected issue with custom user agent entries I had Fiddler running, as is my normal practice.  The reported issues was custom user agent strings not being sent, something that won’t happen on IE9 unless Compatibility View is enabled. I’d first thought there was a problem with the Display intranet sites in Compatibility View option not working due to the Local intranet zone assignment not working, but my issue actually turned out to be Fiddler getting in the way by causing no sites to match the Local intranet zone. When Fiddler was disabled and I switched to using an external tap for monitoring, behavior returned to normal.

Fiddler is great for MITMing secure sessions thus making troubleshooting secure websites trivial, so not being able to use it in these circumstances will cause other problems. But there are other ways around that…

Leave a Comment

I recently had an issue where an application which supports proxies but doesn’t prompt for credentials needed to use a proxy server to communicate with the internet. The solution? Use Fiddler and its built in scripting language as a secondary proxy chained to the primary, forcibly sending a valid authentication header to the proxies.

How does one this? Here’s how, which is a bit more detailed writeup than what’s found here at Stack Overflow. Note that this presumes basic familiarity with Fiddler:

1. Use Fiddler to watch a session that uses Basic authentication to the proxy. Look at one of the requests headers after successful authentication and find the line which contains Proxy-Authorization: Basic. Copy this value to the clipboard. (Example line: Proxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQxMg==)
2. In Fiddler, click Rules → Customize Rules to open CustomRules.js in an editor.
3. Locate the function OnBeforeRequst. The line beginning this will read something like static function OnBeforeRequest(oSession: Session) and is line 159 in the rulset that ships with Fiddler v4.4.9.2 (latest as of November 6, 2014).
4. Below this, add a line as follows, with the secondary part being the string that was copied in step 1. In this example the bolded portion is what we’ve added:
   [...]
static function OnBeforeRequest(oSession: Session) {
// Inject a Basic authentication header
oSession.oRequest["Proxy-Authorization"] = "Basic Yno5eWw1Oldyb25nLmdvLldheSsyNDA=";
// Sample noRule: Color ASPX requests in RED
// if (oSession.uriContains(".aspx")) { oSession["ui-color"] = "red"; }
[...]
5. Save and close CustomRules.js. Fiddler will now begin using this modified ruleset. You can observe that this header is now included with every request.
6. Ensure that your application using Fiddler as its proxy. If the application is local to the computer on which Fiddler is running and uses WinINET then this is likely automatic. If not, it will need to be manually pointed to the local proxy. Fiddler can also accept connections from computers elsewhere on a network (Tools → Fiddler Options… → Connections), but configuration of this is beyond the scope of this article. See the Fiddler documentation for more information.

Leave a Comment

While getting ready for a trip to DEF CON 22 I wanted to have a VPN set up from my phone and tablet to connect back home. After a little while I had both IPsec and OpenVPN connecting back to the house’s pfSense box and passing IPv4 traffic through the tunnel without issue. But, there was a problem when connecting over the T-Mobile mobile network: the VPN would handle IPv4, but IPv6 was left alone to leak through the carrier.

This can be seen in the screenshot above (link) where IPv4 is passing through my home’s Wide Open West connection, but IPv6 goes through T-Mobile. Such leakage has also been written about here by lxgr, in much greater detail.

By pushing an IPv6 route to the client from OpenVPN I was able to black hole IPv6 on the client and close this leakage. This is done by adding the following to the Advanced configuration section of the OpenVPN server config in pfSense:

push "route-ipv6 ::/128 ::1"

While IPv6 still is configured, all traffic goes to loopback and won’t pass over the mobile network. Connections will then fall back to IPv4, which’ll go via the VPN.

EDIT: I was also reminded that I can turn off IPv6 in the APN settings. This works, but I really do like keeping this at the provider defaults… I like having IPv6 when it is available, I just want data to go via only the connection I prefer.

1 Comment

Garmin has recently moved to using Garmin Express for syncing and updating a number of its devices. I recently had to troubleshoot an issue where it wouldn’t work from within a corporate network that uses proxy servers. This has been widely reported on the Garmin Forums (eg: 1, 2), with the general consensus being that Express doesn’t support proxies. It turns out that this is incorrect; Express does support proxies, but because part of it runs as the LocalSystem Account (NT AUTHORITY\SYSTEM) it typically doesn’t have access to the proxy settings.

First, the cause:

Garmin Express has three main components: a service called Garmin Core Update Service which is Garmin.Cartography.MapUpdate.CoreService.exe running as SYSTEM. The second is a tray applet, ExpressTray.exe, which automatically launches on boot running as the currently logged in user. This in turn launches Express.exe, which is the program’s main user interface. The Garmin Core Update Service handles the network communication with Garmin’s servers — something which would normally use proxy servers — but since the default in Windows is not to have proxy settings for the SYSTEM account, this service doesn’t know how to communicate with the outside world.

Now, a couple workarounds:

The first workaround is to change the Garmin Core Update Service to run as the user who needs to run Garmin Express. This works, but may experience wrinkles long-term. Setting the service to run as a specific user requires that user’s password, when password change time occurs (something fairly common on corporate networks) the service will likely fail to start. Additionally, it changes Garmin’s application architecture and may have other untold consequences such as becoming undone when Express updates itself, keeping Express from properly functioning on multi-user machines (read: tablets), etc.

The second workaround is to use the ProxySettingsPerUser policy setting to make the computer have one set of proxy settings for all accounts, user and SYSTEM alike. This is normally defined by Group Policy, but can be manually set by setting the registry value ProxySettingPerUser in HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings to DWORD 0x0. After changing this setting, resetting the proxy settings in Internet Options may be necessary.

By having one set of proxy settings system-wide, processes running as the SYSTEM account will then be aware of the proxy settings. However, if the corporate network uses some manner of authentication for its proxy servers then communication may still fail as Express may not have access to appropriate credentials.

I do not feel that either of these is a proper solution, neither good long-term or enterprise-wide, but both are usable for an individual attempting to resolve problems with a one-off installation. Ideally I’d like to see Garmin change Express so that network communication is handled as the user running the UI. Additionally, some customizable proxy options (eg: Use System Settings, Manually Specify Proxy, etc) as many other applications offer would make Express‘ internet communication considerably more flexible.

(This post applies to Garmin Express 3.2.4.0 only. Newer versions may change this behavior.)

6 Comments