
HTTPS Interception Weakens TLS Security - mlindner
https://www.us-cert.gov/ncas/alerts/TA17-075A
======
mlindner
The US government has basically declared "HTTPS/TLS Interception Considered
Harmful". This is going to be interesting as all the major security load
blanacer/appliances out there offer this as a standard service at this point.

~~~
Spooky23
No, they haven't.

They say pretty plainly that you need to ensure that such products provide
correct certificate validation, since the client cannot do so reliably.

~~~
jamiesonbecker
>> The US government has basically declared "HTTPS/TLS Interception Considered
Harmful".

> No, they haven't.

The original report headline from US-CERT: "HTTPS Interception _Weakens_ TLS
Security"

That seems pretty unambiguous, regardless of your personal feelings regarding
CERT or whether it speaks for the broader US government.

~~~
Spooky23
Don't analyze a book by its cover!

------
Animats
We need MITM detection in the browser.

Yes, it's possible. The crypto bits the host is sending are different from the
crypto bits the client is receiving. There are several ways to compare those,
despite what the MITM box is doing. Out of band channels, timing, and order of
data can be used.

I sometimes refer to HTTPS Everywhere as "Security Theater Everywhere". Before
the mania for HTTPS, many sites only used HTTPS only for crucial transactions
such as logins and credit cards. Those were infrequent enough that they didn't
have to go through a CDN. Now, with HTTPS Everywhere, there's no distinction
between the stuff that has to be hidden from observers, and the stuff which
only needs something like Subresource Integrity to make sure it hasn't been
messed with. So now the secure channel over which credit card numbers and
logins are passed is exposed at the CDN.

~~~
ancarda
It's not safe to do only logins over HTTPS because if the initial site is
served over HTTP, an attacker could rewrite the URL or inject JavaScript to
leak your password.

Also, once you're signed in, every request sends a cookie which is also
valuable to steal as it's an active session.

Every request needs to be encrypted. We haven't made TLS worse by deploying it
everywhere.

~~~
4ad
Logins? 99% of the websites I visit don't have user accounts.

~~~
icebraining
Not even for the person managing them?

~~~
aussie_dev
/wp-admin

