
The Security Impact of HTTPS Interception [pdf] - DeltaWhy
https://jhalderm.com/pub/papers/interception-ndss17.pdf
======
simias
I was surprised by this note (on page 2):

> Contrary to widespread belief, public key pinning [19] — an HTTPS feature
> that allows websites to restrict connections to a specific key — does not
> prevent this interception. Chrome, Firefox, and Safari only enforce pinned
> keys when a certificate chain terminates in an authority shipped with the
> browser or operating system. The extra validation is skipped when the chain
> terminates in a locally installed root (i.e., a CA certificate installed by
> an administrator).

Seems like a strange default to me. I feel like the user should be notified of
this, for instance if they're using a work computer to access their bank
account or something like that.

~~~
pfg
Trying to fight a local attacker with root (which is necessary to add a
certificate to the trust stores on most platforms) isn't worth the effort.
It's easy for the admin to bypass and would cause even more warning fatigue.

That's not to say I disagree with the sentiment that this is something
employers (and other organizations providing access to devices) should be
obliged to disclose, but that is perhaps more of a legal and educational
issue.

~~~
simias
> It's easy for the admin to bypass

If it involves patching and recompiling the browser it wouldn't be that
trivial for your average sysadmin. Besides I don't see why the admin would be
hostile to the users being aware that they're being monitored. As you point
out companies generally disclose that anyway.

~~~
tptacek
No, sysadmins don't patch browsers. Endpoint security products do. Patching
browsers to implement TLS interception is table stakes for security products.
Local pin enforcement would in fact result in million more surreptitious
browser patches.

~~~
debatem1
Maybe on windows. Do you know of any Android security products which do this?
Why does Chrome for Android not implement this?

------
nailer
From the conclusion:

> We deployed these heuristics on three diverse networks:

> (1) Mozilla Firefox update servers,

> (2) a set of popular e-commerce sites, and

> (3) the Cloudflare content distribution network.

> In each case, we find more than an order of magnitude more interception than
> previously estimated, ranging from 4–11%.

> As a class, interception products drastically reduce connection security.
> Most concerningly, 62% of traffic that traverses a network middlebox has
> reduced security and 58% of middlebox connections have severe
> vulnerabilities. We investigated popular antivirus and corporate proxies,
> finding that nearly all reduce connection security and that many introduce
> vulnerabilities (e.g., fail to validate certificates).

------
LogicX
I'll jump on my current soap box, which is that we need a standard to allow
MITM blocking, without interception, and a nicer user experience.

This won't solve all use-cases, but selfishly, It will solve mine at
DNSFilter: If a browser could recognize our SSL cert, or a special field in
our cert, and present the user with a block message, and a static link to
learn more, it would eliminate the need for us to have our customers install a
CA of ours, and MITM traffic. We have not yet done so, and I'd prefer not to,
but it seems to be the industry standard way of avoiding users being confused
by errors when we block/MITM an SSL site.

~~~
Artemis2
I've written a proxy that uses SNI to filter outgoing connections based on the
domain name, without decrypting the traffic. It's not exactly user-friendly as
you'd like, but it's a good solution to our use-case.

I might open-source it if there's interest but it's relatively basic.

~~~
LogicX
I'd be interested in seeing what you've got -- I have on my list to look into
doing so with HAProxy per the link here:
[http://serverfault.com/questions/628147/nginx-proxy-based-
on...](http://serverfault.com/questions/628147/nginx-proxy-based-on-sni-
without-decryption)

------
einrealist
Its sad that interception receives such a bad reputation because of broken
security products. Yes, a proxy is a weak link. But if implemented properly
and in a trustworthy way, then its better than having endpoint security, which
is often worse. And no, the proxy does not belong on the endpoint itself! If
organizations with proxy interception are not able to scan traffic, they will
just drop the traffic. Instead of using MITM mitigations that don't allow
interception at all, we need better user experience (with choice) and safe(r)
products.

I have a little side project where I try to implement a proxy for myself. I
want to remove ads and be able to scan and cache downloads. I trust the
adblock plugins and endpoint security products far less than a MITM proxy, I
wrote myself.

~~~
ownagefool
Why does the proxy not belong on the endpoint?

~~~
einrealist
For various reasons: you probably have more endpoints on your network than
proxy servers and thus a bigger attack surface. Keeping the endpoints up-to-
date is harder (e.g. laptops that are not permanently attached to the network
to receive updates). If your endpoints are workstations, human interaction
(e.g. installing malicious software, opening malicious attachements) and the
overall complexity of the system (e.g. GUI, multiple users) makes it weaker
than a central, dedicated, isolated, stripped down and locked down set of
proxy servers. And finally, process isolation is really, really hard (if your
countermeasure _only_ runs on the target (endpoint), you already weakened your
position).

------
codezero
Is there a website you can visit that will tell you if your TLS handshake
doesn't match your browser's user agent?

Maybe this will have to wait until after the team from this paper releases
their fingerprints:
[https://github.com/zakird/tlsfingerprints](https://github.com/zakird/tlsfingerprints)

~~~
cesarb
[https://www.ssllabs.com/ssltest/viewMyClient.html](https://www.ssllabs.com/ssltest/viewMyClient.html)
tells you what your client handshake looks like, and
[https://www.ssllabs.com/ssltest/clients.html](https://www.ssllabs.com/ssltest/clients.html)
shows the usual handshake for several popular browsers.

------
ejcx
Another blow to the utility of AntiVirus.

I hate the AV industry in infosec. It does not work well and in most cases,
refundes security. Unbelievable that it's still required for a lot of
compliance veers.

------
__david__
What is the meaning of the "AS" acronym that the paper uses (seemingly
representing network providers)? I didn't see it explained anywhere and it's
not ringing any bells with me…

~~~
scotchmi_st
AS refers to the Autonomous System.
[https://en.wikipedia.org/wiki/Autonomous_system_(Internet)](https://en.wikipedia.org/wiki/Autonomous_system_\(Internet\))

It's an IP routing concept. AS Numbers are used to refer to different networks
(run by different ISPs and providers) on the internet.

------
Chris_Newton
I’m surprised by the contrast between the best products in each category and
the average standard. The few good ones show what is possible, yet the vast
majority seem to be sub-standard or outright dangerous. I wouldn’t have been
surprised by the odd outlier where someone dropped the ball, but I expected
much higher general standards.

~~~
hannob
> The few good ones show what is possible

If you've read that out of the paper you read a different one. Quote:

"Our grading scale focuses on the security of the TLS handshake and does not
account for the additional HTTPS validation checks present in many browsers,
such as HSTS, HPKP, OneCRL/CRLSets, certificate transparency validation, and
OCSP must-staple. None of the products we tested supported these features."

Read: Some products got the absolute basics right. None of the solutions did
anything that can reasonably be called "good".

> I expected much higher general standards.

I didn't. I don't expect anything from security appliance vendors.

------
jaimex2
Yep, HTTPS is a joke. Always secure your own transport if its sensitive.

