
Cloudflare, Mozilla, Fastly, and Apple Working on Encrypted SNI - sahin-boydas
https://twitter.com/grittygrease/status/1018566026320019457
======
exikyut
Related/relevant question.

A number of months ago I decided to finally begin researching a project I've
had on the backburner for ages: a simple domain+IP bandwidth throughput
counter for everything within my LAN. Basically I wanted to make a dashboard
saying "you exchanged this much data with this many IPs within the last 24h;
here's the per-IP and per-domain breakdown; here are the domains each IP
served", that sort of thing.

Part of the motivation for this was to track down the headscratch-generating
mysterious small amount of "unmetered data" my ISP reports each month (I don't
watch TV over the internet and cannot think of what else would be it), and the
other part of the motivation was to satisfy idle curiosity and observe
domain<->IP cohesion/fragmentation over time.

At the exact point I began my research TLS 1.3 had just been approved, and I
rapidly realized my nice little idea was going to get majorly stomped on: the
inspiration for the project, years ago, was the SNI field itself (hah).

5-10 years ago, I would have been able to route all my traffic through a
gateway box, and passively watch/trace (slightly behind realtime) everything
via tcpdump or similar, catching DNS lookups and sniffing SNI fields. That
would have handled everything.

Now, with encrypted SNI, and the upcoming DNS-over-HTTPS (seems I need to
think ahead :/), it looks like my (now irritatingly stupid-seeming) project
will require me to generate a local cert, install it on all my devices, and
get a machine beefy enough to keep line-rate speed while doing MITM cert-
resigning.

And then, for the fraction of traffic my system reports as "not signed by
local cert", I'm just going to have to let that go, or I'll break everything
that uses cert pinning.

...which I wouldn't be surprised if some programs eventually use with DoH
lookups (using pinned certs fished out of DNSSEC for DoH makes sense).

I'm very very interested to know if there are any alternatives I can use. I
realize, for now, that I can sniff for and collect DNS lookup results and
associate these with IPs, but when will this break?(!)

Honestly HTTPS and security in general just seems like a gigantic mess. I say
this not as a disrespect of the architecture, but more as a "wow, this is just
so hard to get right".

~~~
tialaramex
You will still be able to measure how much data goes to and from particular
IPs, since that can't be screened.

TLS 1.3 approval doesn't stomp on SNI; on the contrary, for the first time it
actually makes SNI mandatory - in previous versions it was optional, leading
to some HTTP implementations still not working with SNI late in the 21st
century. I had a corporate Python system I was responsible for that couldn't
do SNI even earlier this year.

You probably shouldn't attempt your idea of proxying everything. Proxies are
very fragile, and this will probably inadvertently worsen your security, while
also introducing weird non-security misbehaviour that's hard to track down.
For example Firefox will go "Oh, a MITM proxy :(" and it will switch off all
the safety measures built up over years for the public Internet because this
isn't the public Internet. In principle if your MITM proxy is enforcing the
same or tougher rules, this wouldn't be worse, but let's face it, you're going
to cobble together the minimum possible to make it work.

Every time somebody tries to get fancy and _think_ about the bits inside the
packets their network is supposed to be moving they screw up. That's the most
cynical reason why there's an impetus to encrypt everything. If the bits are
all encrypted gibberish the temptation to meddle with them goes away.

~~~
xg15
And yet a number of recent privacy breaches where apps were collecting and
transmitting data they had no business in were discovered by sniffing the
traffic.

> _Every time somebody tries to get fancy and _think_ about the bits inside
> the packets their network is supposed to be moving they screw up._

How do you propose we do security otherwise? (Apart from delegating it to
other parties so _they_ think about the bits)

~~~
wang_li
>How do you propose we do security otherwise? (Apart from delegating it to
other parties so they think about the bits)

The clear and obvious solution is to make developers, managers, executives,
and major investors personally responsible for the damage their products do.
If Google is going to encrypt everything using pinned certificates, making it
impossible for me to implement security features/boundaries of my choice, then
they should be 100% liable for all damages that come from the use of their
products. Additionally, if an analysis of the problem shows that is is related
to aspects of the product that do not directly related to what the end user
believes the purpose of the product to be, then there should also be criminal
liabilities for all parties as well.

~~~
nemothekid
> _The clear and obvious solution is to make developers, managers, executives,
> and major investors personally responsible for the damage their products do_