------
Keverw
A while back I remember seeing on HN there was a issue with a certain vendor
and ChromeBooks because Chrome used a newer TLS(And the mitm vendor vendor was
noticed in advance too, and didn't update their product).

I wonder how schools and banks plan to react to this... Apparently financial
firms have to record everything their employees do for some regulations.

To me, schools doing this sort of thing is wrong. I wouldn't be surprised if
the principle would grab people's passwords and login to their accounts even.
I know some schools even went as far to demand students hand over their
passwords to social media when they report bullying... Which if the school
blocks social networks anyways, I don't see how it's a school issue for what
happens outside of school...

If this sort of thing really needs to be done, at-least people should be
warned and aware they are being monitored. If it's for a bank and it's only
company equipment everything is being monitored it seems a bit more okay to do
if everyone is well aware. "You are only to use work computers for official
business." sort of policy.

~~~
JumpCrisscross
> _financial firms have to record everything their employees do for some
> regulations_

Phone calls, emails, instant messages and other forms of client contact, yes.
Internet browsing history? No. Rest assured, many firms do this. But it's
because they decided to, not because of regulation.

~~~
Mandatum
Worked for Big 4. They did not log my phone calls or sniff my TLS traffic.

~~~
Spooky23
If you went through a proxy, they almost certainly did.

~~~
Mandatum
They didn't install TLS certs on my machine. My certs were the same ones I see
on my home PC.

------
tofflos
So how do I test if my workplace is doing a good job of this? The article
mentions badssl.com. Do I just click all the red links in the certificate
section and verify that my browser is refusing to display the pages?

~~~
tgasson
You want to do that both on your intercepted LAN and with a direct connection
and compare the results. If they both give the same results you can be happy
your MitM proxy is at least treating insecure sites equivalently. You still
lose the advantage that you browser will tell you _why_ the site is insecure

------
philbert
I still find it unfortunately shallow analysis.

I'm currently fighting a battle in a company in the middle of rolling out Blue
Coat ProxySG. I only became aware of it because it began causing interruptions
to our work since none of the development tools get the necessary root cert to
validate the certs that the proxy is rewriting. The root cert is only
installed into the Windows credentials to make browsers work and it's left up
to every client to fix whatever other problems they have.

One of the common arguments I've encountered from people is along the lines of
"if the company trusts the security people, then I trust the security people".
However this ignores the fact that the company has legally enforceable
agreements in the form od employment contracts, NDAs, and what-have-you that
protect the company against a breach of that trust.

But what kind of protection do you have as an individual if, for what ever
reason, one of the security people decides to single you out while they have
unsupervised access to you social media logins, personal email and credit
cards numbers and financial details (and lets face the fact that everyone does
all of these things to some degree on a work computer).

The answer is that you more than likely have no protection at all (likely not
even in workplace law). Even if you suspected someone had inappropriately
accessed your personal details, the company almost certainly has an IT policy
saying that you shouldn't be using your computer for personal use. You're
screwed.

However these inspection boxes drastically change the situation to what it was
before, because most people outside the IT department won't even know about
this drastic change in capability. And likely they try hard not to think about
until (if) they discover something has happened. I'm sure everyone here is
aware of the abuses of NSA employees spying on their wifes, or ex-es [0]. Such
is human nature.

Sadly I suspect that all these arguments will do little to change the
situation. It seems more likely that the companies who deploy these systems
are only going to listen to arguments specifically about how it is increasing
work, causing delays of deliveries and affecting project costs.

[0] [http://www.reuters.com/article/us-usa-surveillance-
watchdog-...](http://www.reuters.com/article/us-usa-surveillance-watchdog-
idUSBRE98Q14G20130927)

~~~
iamatworknow
This is exactly what my company went through just a few months ago when we
hired an IT security guy whose first order of business was setting up a Palo
Alto Networks firewall. Before turning on the MITM functionality he gave a
presentation to everyone about what it did, and nobody (support staff,
developers, administrators, management...nobody) seemed to mind except for me.

This was what I sent to the HR lead immediately after the meeting:

I remember a while back we all signed some document regarding data security
here. I don't remember what that document said specifically -- did it mention
at all the possibility that all of our network traffic could be monitored? I
ask because, while [new security guy] claims that with the new firewall "No
data is stored or made available for other purposes," the fact is that it
absolutely can be viewed and stored, and we as the end users have no way to
verify whether it is or not. On Palo Alto Network's own website there are
comments from other users of our firewall asking how to disable packet
inspection in the logs because, "I can also see users passwords in some
cases".

I understand and agree with the necessity of setting up a firewall that can
inspect encrypted traffic. However, I also understand that this means
everything we do or send on the office internet can be inspected by presumably
anyone with access to the firewall's back end (including personal passwords
and anything usually thought of as "secure"). I'm not sure how clear this is
to some (or most) of the employees here. If the agreements that we signed
don't reflect this, I think they should be updated and re-agreed to.

[some back and forth ensued, where she reminded me of a line in the agreement
that does say we can be monitored at any time]

That may be fine then. All I know is that I heard some concern over being able
to go to facebook and whatnot, which seemed to be relieved when we were told
it would still work. I just don't know whether or not people realize that
while they can still go to facebook, theoretically anything they say or do on
it, including all of their login information, chats, and posts marked to be
shown only to friends can (though not necessarily will) be viewed by the
company as well.

I could be making a bigger deal out of this than it needs to be, I just tend
to take online privacy matters pretty seriously. Assurances that the data will
be treated responsibly (not viewed or cached) are all well and good, but at
least for me, aren't good enough. I won't be going to any personal websites on
the network here at all.

~~~
philbert
But it's far worse than that. Look further down in the thread where a security
guy has pre-emptively invoked the "acceptable use" policy to cover for up for
incompetence to secure the MITM proxy appropriately.

Acceptable use policies are not self-enforcing, they are really only used
selectively, regardless if they say you shouldn't use your computer for
personal use. Everybody does that to some degree and it is accepted in reality
as long as it's within certain limits.

If the policy was self-enforcing then half the internet would be blocked, but
of course companies don't do that because no one wants to work in that
environment.

If you're watching porn or torrented movies, you'll either get a warning or
fired, but the company will do nothing if you make an online payment.

