
Google and Mozilla's message to AV and security firms: Stop trashing HTTPS - jgrahamc
http://www.zdnet.com/article/google-and-mozillas-message-to-av-and-security-firms-stop-trashing-https/
======
mholt
I really believe this is an important study. To help expose MITM, I
implemented HTTPS interception detection features into Caddy, based on the
heuristics described in the paper:
[https://github.com/mholt/caddy/pull/1430](https://github.com/mholt/caddy/pull/1430)

The web server is in a unique position to be able to detect interception where
the browser can't, and then choose how to handle it (warn the client, log the
event, whatever). If you want to test this feature, I welcome your bug
reports!

For example:

    
    
        {{if .IsMITM}}
        <b>We have reason to believe your
        connection is not private, even if
        your browser thinks it is.</b>
        {{end}}
    

Or:

    
    
        redir {
           if {mitm} is likely
           /http-451-censorship.html
        }
    

The researchers won't be releasing the fingerprints they collected until after
NDSS '17 (March), but I'll look at taking those into account when they are
available.

~~~
javajosh
You're doing excellent work with Caddy, Matt. This solution of yours, which
detects inconsistent headers on a single connection, is a good one. What will
you do if and when MITM attackers do the extra work to duplicate headers?

~~~
mholt
Thanks Josh, I appreciate it. Their method works by comparing the User-Agent
HTTP header to the characteristics of the TLS handshake of the underlying
connection.

There are some exceptions, but TLS proxies generally don't touch the User-
Agent HTTP header. Doing so runs the risk of breaking things at the
application layer. TLS proxies probably don't care if they break things (hence
the research) but a proxy that wants to hide (malware, censorship, etc.) would
not want to risk breaking HTTP.

This method, for the time being, should effectively force TLS proxies (who
want to hide) to preserve the qualities of the original TLS connection. Then
if the connection is weak, the browser can at least warn the user. I'm not
certain this is a permanent solution, but given the eternal turnaround time of
corporate products, I suspect it will be useful for years to come.

------
zaphar
Sadly for companies in some industries (i.e defense or healthcare) there are
regulatory compliance issues that force them into running something that can
intercept TLS connections. These companies are many times in a position of
either weakening security or failing an audit. Until the regulations catch up
they will be stuck between a rock and a hard place.

~~~
hehheh
Should people in those industries have access to the outside web on the
computers that have even a smidge of access to data that must be kept private
by law? I'd say "no" \-- I can't think of a scenario in which a healthcare
device needs access to Google or hacker news or whatever.

They could just use a whitelist and replace all CAs on the computer with a
(set of?) private CA(s) that allow the user to do work on information that
requires such security.

~~~
jcrawfordor
Telling people that they cannot 1) have their records management system and 2)
have internet access on their computer is simply unrealistic. Basic measures
like blocking webmail providers are extremely unpopular with employees and
produce huge executive pushback, a whitelist approach to internet access like
you propose would just be a total non-starter. Imagine if you yourself worked
in that environment, where your computer could only access a few select
websites because you have access to restricted information (which you almost
certainly do) - I mean, most tech workers I know are deeply upset about not
having local admin on their machines. What you're proposing is about a
thousand steps more restrictive.

~~~
crpatino
> Telling people that they cannot 1) have their records management system and
> 2) have internet access on their computer is simply unrealistic.

I bet 100 years ago it was considered unrealistic to tell white collar
employees that they could not bring booze to the office. Today it is a firing
offense in most jurisdictions.

After all, people are already aware there is a distinction between their
professional personna and their private self. They know there are things you
do under one identity but not under the other, and viceversa. Merely adding
one tiny thing to the list will do little.

Sure, executives will push back. I bet they pushed back even harder when
accountants told them that "No, you cannot put your stripclub bill into the
corporate credit card; and I don't care if it was a business expense, either."

That's the meaning of being a professional: telling the higher-ups that there
are hard rules (natural or otherwise) that don't give a flying-fuck about
their social status. Doctors know it, lawyers know it, accountants know it,
but for some reason IT people does not seem able to figure that out.
Compensation aside, the social prestige that comes with each of those
professions is directly proportional to their ability (and duty) to enforce
those standards regardless of what their rich and powerful bosses think about
it.

~~~
true_religion
It's difficult to hold professional standards without a professional
association backing you up. Doctors and lawyers would capitulate to client
requests if they didn't have the backing of the professional associations, and
in many times law.