I struggle to understand how this is a "clear and obvious" solution. How would
you go about executing this? Legislation? The big famous piece of recent tech
legislation, GDPR, is, by most opinions, far and away "clear and obvious". And
given the US's current political environment, I'd struggle to believe any sort
of legislation could be passed that is "clear and obvious".

There has to be a better solution that "coordinate the interests, incentives
and motivations for millions of users, developers, managers, and executives to
pass some legislation that makes the latter group responsible."

------
tscs37
This is amazing work, can't wait for this to be finished and deployed on the
internet. Together with encrypted DNS (DoT and DoH) we finally get fully
confidential connections to a server without leaking anything other than
Remote IP.

~~~
evfanknitram
The Remote IP is almost as sensitive as SNI right?

~~~
hansjorg
Not always, see domain fronting:
[https://en.m.wikipedia.org/wiki/Domain_fronting](https://en.m.wikipedia.org/wiki/Domain_fronting)

~~~
blattimwind
Or services which use subdomains for individual users, e.g. #.github.io,
#.tumblr.com, #.blogspot.tld and so on.

~~~
cesarb
This. Currently, the difference between accessing github.com/blattimwind and
blattimwind.github.io is that, in the second case, which username you're
accessing is visible to all. Encrypted SNI will also protect that part of the
URL.

------
Cyphase
It's great seeing more and more work being done to increase privacy and
anonymity online, especially things like this which are about plugging
smaller, less obvious holes. Nothing is perfect, but the harder it is for the
snoops and spooks, the better.

~~~
Avamander
NTP over TLS next please.

~~~
georgyo
[https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-
ntp...](https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-12)

Which should be in ntpsec eventually.

[https://www.ntpsec.org/plans.html](https://www.ntpsec.org/plans.html)

------
zzzcpan
Am I understanding this correctly, they propose a _esni TXT record for a
domain containing a public key, which is used to encrypt SNI?

Who does this protect from?

ISPs that don't want to give up spying obviously are monopolies, have enough
power and can block DNS-over-HTTPS/TLS and all 3rd party resolvers. So can
censors. State actors can intercept DNS traffic even easier, since DoH/DoT
make it more centralized. IP address itself leaks so much information, that
cleartext SNI might not be even needed after all (meaning you can still
pinpoint a domain with high probability just by IP address).

Maybe this can help make collateral freedom a bit easier. But it's already
possible to achieve that with generated not known ahead throwaway domains,
they are cheap compared to CDN/cloud costs. And collateral freedom doesn't
really work against censorship all that well on its own, as centralization
makes it easy to pressure CDNs and clouds to deny service to dissidents. Not
enough collateral damage.

~~~
zamadatix
"ISPs that don't want to give up spying obviously are monopolies, have enough
power and can block DNS-over-HTTPS/TLS and all 3rd party resolvers."

Too many big players are behind it for ISPs to be able to get away with that
strategy. If a battle started then Google, Cloudflare, and others could simply
start hosting DNSoHTTPS directly alongside all of their major services. To
most customers 90% of "the internet" is the services from these providers.

"So can censors. State actors..." There is never going to be surefire way to
subvert a large government that controls the infrastructure you are trying to
sneak through. Even if there was the government would still be in control of
data at any companies that operate inside the country. It's not "outsmart
China or bust".

Rather than dismissing the solution as useless because it doesn't provide the
ultimate privacy maybe it's more worthwhile to look at what it can do and how
other changes to TLS and other protocols can continue to make things harder to
snoop.

~~~
mschuster91
> It's not "outsmart China or bust".

While we're at it: what prevents, say, a cartel of the world's transit
providers to cut China off from the Internet until they don't censor it any
more? And why haven't they done so? After all, there are only two outcomes:
the Chinese government goes fully intranet, but their economy tanks as a
result or the Chinese government backs down, with their economy (and civil
rights) profiting. Same goes for Russia or Iran.

It's about time that Western companies take a stance when it comes to civil
rights. So much technical and social progress is kept back out of the fear the
censorship creates, it must be profitable by now to simply force their hands.

Oh, and while we're at it, why are there still companies doing business with
our very own guilty parties in espionage terms? Why do they have bank
accounts? Why is anyone renting them office spaces, selling computers and
whatever else?

The same companies from USA, Germany, Israel and I believe also Italy do not
only supply our own governments (which is bad enough in itself) but also
dictators who use these tools to repress their own citizens.

~~~
about_help
Money. Sadly morals and convictions get quickly tossed out the window for
money and power. It is China's problem, why should Western companies damage
extremely profitable business relations? I agree with you that they should cut
off such countries, but modern morality is a lot more fluid and money is king.
Typical FYGM mentality.

------
jopsen
Lots of people here seem to focus on how this could prevent censorship and
spying by governments. It might raise the bar, and make such measures
infeasible for small countries, while also making it more visible.

But what we really should focus on is the added security everywhere else. Even
when I trust my ISP, that is no reason not to have defense in depth.

Someday WiFi or 4G network will have a horrible security flaw. And then this
will be another bolt in the next layer of security.

If security is important, we need multiple layers!

Focusing on what authoritarian governments might or might not do is pretty
much besides the point.

~~~
xg15
> _Even when I trust my ISP, that is no reason not to have defense in depth._

But if this is the method we are following, we will also need to think about
the costs-vs-benefits of different security measures.

If patching known exploits or threat-models, the cost-vs-benefit generally
allows for very strong security measures because you know the risks if you
don't implement it and you know when the measure is implemented and you are
done.

However, with "defense-in-depth" you could always add another layer of
encryption, add another sandbox layer or make a system less general-purpose.
If security is your only priority, there is no point where you would stop.

~~~
xj9
> If security is your only priority, there is no point where you would stop.

in a secure system, adding defensive layers is constrained by the amount of
code required to implement them. at a certain point, these layers can become
an attack surface, and therefore a liability.

------
social_quotient
One thing my team is working on and “waiting” for is the ALT SVC SNI extension
to be adopted.

If you haven’t read the spec it’s pretty fascinating.

[https://tools.ietf.org/id/draft-bishop-httpbis-sni-
altsvc-02...](https://tools.ietf.org/id/draft-bishop-httpbis-sni-
altsvc-02.html)

Working with ALT SVC’s and being able to set the SNI which piggybacks on some
of the OP encrypted SNI is pretty cool tech. It’s all early, hard to get
working, not supported by most browsers, but it’s going to allow for some
interesting future security and trust options.

------
chaz6
Would it not be simpler to issue an SSL certificate for the IP address for the
outer connection (kind of like how EAP works with inner and outer identities)
instead of relying on a DNS RR?

------
enitihas
Just curious, would it enable Signal and other tools trying to avoid
censorship by doing domain fronting without the cloud provider (e.g AWS
Cloudfront) noticing.

e.g.
[https://news.ycombinator.com/item?id=16970199](https://news.ycombinator.com/item?id=16970199)

[https://news.ycombinator.com/item?id=16868564](https://news.ycombinator.com/item?id=16868564)

~~~
icebraining
Arguably it's no longer domain fronting, it's just connecting to a server that
serves both sites without saying which one you want. So it's better, because
it doesn't break any rules. That requires AWS et all to support SNI
encryption, though.

What I wonder is about downgrade attacks. Browsers will probably have to
support clear-text SNI for a long time - could censors abuse this by making it
seem that no server supports encrypted SNI? Or is there a digitally-signed way
for servers to prove that they support it, before the browser sends the host?

~~~
tialaramex
The intent is that you'd be using a secured DNS channel such as DoH or DoT to
obtain your DNS results - so an adversary can't rewrite the DNS records.

This proposal supposes that when we've decided to talk to example.com we may
as well ask a DNS query that requests not only 'A' and 'AAAA' records (IPv4
and IPv6 address) but also an encrypted SNI key. If such a key is available we
can use it to prove to the server (which set that key) which name we wanted,
while eavesdroppers are none the wiser.

If the adversary can eavesdrop DNS they can already speculate from our query
which host we wanted to talk to, but securing DNS is a problem for which there
are known solutions.

~~~
icebraining
So censors can stop this by preventing the use of (non-controlled) DoH and DoT
servers?

~~~
namibj
No, the owner can sign the dns records and also sign the absence of a record,
and if the censor tries to tell the browser that there is no SNI key, without
being able to produce the signature to prove that, the browser can just treat
this as an MITM attack. This only work on signed DNS entries though.

~~~
icebraining
But they just want to block it, so if the browser and/or app treats it as a
MITM attack, that's fine from the censor's POV.

~~~
namibj
There is a difference between inciting end point devices to drop down to less
secure protocols, and alerting the user that you are running an active attack.

------
breakingcups
Does anyone know Google's position on this? I tried finding a relevant
Chromium issue but failed.

~~~
tialaramex
"Google's position" includes a lot more than just some Chromium developers,
and even Chrome is big enough for there to be internal tension between teams
focused on end-user security (e.g. encrypting SNI) and real world performance.

Google is a cloud operator these days, and as such if something like this is
to be of much use they'll have to eat the consequences at the other end, which
means their product (Cloud servers) working less well for uncontroversial
services than it might if they let censors do as they please. Basically for a
cloud operator or CDN choosing to actually implement a working encrypted SNI
solution (whatever it is) means now all your uncontroversial sites are obliged
to tell censors "I'm Spartacus" and reap the consequences. If the censor is a
single place of business or a micro-state maybe you can just suck it up. If
it's Russia then you've just decided you want to annoy all your paying
customers on a point of principle. I believe the word for that in Yes,
Minister was "Brave".

Ultimately, for this to be deliver much value (and if it doesn't why bother at
all?) it needs to be something every major cloud provider and CDN does for all
the sites they host. Which means from somewhere they're all going to need to
find a lot more backbone than is needed for, say, TLS 1.3 itself.

I hope it works, but I fear it will not.

~~~
matt4077
Google and AWS are each large enough to make blocking them a very expensive
proposition.

I also get the sense that Google is pretty good at prioritizing long-term
goals such as a fast and secure internet over any short-term considerations.

------
est
Can we do something about the certs? There are DPI that can block websites by
cert CN/SAN.

~~~
tscs37
This is sorta it. SNI is the only unecrypted part that leaks the server
hostname. CN/SAN blocking usually has a middlebox that decrypts the
connections so there is nothing to be done here.

If somebody can MitM your encrypted connection to both server and DNS,
encrypted SNI stops working to my understanding.

~~~
est
IIRC after ServerHello the cert was given to client in clear text.

~~~
geertj
This changed in TLS 1.3. The server cert is now encrypted.

~~~
est
That's cool. Is it possible to force google.com use TLS1.3?

~~~
tialaramex
If you insist upon talking TLS 1.3 draft 23, which is the last substantive
change before the draft went to the RFC queue, google.com is perfectly happy
to talk TLS 1.3 draft 23.

TLS 1.3 has downgrade detection, so if a middlebox tries to downgrade you
(e.g. to TLS 1.2) without proxying the entire connection the TLS 1.3
implementation in your client will spot that and reject the connection.

Proxying is possible (including with a downgrade) if you trust the proxy. So,
don't.

If you have a recent-ish version of Chrome or Firefox you are already using
all this.

------
ausjke
SNI is key to https virtual hosting. If encrypted how will the server know
where to go? More importantly, why not just use the "Host" header inside https
if you need SNI?

I mean, if SNI is encrypted then we don't need SNI at all, just use the Host
field inside https header which is encrypted already and carries all the info
you need know. Am I missing something?

Yes SNI could be encrypted outside of the SSL handshake in client-hello, but
why? will it be useful to defend domain fronting, don't think so.

~~~
tialaramex
The purpose of SNI is to allow the server to pick the right proof of identity
(usually an X.509 certificate) for the site the client actually wants to
access. This needs to happen before the HTTP session starts, so we can't wait
for a Host: header.

Yes, the intent is exactly to encrypt SNI during the initial ClientHello, in
particular the public key used will be found in DNS alongside the server's IP
address(es).

The key used will be the same for some set (perhaps all) of names hosted on
this IP address, so yes it achieves the same goal as "domain fronting" but
without tricks.

------
repolfx
This doesn't make much sense to me, I wonder if the senior management at these
firms understand what the engineers are doing.

You could already do something approximating encrypted SNI using domain
fronting. Connect to boring domain A via SSL, then send an HTTP request with a
Host header set to your actual target domain B. Load balancing HTTP reverse
proxies in the clouds would happily use the encrypted domain in the Host
header, ignoring SNI in the TLS headers. This started being widely used to
evade censorship and build "unblockable" services, because to block them you'd
have to block all of Cloudflare or Akamai or Google.

These firms all, as one, banned domain fronting. Turns out the bosses wanted
access to big markets more than they wanted censorship resistance.

So why do these developers think it'll work out any differently this time,
with slightly different packet formats? First company to enable encrypted SNI
will get blocked at the national level and will blink. The others will look at
it and probably never try.

If they're serious about making sites unblockable by domain, the first step is
to re-activate support for domain fronting and make a public commitment to
keep it.

~~~
acdha
> This doesn't make much sense to me, I wonder if the senior management at
> these firms understand what the engineers are doing.

When a bunch of well respected people decide to do something which you don’t
understand, maybe next time your first instinct should be to ask what you
don’t know rather than assuming they’re participating in an IETG process which
will be shut down?

In this case, you might start by questioning whether there’s any other
explanation for not supporting domain fronting in the past other than support
for censorship (hint: Google gave it at the time), and whether those sound
engineering reasons might in fact have lead to something like this as an
official supported alternative.

~~~
repolfx
Google did not give any engineering reasons at the time. That's misleading.
Here's what they said:

 _" Domain fronting has never been a supported feature at Google, but until
recently it worked because of a quirk of our software stack," a Google
spokesperson explained in a statement emailed to The Register. "We're
constantly evolving our network, and as part of a planned software update,
domain fronting no longer works. We don't have any plans to offer it as a
feature."_

This might superficially sound like domain fronting stopped working
accidentally, as part of other changes, but notice how carefully it's phrased.
They made an update. It stopped working. Nothing in this phrasing would be
false if they made a business decision to kill it and did so.

I find this explanation extremely likely for several reasons:

1\. It happened just when fronting was being adopted by Signal, a high profile
app that would have caught attention.

2\. All the other big players made the same change, again, prompted by
specific events related to anti-censorship.

[https://www.bamsoftware.com/papers/fronting/](https://www.bamsoftware.com/papers/fronting/)

 _GreatFire speculated that the attacks were precipitated by the publication
of an article in the Wall Street Journal that described in detail domain
fronting and other “collateral freedom” techniques. The interview associated
with the article also caused CloudFlare to begin matching SNI and Host header,
in an apparent attempt to thwart domain fronting._

This explanation turned out to be correct. CloudFlare said:

 _Among other network service providers, it 's clear domain fronting could be
awkward. "Cloudflare does not support domain fronting," a Cloudflare
spokesperson said in an email to The Register. "Doing so would put our
traditional customers at risk as it would mask banned traffic behind their
domains."_

Note that their explanation of why they killed it would also apply to
encrypted SNI.

3\. I worked at Google for a long time and am very familiar with their serving
infrastructure. I remember noticing that resolved hostname and host header
didn't have to match a decade or more ago. This ability lasted a _very_ long
time, right up until the moment people started using it in ways that upset
governments. Then it went poof.

I can believe that these particular 4 players might have had a change of
heart. Mozilla doesn't run any CDN or third party web services of note, and
has nothing to lose from implementing this. Nor does Apple. Cloudflare and
Fastly are both small firms who might have genuinely changed their minds,
although if they have they should state explicitly that they are newly willing
to let their "traditional customers mask banned traffic".

But I'm also not naive: it's possible some people are thinking, better ask for
forgiveness than permission.

~~~
viraptor
> "Doing so would put our traditional customers at risk as it would mask
> banned traffic behind their domains."

> Note that their explanation of why they killed it would also apply to
> encrypted SNI.

I'd say that's an interesting interpretation. What they likely meant is that
if govs/orgs want to block X and X starts using domain fronting via domain Y,
there's a chance Y starts getting blocked. (basic SNI/DNS filtering) The same
idea does not apply to the encrypted SNI - there's no damage to a random
domain, unless the whole provider range gets blocked.

~~~
repolfx
But the circumvention can use any domain and switch repeatedly, or dump lots
of them using various techniques and randomly select. It doesn't need to be
the case that domain Y is static.

In particular, note that encrypted SNI could just be blocked at the network
level, thus forcing fallback to regular old TLS. But domain fronting can't be
blocked like that.

~~~
viraptor
> It doesn't need to be the case that domain Y is static.

That's true, but I don't think it's relevant to what the providers want to
prevent. Even if the domain changes based on some pool, if Y is used at some
point, Y could be blocked as a collateral damage.

Since Y pays the provider, the provider cares about them not being blocked
because of a functionality they enable.

------
peterwwillis
I think it's worth pointing out the repercussions of this and DNS-over-HTTPS.

Every corporation which does SNI scanning for web filtering will require every
user to insert the company's CA cert in every client they use. This then also
forces them to make a choice between requiring all apps in all networks to do
this, or whitelist certain parts of the network. Not only does this reduce
their security, but it limits how apps can work on their networks.

Authoritarian governments will also start requiring this. I could even see
federal agencies for non-authoritarian governments making a stink over it on
law enforcement grounds. They already hate encryption. If they can't force you
to expose what sites you are visiting, they may force new legislation to
require all web service providers to provide logs to law enforcement, which is
a much worse privacy violation than just seeing what domain you were hitting.

I think the better solution to this would have been to improve server-side
support for VPNs and Tor. Tech does not exist in a bubble, and rights can be
taken away when they conflict with the interests of authority.

~~~
kristofferR
Forcing the installation of a root CA isn't a viable option for all but the
largest authoritarian governments (China and Russia).

Kazakhstan attempted [1], but abandoned the idea, likely since it was
unrealistic to expect widespread adoption of the certificate.

[1]
[https://news.ycombinator.com/item?id=10663843](https://news.ycombinator.com/item?id=10663843)

~~~
peterwwillis
A much easier solution is for the government to circumvent PKI entirely.
Basically you issue a National Security Letter to some cert provider and
require them to give you their keys. Now you can generate valid certs as that
provider. You use this in combination with a MITM tool to auto-generate certs
for any requested domain, and those certs are implicitly trusted by all
clients because they trust that CA's keys. So the state can now MITM and
listen to all secured connections, and the only giveaway is that the cert is
not in the certificate transparency log, or if the CA used does not match the
domain's CAA record (when it exists).

~~~
cesarb
> So the state can now MITM and listen to all secured connections, and the
> only giveaway is that the cert is not in the certificate transparency log,
> or if the CA used does not match the domain's CAA record (when it exists).

Or when the domain uses HPKP to pin its certificate to a different CA. When
the MITM CA has been added manually to the browser's root key store, most
browsers allow HPKP bypass by that CA unless configured otherwise; but if the
MITM is done by compromising one of the browser's default CAs, the browser
won't allow a bypass.

Or if the certificate was supposed to be an EV certificate, which can only be
issued by a limited number of CAs, and the compromised CA is not one of these.
And even if an EV CA is compromised, AFAIK some browsers require the
certificate to be in a Certificate Transparency log, and they also require
that the certificate carry proof of its submission to the CT logs.

~~~
peterwwillis
1) HPKP is dead, Chrome 67 removes support. 2) No client will flag an error if
the new cert is non-EV. EV is completely useless as a security feature. 3)
AFAIK no browser checks the cert transparency log.

------
mosselman
Is this really done by these companies or just by developers from these
companies in their spare time?

~~~
eastdakota
This has 100% support from the most senior quarters at Cloudflare. Can’t speak
for the others.

------
EGreg
What do you think the time frames are for something like this to make it into
all the major browsers?

~~~
RyanZAG
You'd need to get it into all servers too, which is probably a very long time
frame.

~~~
galadran
This design only requires the hosting server (e.g. Cloudflare, CDN, ...) to
support encrypted SNI. It can be entirely transparent to user deployed
servers. So it might well be here much sooner than you think!

------
XparentX
Is this a way for the ad-industry to evade pi-hole or similar technology?

~~~
icebraining
They would spend more money developing this than they would gain. Nobody, in a
statistically-relevant sense of the word, uses pi-hole.

~~~
XparentX
What do you mean, not use pi-hole?

~~~
icebraining
I very few people use it, to the point that the ad companies don't really
losing anything from it.

------
okket
Direct link to the tweet thread

[https://twitter.com/grittygrease/status/1018566026320019457](https://twitter.com/grittygrease/status/1018566026320019457)

Link to the RFC draft-00 "Encrypted Server Name Indication for TLS 1.3" on
which the work is based

[https://tools.ietf.org/html/draft-rescorla-tls-
esni-00](https://tools.ietf.org/html/draft-rescorla-tls-esni-00)

~~~
stingraycharles
Thanks, the UI of this Stackshare website is not that great.

~~~
breakingcups
I just get an almost blank page.

~~~
DeepYogurt
Me too. It has a lot of javascript that I'm blocking.