But what happens if the proxy gets hacked and the attacker gets hold of your
banking/personal logins/data? Who is most likely to discover the hack?
Probably the same security guys who are managing the proxy. Will the security
guys do the right thing and inform management that a hack occurred? Will the
company also then do the right thing and inform all their employees that a
hack occurred and now you might be missing some money? Will the company choose
to hide behind the “acceptable use” policy to absolve itself from liability
and say that it was you doing the wrong thing and stuck with the costs of your
actions?

At each layer beginning at the individual working in the security team, to the
whole security team, to the company management team, to everyone working at
the company, that the incentives are aligned to cover up such an incident
rather than reveal it.

The TLS inspection proxy is a bad system and worse still it’s a dangerous
system in the hands of people who are not capable of providing and unbiased
assessment of the risks they are exposing themselves and everyone else to, not
to mention the company. It’s more than just financial risk, it’s the moral-
hazard kinds of risk that really concern me because of the lack of
transparency/understanding of its roll out, the incentives to cover up when
something bad happens, and the lack of legal protections afterwards.

~~~
iamatworknow
I very much agree with all of these points, which is why, as I told my HR rep,
I won't use any personal websites on the work network at all since the HTTPS
interception was turned on. It's been a gigantic pain in the ass doing things
like checking my bank statements or whatever on my phone only, but I live with
it. The only non strictly work related site I go to is this one, with this
throwaway account/random password.

On the topic of liability and owning up to a potential hack, I think my
company would be transparent about it, based on a history of being transparent
about many atypical things in the past. We're not public, never received any
VC funding, and nobody has any equity stake in the company except for the
owner, who himself goes over the entire company's income statement in front of
all the employees once per year to let us know where all the money's coming
from/going to. I do believe he would do whatever he could to make it right,
because the buck stops with him and him alone.

Clearly that's only a small comfort if our personal information _is_ leaked,
but I don't think in my case it would be covered up. I could certainly see
that being the case in most corporate structures, though.

------
tinus_hn
And the answer is going to be custom unspecified encryption inside the
encrypted channel.

HTTPS mitm proxying is a dumb idea that can't work right but is easy to sell
to executives. It will be defeated until we're at the state of a few years
ago, where the products that really matter, like banking, have tough security
and the rest has less.

------
jusob
It does not have to be. Done correctly, SSL interception can pass through all
the errors to the client:

* certificate issues (expiration, domain mismatch, etc.)

* OCSP/CRL verification

* validation of HPKP header

I understand that few vendors may be doing it (I know one which does at least
the first 2). Probably the worst offense is choosing the weakest TLS version +
cipher to save resources, like using TLS 1.0 because it take less resources to
decode/encode than TLS 1.2 + elliptic curve.

~~~
userbinator
On the other hand, a MITM proxy can also do _upgrade_ "attacks"(?!),
communicating with remote servers over the Internet using a stronger protocol
than the clients on the LAN behind it support.

In fact it seems to me that having the validation happening in one place may
potentially be easier to maintain than across many different clients'
software.

~~~
hackcasual
My experience with browser companies vs. proxy software companies is that the
browser vendors give a much bigger shit about end user security.

~~~
andrewflnr
You're assuming people on the LAN can upgrade to recent browsers. A lot of
them are stuck on Windows XP. I realize that's a "you have bigger problems"
type of scenario, but you also have to play the hand you're dealt.

~~~
Laforet
If an organisation has a large number of networked computers on Windows XP
they are going to have more issues than that - having no SNI support is one.

~~~
omh
If you have an SSL intercepting proxy then you don't need SNI support on the
clients.

~~~
jusob
If this is an explicit proxy, this is true. But with a transparent proxy, SNI
would still be needed to know what domain name is going to be requested.

~~~
userbinator
With HTTPS, the Host: header, which is precisely what SNI was designed as a
use-case for, can be used.

~~~
jusob
But you see the Host header after the TLS handshake, after the certificate was
sent. The poitn of SNI is to indicate the host header during the TLS handshake
so that you get the right certificate. HTTP with the host header is one layer
up. Again, this is for transparent proxy where no CONNECT is being sent.

------
omribahumi
This is what squid has been trying to solve with their server first bumping[0]
and peek-and-splice[1]

