It's worth noting the reason why Mozilla made this change: not because they consider these systems acceptable, but because they can't even get telemetry data on the scope of the problem because the telemetry mechanism naturally also uses HTTPS, and because this issue prevents such users from getting updates to Firefox itself.
And their telemetry needs are superior to the actual privacy at stake here? And they are now providing an updated version of Firefox that merely flip-flops on the protection, instead of providing a message "hey, you're being intercepted"?
I'm not naive, but I still think it's only to prudent to point out how ridiculous this sounds. In any case, it seems like Mozilla needs a bit of Skype-magic for their update process. Relying on the very thing you are patching with every minor version seems silly regardless.
"Breaking" the browser for a large number of users will only lead to one thing: Users switching to a browser that still supports SHA-1 certs issued after Jan 1st, 2016. No privacy improvement there either. Additionally, there are many valid use-cases for replacing certificates, e.g. corporate proxies. They should just stop using outdated hashing algorithms for those certs. It's not Mozilla's place to decide whether that use-case is valid or not.
SHA-1 was never fully disabled; it's just that certificates using SHA-1 issued after that date weren't accepted anymore. Telemetry is important to understand the ramifications of this issue. This change is likely to be reverted once Mozilla understands the implications. Take a look at the discussion on Mozilla's mailing list for more insight into their thinking[1].
I think the idea is to first revert to a state where people behind this MITM boxes can receive updates to firefox, and then decide how to handle things from there.
They just need to merge the Tor Browser into Firefox and add a meek-like http-based pluggable transport, then they can get around these weird MITM boxes.
They probably should have foreseen this and used OpenPGP-based updates over plain HTTP though.
Would they consider these systems to be necessarily unacceptable? Intercepting TLS at a corporate proxy is perfectly valid and necessary for a decent security program.
I agree that it's perfectly valid, but disagree that it's necessary. Deploying proxies has costs - it obscures the endpoints of communication from sensor software and makes anomaly detection more difficult.
Richard Bejtlich's "Practice of Network Security Monitoring" has a chapter dedicated to the costs and benefits of proxy deployments; I recommend the book for a look at one coherent method of network security monitoring.
> Deploying proxies has costs - it obscures the endpoints of communication from sensor software and makes anomaly detection more difficult.
It also establishes a single machine that sees all the plaintext of everything that should have been TLS encrypted from every machine on your network. It's like attacker catnip.
If an attacker is able to gain root access to your proxy, or inline with a TAP where your proxy is sending intercepted traffic to, you probably have much bigger problems.
> If an attacker is able to gain root access to your proxy, or inline with a TAP where your proxy is sending intercepted traffic to, you probably have much bigger problems.
Bigger problems than an attacker being able to decrypt and modify all of the TLS sessions in your company? If you have bigger problems than that then they've presumably spilled out of the realm of IT problems entirely and you're dealing with some kind of government lawyers or maybe a large uncontrollable fire.
The attacker can pull credentials that any user uses on any webpage or other TLS-based connection. It's not the domain admin password or the database password, it's both, and the other ones too. Like the one the accountants type into the company's banking website.
TLS MITM is essentially the holy grail because there are so many overlapping ways to break into everything. If there is some password nobody has ever typed into a web admin portal then get their email credentials and do a password reset. Or use one of the apps that uses TLS to authenticate updates to push out a key logger. Or wait for a new attack to be published and block delivery of the patch. Or take advantage of being able to display anything you want on the company's internal website and start social engineering. On and on.
TLS under non-self-compromise circumstances provides reasonable security and is allowed through corporate firewalls, which means that everything uses it one way or another. Which means if you can compromise TLS then you can essentially compromise everything.
I understand your point, and acknowledge that TLS MitM is a major security threat, but my point is that if you're able to get deep enough into someone's network that you're able to intercept traffic between where it is passed to the interceptor and then re-encrypted, most information they could get from a MitM could also be obtained by pillaging the network through direct endpoint and server access. If they install malware on your workstation, they'll grab your admin panel and email credentials with ease; they don't need a MitM to do it.
You're right that a TLS MitM is one big way to make it easier for them to pivot and install malware, but there are many other ways they can do it, too, if they're on your internal network.
I think the pros of TLS interception outweigh the cons. You are exposing yourself to a little more risk once someone has already breached you, but you could say the same about other security products and procedures. For example, if you gained admin access to an endpoint agent like Carbon Black or Google Rapid Response, you can now deploy malware to every machine in the company. The pros of these endpoint monitoring tools outweigh the cons, though. You just have to architecture and protect them properly.
It only obscures it if you have a bad setup. Having records of structured proxy logs is fantastic. Without being able to disallow uncategorized and malicious sites, the infection rate at my company would probably triple. Without being able to inspect proxy logs on the fly through our SIEM, we'd have to request packet captures for every single potential incident, and hope the captures didn't roll over.
We also do a lot of anomaly detection on the proxy logs themselves. It does obscure NetFlow-based anomaly detection, and does create complications in the architecture, sure, but from my experience with them, the pros outweigh the cons if you set them up properly.
I am probably in the minority here, but I don't agree. I understand why the security program does it and why they think they need to. I just think that, regardless of who owns this computer and the network it's connected to, if I'm using it, I should be able to use TLS without any interception.
I'm shocked to think this is a minority opinion. Please give us certificate pinning because this type of interception is completely hostile to the end user.
Pinning, as implemented by major browsers[1][2], doesn't prevent this. Private trust anchors are exempt from key pinning. This is deemed acceptable because in order for the proxy root to be trusted, it would have to be installed on your system, so whoever owns the proxy already has control over your client.
If you think that using MitM proxies should be illegal for employers or other organizations providing clients, that's probably more of a legal discussion. I don't think there's necessarily a right to privacy when it comes to internet use at your workplace, as long as all parties are aware of this.
I don't necessarily think they should be illegal. I do think that browsers should go out of their way to make life difficult for organizations that want to do this. If Firefox and Chrome both agreed to hold the line on this issue and say "MITM is always wrong", forcing prospective MITMers to maintain local hacks, then at least some organizations would listen, even if others continue to do the wrong thing.
Could Firefox display an icon or provide a visible warning to users when traffic is being intercepted?
The root cert could've been installed by malware, no?
This seems like a good first step: Firefox should display a persistent, unremovable notification bar that makes it clear that the connection appears MITMed. If people complain about that notification, the answer is "remove whatever malware you have, or complain to your network administrator".
It's difficult for Firefox to determine this. In this MITM case, Eve is your employer and she's modified the cert store that Firefox implicitly trusts.
Now it would be interesting if firefox could distinguish between the cert store that it came with and new certs installed.
Another idea would be for users to write an extension that could say "such-and-such cert is my employers and you should create a UI flag when it's being used." I know I looked into that for Chrome and it's impossible since it's not available to the extension system.
Firefox knows this any time a site has a pinned certificate and that certificate doesn't match, but chains to a certificate in the system trust store that didn't ship with Firefox.
> Ok, I expected it should be feasible. I wasn't optimistic when I read a Chrome bug that was nofix'd to make certificate info available to extensions.
This doesn't seem like a thing you could easily do from an extension, especially from a Chrome extension. But the browser itself easily has access to this information.
> You sound kinda authoritative, are you suggesting that you could propose this change to firefox and it might get accepted?
No, not at all; I'm not a Firefox developer. I just have strong opinions on how broken MITM is, and thoughts on how to mitigate it while dealing with the reality that an ultimatum to choose between the browser and the organizational policy will often see the browser lose. Leaving the browser capable of browsing, while showing an unremovable information bar that warns people about something MITMing their traffic, seems like a strong step towards condemning MITM that might actually work.
If malware has write access to your certificate store, it is likely that it could also modify your certificate store or browser in a way that would bypass this warning.
When you're working at a company, using a company computer, you're not an "end user", though. If the machine you're using is infected with malware, the company needs to know about it, and what the malware did. To ensure full visibility, you need TLS interception.
I don't think they would. The issue isn't that traffic is being intercepted inside the enterprise. It's that the proxy performing the interception is issuing a certificate that uses SHA-1 in it's digital signing algorithm.
This was a problem for Pokémon Showdown recently. We use HTTPS for logins and some other things, which stopped working a few days ago for users using MitM antiviruses and Firefox.
There's no way to detect whether or not an HTTPS iframe has failed to load, so my workaround was to fall back to HTTP if the HTTPS iframe didn't load within 2 seconds. We still switch the connection over to HTTPS if the iframe does eventually load.
I'm kind of confused by why so many users thought it was a Pokemon Showdown issue, specifically. Doesn't Google default to HTTPS? PS shouldn't be the most significant website they have trouble with.
That opens you up to any active attacker simply stopping traffic. You're usually safe against passive attacks if the network has no glitches, but completely vulnerable to active attacks.
Then again, if you don't use https on the whole site, active attacks could already simply change the url of the iframe to be http and intercept that with sslstrip, and passive attacks could already steal cookies.
Yeah, I was going to ask the user for confirmation before falling back to HTTP, when I realized what you did: an active attacker can just change the URL of the iframe.
Anyone who really needs secure pokemon battles can just use the HTTPS site, anyway. (Which does ask the user for confirmation before falling back to HTTP, if an HTTPS connection fails)
Well, we do support full-HTTPS, it just isn't required.
If it were, PS would have been unusable to anyone with Firefox and Avast/BitDefender/etc.
It also allows image embeds. Users often share HTTP images in the chatrooms, which browsers using the HTTPS site complain about.
For some weird reason, Google Chrome doesn't support data-URIs in HTTPS when using HTML5 drag-and-drop to drag files from a website to the desktop, which requires an annoying workaround.
In addition, most people wanting to set up a third-party PS server don't want to go through the hassle of acquiring a certificate. It makes the setup process a lot more complicated than just "clone the repository and run ./pokemon-showdown"
It was challenging trying to explain to my parents that firefox was complaining about an anti-virus maker's man-in-the-middle certificate under the heading "Safe browsing protection" which, oddly enough, only really tried to spoof Google, Yahoo!, Bing, and Microsoft domains.
The bug speak about some security scanners and antivirus products. But the thing which triggered was a malware. Oups! I should have said a potentially unwanted program.
I hope this is just bad wording and not a setting that actually disables certificate validation? They can't possibly mean it will accept even invalid SHA1 certificates?
> security.pki.sha1_enforcement_level” to 0 (which will accept all SHA-1 certificates)
Setting security.pki.sha1_enforcement_level to 0 will still only accept SHA-1 certs that are signed by a root CA in the NSS truststore. That setting only disables the SHA-1 deprecation logic.
