I like Firefox. It has the visual settings I want, the security features I want, the plugins I want, and the business model I like. Chrome and Safari in their own right are just fine, but I prefer Firefox.
My employer, however, does not like Firefox, and that is for obvious reasons. Firefox is a standalone application that doesn’t require root privileges to install or configure. It also ignores group policy, and maintains its own certificate store. From an IT admin perspective, it’d be a nightmare to try to support. So, officially, they don’t. But, they don’t explicitly forbid its use, either. In fact, many internal documents offer information that is Firefox-specific. But, IT also blocks the domains which provide Firefox installation packages, and the company’s Reasonable Use of Company Resources policy does state that circumvention of technological protections is prohibited, so am I violating this policy by, say, acquiring an installation package that I had downloaded onto a domain I control? I’m not really bypassing these protections, and besides which–I have a business need to test how web code renders in different browsers. It’s a bit of a grey area.
What isn’t a grey area, however, is the means by which I connect to the Internet. Naturally, I use the default proxy URL and configuration provided by the company, so all good there.
Then recently, I couldn’t connect at all. I received a certificate error for every HTTPS page I attempted to access. Unbeknownst to me, IT had installed a middlebox.
Middleboxes operate by intercepting a connection, breaking it open, then re-encrypting it back to the end user. This re-encryption, however, requires a re-signing of the contents with a valid certificate. This certificate is generally a company-generated CA, installed via group policy into every machine’s certificate store. But since Firefox uses it’s own certificate store, when the re-signed connection arrived, Firefox only saw that the connection was signed with an unknown and invalid certificate, and promptly terminated the connection as a security measure. This is, amusingly, the way it’s supposed to operate. Breaking TLS in this manner violates its purpose, but it works because of its current limitations (at least for now–TLS 1.3 has protections against this but is being pushed back because of its ability to prevent this type of corporate TLS-breaking).
Naturally, I don’t have a problem with the company monitoring the use of its own resources, so you’ll find no soap box argument here. My main concern, then, was how to get Firefox working again.
Fortunately there’s a buried setting, within about:config.
Simply changing the Value from “False” to “True” will allow Firefox to access and accept the hosting machine’s certificate store, thus allowing corporate TLS certificates to break and re-sign HTTPS.
So at least for now, I can still use Firefox. I just had to configure it myself, which is no doubt the kind of support IT wants to avoid having to provide.
Curiously, when I’m connected to the company VPN, my traffic doesn’t appear to be funneled through the middlebox. I wonder if there’s too much overhead to do that, or because since the VPN uses TLS it’d be a technical challenge to separate VPN TLS from HTTPS TLS? Maybe they’re only concerned about monitoring non-exempts to that extent. Dunno.
Regardless, Firefox can still play nice in a corporate environment. It’s just that it has to be manually switched away from its default, and untrusting, policies.
–Simon