[0] [http://wiki.squid-
cache.org/Features/BumpSslServerFirst](http://wiki.squid-
cache.org/Features/BumpSslServerFirst)

[1] [http://wiki.squid-cache.org/Features/SslPeekAndSplice](http://wiki.squid-
cache.org/Features/SslPeekAndSplice)

edit: reference peek-and-slice too

------
Khaine
One important reason to do ssl inspection is to detect the exfiltration of
corporate data, particularly if your organisation is likely to be attacked by
governments or sophisticated crime gangs.

I know my organisation do SSL inspection, but they have whitelisted common
personal websites like internet banking to protect the privacy of staff.

As far as I'm concerned, if your risk profile requires you to do SSL
inspection then this is the right way to do it.

------
seasonalgrit
any recommendations on tutorials/guides for better understanding the world of
TLS, certificates, and so on?

i don't feel like i have a healthy mastery of the ideas discussed in articles
like this one.

~~~
kbart
HTTPS is basically HTTP over TLS, so start with RFCs:

\- TLS v1.2
([https://tools.ietf.org/html/rfc5246](https://tools.ietf.org/html/rfc5246))

\- Certificate validation
([https://tools.ietf.org/html/rfc6960](https://tools.ietf.org/html/rfc6960))

\- PKI is a little more tricky, as there's no single standard that defines it,
though to get basic idea of what are certificates read RFC 5280
([https://tools.ietf.org/html/rfc5280](https://tools.ietf.org/html/rfc5280)).

Sure, you can dig as deep as you want, but these resources should give you a
good starting point.

~~~
rkeene2
Don't forget RFC 2818 (HTTPS) which Chromium (and thus Chrome) recently broke
mandatory features of:
[https://bugs.chromium.org/p/chromium/issues/detail?id=308330...](https://bugs.chromium.org/p/chromium/issues/detail?id=308330#c39)

~~~
NetStrikeForce
Is this a remake of that "embrace, extend, ..." movie of the 90s or this time
it's cool?

~~~
rkeene2
It's really very similar. This is a case where the Chromium developers want to
do something so they are going to do it, standards be dammed...

------
evilDagmar
TL;DR: If your organization is going to do HTTPS interception, _don 't screw
it up_.

~~~
angry_octet
I think the take away is that your mitm box _will eventually screw up_ , and
you will be liable for whatever results, from brokenness (e.g. the 40,000
chromebooks going offline) to complete disclosure of company-breaking
information.

------
jaimex2
_Reading the title_

... no shit.

~~~
jupp0r
Exactly my idea, but after reading the article I'm severely disappointed that
the whole practice isn't declared bad. Instead it only points out that some
mitm boxes are even more broken than I though possible and mess up cert
validation.

~~~
jaimex2
It's a terrible practice, the article doesn't even go into some other things
like how easy is it to actually break into the intercepting software and steal
the private cert so you can mitm the network for free!

and I'm a dev at one of these companies!

We really didn't want to add the feature but we were bleeding customer's who
for some reason had to have it. ( Yes, we do validate the certificates )

We decided to bite the bullet when it looked like even Google was "supporting"
being mitmed as a customer pointed out.

Reading this article...
[https://support.google.com/a/answer/1668854?hl=en](https://support.google.com/a/answer/1668854?hl=en)

was my biggest "fuck you" moment.

------
synicalx
It might weaken TLS, but it also stops the 3000 head of cattle I managed from
being able to watch porn (6 incidents) and torrent movies (47 copyright
notices). If their internet banking, which they're not supposed to be doing at
work, gets compromised then I really couldn't care less.

~~~
plugger
Instead couldn't you just whitelist the online banking sites and intercept
everything else?

~~~
synicalx
That would defeat the whole point of a proxy, if I can't see what they're
doing and report on people who are doing the wrong thing (according to their
employment contract), then why bother?

~~~
mulmen
Because if you block it then they can't do it and you have nothing to report.
Everyone wins.

~~~
jupp0r
That's one way to see it. In my experience, those proxies in schools are a
great way to motivate students to self-educate about how the internet works
and about online privacy tools like TOR...

~~~
mulmen
Why is a proxy necessary for a student to self-educate? Are you just saying
this is a lesson they learn the hard way once they have been spied on?

