
Man-In-the-Middle Interfering with Increased Security - jvehent
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/
======
JoshTriplett
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.

~~~
meowface
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.

~~~
bbayles
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.

~~~
AnthonyMouse
> 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.

~~~
meowface
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.

~~~
AnthonyMouse
> 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.

~~~
meowface
Being able to decrypt and modify TLS sessions pales in comparison to being
able to access your domain controller, or dump all your databases.

~~~
AnthonyMouse
It really doesn't.

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.

~~~
meowface
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.

------
Zarel
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.

[https://twitter.com/TonyFlygon/status/684756701027954689](https://twitter.com/TonyFlygon/status/684756701027954689)

(Example user complaint.)

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.

~~~
Buge
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.

~~~
Zarel
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)

------
jvehent
For some background around the discovery and analysis of the issue, see this
thread:
[https://groups.google.com/forum/#!topic/mozilla.dev.platform...](https://groups.google.com/forum/#!topic/mozilla.dev.platform/ZNKxYgIk_Sg)

------
ChuckMcM
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.

------
xcombelle
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.

------
0x0
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)

~~~
jvehent
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.

------
baby
What is the fix in the new firefox version? They removed these man-in-the-
middle root certs from the store?

