Re: [TLS] Encrypted SNI

[Tony Arcieri <[e-mail]>]

On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan <[e-mail]> wrote:

> From my personal perspective, we need to be careful with all of these
> efforts. It feels like the pendulum has swung so far to one side, the side
> of privacy-at-any-cost, that we are unknowingly increasing the risk to
> individuals and organizations by enabling threat actors and intrusions sets
> to attack networks and clients without any level of protection from the
> network.
>

Speaking as an industry practitioner and network security professional,
don't trust the network. That is the entire purpose of TLS.

As one of my present job capacities I micromanage Juniper SRX firewall
rules. However, my personal view of the value provided is that it's a
defense-in-depth measure at best.

There are already many ways for attackers to take surprising and unexpected
paths through the network which are much more interesting and useful than
through a DNS+CDN's frontend terminator. Just as one example of such a path
which is incredibly hard to block is Amazon S3, where you can attempt to
whitelist a particular bucket by hostname, and even try to do NIDS to
ensure that S3 requests only go to mybucket.s3.amazonaws.com by inspecting
SNI and rejecting anything but a particular bucket in the SNI, but after
TLS has been established an attacker can send a Host: header of
attackerbucket.s3.amazonaws.com and S3 doesn't care what domain you used to
get there or what SNI you sent.


> It also feels like a lot of these initiatives are being done without
> adequately involving and ensuring that enterprise networks and critical
> infrastructure can work with these changes. Question, do we know how these
> ideas and changes are going to impact an organizations ability to fulfill
> their requirements for regulatory compliance?
>

I am a co-founder of a technology company, and was formerly on the
information security team of a publicly traded next-gen fintech company.
Speaking as a representative of industry, I would once again like to make
it very clear that demands for "visibility" represent one perspective
within industry as a whole. I think if it were possible to take a hum "from
industry", you would find it quite divided on this topic, particularly
between older larger companies and smaller, newer ones.

Having aided (in some cases instrumentally) with PCI-DSS, HIPAA, and SOX
audits in a modern fintech company with a card storage environment and
massive cash flows to account for and safeguard, my professional opinion as
someone on the information security team for that company is that the net
effect of ESNI on any of the compliance strategies being used is 0.

I think you might get a different perspective from someone whose compliance
strategy is largely predicated on e.g. Blue Coat "Visibility" appliances
who think things like passive SNI inspection are good indicators that
traffic flows are legitimate. However, while I'm aware this approach is
quite popular with e.g. older financial institutions, as noted above with
the S3 example it's still leaky. As long as you have a "legitimate"
frontend that can reach a backend which will honor the Host header over
what's in SNI and can get to both "legitimate" and attacker-controlled
resources, attackers can already bypass things passive SNI inspection.

That said, I think there are very much legitimate enterprise use cases of
this feature (see below).


> If we continue down these paths, then I fear networks will be required to
> wrap all traffic in some other less secure protocol, outright deny some of
> these protocols, or be forced to fully proxy all traffic or take an
> approach that Google has done with their BeyondCorp design.
>

In my opinion BeyondCorp-style designs are considered state-of-the-art by
the security teams of companies I respect, including the public fintech
company I formerly worked at which is presently in the process of migrating
from VPN-based access to a BeyondCorp-style approach.

As someone presently solving this problem for my company, I have recently
deployed Google's Identity Aware Proxy (IAP) to provide "front door"
authentication to internal web applications. IAP works by having you point
DNS at Google's frontend web servers, which terminate HTTPS, check for a
credential, and if it isn't present perform an OAuth flow. It integrates
with the rest of Google's suite of "BeyondCorp" tools including things like
Cloud Identity and Endpoint Verification to ensure all access to internal
tools is both strongly authenticated and coming from a known healthy
endpoint.

The important point here is that everyone using IAP is pointing DNS at the
Google frontend. In conjunction with e.g. Google Domains or GCP Cloud DNS,
IAP could support this approach to ESNI. In a BeyondCorp architecture, ESNI
would provide confidentiality for the DNS names of internal tools being
accessed through IAP. Using something like DoH in conjunction with
dns.google.com, we can completely reduce the parties who are able to
determine which internal tools are being accessed to Google exclusively.

Is there enterprise value to actually protecting this information? Well,
like network security, it is (or at least should be) only defense-in-depth.
But I still see value in defense-in-depth.

As an industry practitioner, from the perspective of the sorts of companies
I work at, I see no downsides of this approach. Instead see an interesting
feature which I want to use.

Framing things in terms of "privacy" versus "industry concerns" is a false
dichotomy, and one we continue to see being perpetrated by the "visibility"
camp, e.g.
https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises
(which had an awesome response from agl:
https://www.imperialviolet.org/2018/03/10/tls13.html). They are using this
as a rhetorical tactic to spin the "visibility" debate, when the reality is
that the interests of individuals and enterprises are not at odds. What are
at odds are improving Internet security for everyone versus the interests
of e.g. Blue Coat's customers whose compliance story presently depends on
their ability to break their own security from a single point of
compromise. More modern techniques like endpoint agents, tracing
frameworks, and other observability tools can tick the same compliance
checkboxes and solve the same problems like debugging complicated
service-oriented architectures. But it seems some people stuck on the Blue
Coat model would rather make Internet security worse for everyone than
invest in updating to a more modern approach.

Enterprises can benefit from privacy just as much as individuals. However,
not all enterprises within industry as a whole are ready to take advantage
of it. When seeking out industry input for IETF, make sure you're not only
paying attention to a particularly vocal segment whose views are not
representative of industry as a whole.

-- 
Tony Arcieri