If you attempt to force your lawyer to violate ethics, and their document it
and complain then _no_ lawyer will work for you.

If you attempt to force a doctor to violate ethics, then not only will no
doctor work for you, but you might actually get jail time.

------
rkeene2
My main complaint with attempts to MITM TLS is that it is a failure -- you
cannot actually MITM TLS without breaking TLS. Specifically, TLS client
certificates are almost always broken when by attempts to MITM TLS and we use
TLS client certificates for almost all HTTPS connections.

~~~
majewsky
This was actually a huge problem when, at $work, we recently locked down our
productive Kubernetes clusters to only allow access via an SSH jump server.
The approach that we've settled on is to have a forward HTTP (without S) proxy
on the jump server (listening only on localhost) whose port is forwarded to
the local machine by SSH, so we can do `export
https_proxy=[https://localhost:$forwarded_port`](https://localhost:$forwarded_port`)
to make kubectl work. sshuttle was also evaluated, but it clashes with the VPN
client that the remote colleagues need.

~~~
majewsky
Cannot edit anymore, but that sould be "[http://"](http://") instead of
"[https://"](https://").

------
paulddraper
I see a lot of hate for TLS interception of any kind, but I did it just the
other day for my CI servers. This isn't what Chrome and Mozilla are upset
about, but it's an example of IMO valid TLS MITM.

Our multi-language build process downloads from Bintray, Maven, npm, Github,
Cloudfront, S3 using curl, Maven, SBT, npm, apt, etc. To improve times and
insulate against downtime, I MITM the CI servers with a caching proxy.

Two environment variables (http_proxy, https_proxy), and everything is cached,
fast, and reliable.

~~~
rkeene2
There is no valid TLS MITM. All attempts at TLS MITM break TLS in some way --
very commonly with TLS client certificates.

Edit: You're only proxying the encrypted data and not trying to do a MITM, so
this doesn't break TLS, but it doesn't do a MITM. I added this complaint as a
more general statement at the top-level of comments.

~~~
wang_li
It's my network with my assets and my data. Only I decide what is valid wrt to
TLS on my network. The number of applications that purport to service a
particular purpose but then proceed to exfiltrate substantial amounts of data
that is not even tenuously related to the purpose of the application has
destroyed any good will on my part.

On my network there are an order of magnitude more valid TLS MITMs happening
than there are valid non-MITMed TLS connections.

------
tyingq
HPKP[1] everywhere? Are any of the antivirus or corporate proxy products able
to defeat it?

[1]
[https://en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning](https://en.m.wikipedia.org/wiki/HTTP_Public_Key_Pinning)

~~~
mrbabbage
> Chrome does not perform pin validation when the certificate chain chains up
> to a private trust anchor. A key result of this policy is that private trust
> anchors can be used to proxy (or MITM) connections, even to pinned sites.
> “Data loss prevention” appliances, firewalls, content filters, and malware
> can use this feature to defeat the protections of key pinning.

[https://www.chromium.org/Home/chromium-security/security-
faq...](https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-
does-key-pinning-interact-with-local-proxies-and-filters-)

I can't remember what Firefox does in this situation

~~~
tyingq
Wow..That pretty much neuters the entire purpose.

~~~
aseipp
Except for the fact that HPKP actually works and has been working. The part
that "does not work" \-- which is actually a design issue -- is that it does
not override private anchors.

The real thing you seem to be upset about is that Chrome even _allows_ you to
MITM TLS connections at all at any level, whether or not the "actor" is your
boss or a rogue adversary. It's debatable whether or not this is a good
policy[1]. It's also a completely separate debate from whether HPKP is
"neutered" or not.

[1] Realistically, it mostly doesn't matter what you think, because here's
what will usually happen: Chrome doesn't allow MITM. Your business then
enforces a network policy that bans Chrome from all devices. The alternative
browser still allows MITM, and you still have to use them, and thus it still
happens to you and everyone else. The end.

------
j_s
You can request a second opinion attempting to detect MitM via JavaScript
using snuck.me:

[https://jlospinoso.github.io/node/javascript/security/crypto...](https://jlospinoso.github.io/node/javascript/security/cryptography/privacy/2017/02/20/snuckme-
cert-query.html)

The usual client-side JavaScript crypto caveats apply.

------
jpalomaki
The reason why corporations are doing this is because they are afraid what
kind of (malicious) content is coming down to their network and what users are
possibly sending out.

Could we fix this by isolating the browser more efficiently from the local
workstation environment and thereby removing the need for this kind of
security?

What if you would be executing the Internet browser in an environment where
you would not need to care so much about the security. Like running the actual
browser process in a completely separate environment, maybe located outside
your intranet firewall and just streaming the UI via some simple-enough-to-be-
secure mechanism to the desktop.

------
j_s
An client-side SSL interception API exists: SSLKEYLOGFILE. It isn't any help
for security appliances though.

Also, it is only implemented in Firefox and Chrome; Microsoft doesn't support
it in their browser or at the OS level.

I'm suprised it still exists, it seems like a juicy malware target, just like
these poorly implemented SSL MitMs.

------
SimeVidas
I still don’t know if I’ve disabled HTTPS interception in ESET Internet
Security. I went in Settings > Internet Protection > Web Access Protection >
Web Protocols, and then disabled HTTPS checking, but I’m not sure if that’s it
or if there’s more.

~~~
cesarb
If you're using Firefox or Chrome, go to a site with an EV certificate (for
instance [https://twitter.com/](https://twitter.com/)), and check if it shows
the EV bar. These two browsers only accept EV certificates from a few
hardcoded CAs, so if it's still being intercepted, it won't show as EV.

Another option is to check the certificate for any website; for instance, the
one for this site should chain to "COMODO RSA Certification Authority", and
for me shows the SHA1 signature
BB:DD:64:6F:EB:11:0C:D5:EC:CF:57:D1:F7:52:AA:99:50:1B:44:FD.

~~~
lisivka
No EV bar at twitter site in Firefox in my case, nor at google.com, Facebook,
etc., but thawte.com is displayed properly (Thawte, Inc. (US)). :-/

~~~
SimeVidas
Same here. I think we’re fine. The certificate chains don’t show anything
suspicious.

------
askvictor
Is it not possible to implement an interception or proxy API in the browser?
That way everything is above board, and the user knows what's going on.

------
reiichiroh
What about intercepting SSL decryption in the workplace with Fireeye and Palo
Alto type devices?

------
nrki
Please also stop trashing SMTP.

------
Spooky23
Obviously HTTPS needs to be implemented correctly.

But this is more a problem with the knee jerk HTTPS everywhere movement and a
quick and dirty response than anything else. The browser and OS vendors don't
provide high quality APIs for this purpose, so customers are stuck picking
security products without an easy way to identify quality gaps.

Even in unregulated industries, most commercial enterprises should be doing
TLS inspection -- i would argue that's it is irresponsible not to. How can you
claim to protect customer data or respect customer privacy without looking at
the data flowing out the front door?

~~~
__jal
Can you describe what is "knee jerk" about HTTPS everywhere?

It sounds like you're saying that you believe HTTPS is a bad solution to
(presumably) the problem of surveillance-friendly plaintext comms via browser.
But I'd like to understand.

You also seem to be claiming that AV products are somehow a special category
of security product, for which evaluation is especially difficult. I don't see
it, and in fact, there's a handy chart in that post to help.

Companies that have audit requirements for these things are most likely going
to need purpose-built tools for this; depending on AV crapware is a terrible
idea.

And as for the notion that "most" enterprises should be shoulder-surfing their
employees, well. I assume you also recommend all employees pass through a
metal detector and have all thumb-drives and whatnot inspected on the way out?
If not, why not?

~~~
3pt14159
Should elementary aged school children have privacy while surfing the internet
from school? If the answer to that question is "no" then the answer about
HTTPS everywhere can be seen as knee-jerk.

Of course, system administrators could put further work into making sure that
computers are not used maliciously, for example, by recording the screen
constantly and by randomly inspecting the recording or by using machine
learning to identify things like pornography, but it won't cover everything
(browser bars that are actually malware or other viruses) and it's a whole lot
easier to just thwart HTTPS than it is to do anything else.

~~~
nsgi
Yes, they should. They might want to look up information on abuse, sexual
health or homosexuality in confidence.

There are other ways to accomplish preventing children from accessing
inappropriate content, namely filtering by domain which is still possible with
HTTPS. Google SafeSearch can also be turned on at the DNS level, still
allowing HTTPS to be used and privacy to be maintained.

The best way to accomplish more granular filtering is to install a custom
browser extension that monitors what pages are visited, no machine learning
necessary. And if group policy doesn't prevent browser toolbars from being
installed, the school has bigger problems.

~~~
3pt14159
You're simultaneously saying that children should have privacy while also
saying children should have browser extensions that monitors what pages are
being visited.

