Support Encrypted Client Hello (formerly known as ESNI) #7482
Comments
|
Your wording implies that it's done, and will soon be a standard. It's not done, it's going to be changing, and yes OpenSSL should support it once it gets finalized. |
|
Indeed; note that the intended status of the linked internet-draft is only Experimental; it is not intended to be on the standards track. |
|
Nitpick: the link you provided wasn't the last version; that's probably here: https://tools.ietf.org/html/draft-ietf-tls-esni (just clicked a few times, no deep knowledge; EDITed as suggested, and it's in OP now anyway) |
|
Leave off the trailing -XX part and you always get the latest version. |
|
Hiya, I've coded up a proof-of-concept version of the client-side of ESNI for openssl. It works with the CloudFlare deployment and doesn't seem to fall over (but no guarantees:-). The code is here. I also tried to document the design. I hope to work with a student to do the server side and track changes in the Internet-draft as that progresses. Comments are v. welcome esp if there's stuff to do to make this more likely to end up useful for the project when the standard settles down. |
|
@sftcd Is you code portable to BoringSSL ? |
|
Dunno, sorry, haven't ever looked inside BoringSSL. Happy to play about and see if that's useful at some point and someone tells me how:-) |
|
State in Go golang/go#9671 (comment) |
|
Hiya, we've done some more work on our openssl fork that has ESNI support and on a curl fork that uses that. It's early days, but if anyone wants to try play with the build and give us feedback that'd be great. Here's HOWTO. If you find any issues with that you'd like to raise then please raise an issue in our openssl fork or curl fork, or send us mail at the addresses in the HOWTO. Thanks. |
|
We've integrated our ESNI supporting fork with the lighttpd web server. Details here. Be interested if anyone has feedback on that. |
|
Safe? I believe, there's no (IETF-)standardized way to do ESNI yet, so it's necessarily an experiment that will need some (hopefully minor) tweaks before becoming stable. The IETF consensus seems to be moving towards using a different DNS RR to transport this piece of information. This record addresses more issues than just ESNI, but just as the previous one it hasn't been IANA-allocated yet. |
|
Yes, the number will change, and the DNS record as well. I don't know the plans of implementors (and those who've deployed it already) or even details of the TLS parts – perhaps the clients might probe for both records during some overlapping period 🤷♀️ EDIT: or more easily, the servers might publish the same key through all the different DNS records. |
|
Hiya,
On 08/01/2020 08:00, Vladimír Čunát wrote:
Yes, the number will change, and the DNS record as well. I don't
know the plans of implementors (and those who've deployed it already)
or even details of the TLS parts – perhaps the clients might
probe for _both_ records during some overlapping period
🤷♀️
Yes, the plan is to migrate to use of HTTPSSVC (though even
that'll undergo a name change, and no RRTYPE has been
picked for it yet). So there are a few changes ahead
before ESNI will be done.
The hope/expectation is that the current RRTYPE and the use
of TXT RRs (as was defined in draft-02 of ESNI) will be
dropped. I guess there's a small chance the TXT RR that is
deployed today by cloudflare might live on a while but I
don't expect the experimental RRTYPE to be something that
people need to support.
As for my coding plans: once the next spec revision is out
I'll try get it coded up as soon as I can. Hopefully
that'll all stabilise in the next month or two, but of
course predicting the future is an imperfect thing:-)
Cheers,
S.
|
|
For those who don't know, Stephen is a former IETF Security AD and a member of the Internet Architecture Board. Trust that he (and the project) will do the right thing :) |
|
On 10/08/2020 18:40, Valerii Zapodovnikov wrote:
Guy, chinese already blocked it (just blocked tls 0xffce extension
https://ntc.party/t/exposing-and-circumventing-chinas-censorship-of-esni/611),
Yes, that's being discussed on the IETF TLS list too. [1]
so any thoughts on 1-RTT after ClientHello?
I don't recall such an option being discussed so far in
the TLS WG, so maybe bring it up there. I'd not be
surprised if the browser folks already considered that
earlier on though.
Cheers,
S.
[1] https://mailarchive.ietf.org/arch/msg/tls/YzT5LjLJ_6WWhdnU2wVsKNKR6_I/
|
candrews
changed the title
|
Meanwhile the Russian government is going to forbid ESNI/ECH and block websites using it. This would be unlikely to happen if there were working implementations widespread, but this surely will if discussion take a couple years more. |
|
They can surely block way faster and simpler than "we" can do widespread deployment (of anything). |
That was less than 10 days, banking stuff stopped working so it works fine again.
China CCP thanks you for not including this in your software with like a compile flag or something. |
|
Any updates on this? Look I feel like I am talking to a brick wall here. China uses network asics not general purpose computers to filter traffic. When they need to filter a new type of traffic they need to build new asics. This takes approximately 8 months if they are having political unrest or 18 months if they are doing it without spending money with reckless abandon on etching the asics. Now why is this important? If implementation was widespread enough it would not be worth it to block. There is a reason why azure, a American company, is still not blocked. As blocking it would exceed the censorship value of the target. Now why should "we" care. Our goverments are not doing this? China will kill you if it thinks you are a threat to the CCP. It does not need a trial. It does not need a hearing. If they even suspect dissidence you will be picked up by a van and no one will ever hear from you again. Currently people buypass censorship in one of two ways: 1- cypher their traffic in a off the shelf cypher that is not currently able to be manipulated by the asics. Your traffic will look like VPN traffic and will be comparable to others who use the same cypher but will not be comparable to normal traffic. Both of these are problematic in their implementation because they can tell you are using a vpn with the non-asic components of the GFW. They take your traffic and stenograph it if you have too much signal to noise. TLS 1.3 echo is perfect unitl nullrouting it was doable (this has been reversed) due to Why this should be approved Approve this please. |
|
Checking to see if we can use ECH / ESNI yet? |
|
Hiya,
On 27/11/2022 00:50, Motophan wrote:
Checking to see if we can use ECH / ESNI yet?
Yeah, it's available behind a flag in browsers now (usually
only if you also turn on DoH), but not yet in servers other
than oddball things like mine (defo.ie) or cloudflare (which
I think is still an experiment too).
S.
|
|
Hi everyone, please forgive the ignorance, tried to understand what is going on in general with ECH. |
|
Given the history on this post, now deleted, maybe we can use the example of people such as employers not being comfortable with ECH and how they would attempt to defeat it. I mean as an employer, there's not a chance that I'm letting anyone in my network with a Tor-esque protocol. Frankly, if you can intercept DoH, you can still circumvent all of this, so you need to pin the cert used for DoH, in which case you just refuse to fulfill such requests and then this is still defeated. Essentially all the "magic" of this proposed system is just security through obscurity by fast rotating key exchange over DoH. It's not actually anything secure and won't protect a single person from oppressive regimes. Just want to clarify that. This is a joint business venture being written into crypto libs by companies who want to control vast real estate on the web. |
|
Hiya,
On 09/03/2023 14:52, vahidlazio wrote:
Hi everyone,
I got couple of questions regarding the support for Encrypted Client Hello.
1- It was mentioned above the Chinese ban on ESNI and the fact that they can do the same ban for ECH. (they can tamper the client hello message and remove the ECH extension, so even if the GREASE data is sent, if the server can work with the remaining stuff, fine, if not, the ECH will fail)
Not quite. The ECH extension still sticks out but a middlebox
cannot just remove it and see the TLS session succeed.
I consider this a security flaw that a middle man can examine what kind of features the server support. is there any mechanism already in place to prevent this? (maybe a client_hello_hash sent back from the server hello message and client checks if the hashes are the same with what it sent to the server?)
So I don't think the attack you mention above works. A TLS
handshake will fail if a middlebox changes any of the octets.
For more background, various designs and their consequences
were considered and documented in RFC9744 [1]
[1] https://datatracker.ietf.org/doc/rfc8744/
2- We still need to send the outer SNI in the outer ClientHello to the server, (if the handshake with ECH Config fails, the server should be able to attempt to do the handshake with the outer SNI) something like public.blah.com. imagine my server goes behind the Cloudflare CDN, can it be that the outer SNI is public-ech.cloudflare.com? then it will be almost impossible for middle-man to understand which website i'm visiting. the censorship strategy will be like all or nothing.
The outer SNI will be sent using the public_name value from
the relevant ECHConfig, typically published in an HTTPS RR
in the DNS. IOW, the server can publish the name it'd like
as the outer SNI in the DNS, and browsers will use that. The
idea is that that will likely be the same value for any web
sites that can be accessed via that server using ECH.
3- the fact we need to still set the outer SNI in clear text makes the censor's efforts minimal to block the service entirely. imagine they have some sort of white-lists, google services are allowed in Google Cloud but the random websites which might be VPN's are blocked. with outer SNI this is simple. except that the server either sends back a self signed certificate for a self signed "google.com" and the client approves this very certificate. (which if that works, we can already do this). and then it rises the question that if we can't hide the service we are visiting, what's the point of ECH anyways?
ECH will likely provide more benefit for those using a CDN
yes, where the cost of blocking the entire CDN may be too
high for a number of entities.
For a lone web-site, ECH adds less value, if e.g. the
destination IP address(es) can be used as the basis for
blocking.
There'll be some in-between cases too of course.
WRT certificate-based ideas, I'd again suggest a read of
RFC8744.
Cheers,
S.
…
please forgive the ignorance, tried to articulate what is going on in general with ECH.
Thanks.
|
|
thanks @sftcd ! IIRC the GREASE data will be sent with random values for ECH if the client version supports ECH even if the ECHConfig in the DNS records is not present. to make the client hello not stick out. basically the values of the extension are only semantically different making it hard for the censor to block it. For cloudflare i used wireshark and it seems the ech public server name is something like cloudflare-ech.com which i think if they roll it out something like that will be for all the domains they host. If it's the same case for Google then the cost for the censor is blocking the whole google cloud which also includes Google services. but the restriction here is you need to own the domain that you put in the DNS HTTPS record and have a valid certificate for that, the client must abort the handshake if the certificate is not valid for the public name. here the client can accept the self signed certificate which you referred me to the RFC8744. |
|
by "stick out" i mean it won't be clear based on the client hello if the server supports the ECH and if the DNS record for the ECHConfig exists since the ECH extension (real or fake) will be sent if the client supports ECH. meaning if it becomes widely the standard in the clients, distinguishing it for the censor is hard. |
|
This type of general discussion about the spec will be more effective if they are issues on the draft repository,https://github.com/tlswg/draft-ietf-tls-esni or the TLS mailing list (subscribe at https://www.ietf.org/mailman/listinfo/tls) |
|
On 09/03/2023 17:53, vahidlazio wrote:
thanks @sftcd ! ``` --> Not quite. The ECH extension still sticks out
but a middlebox cannot just remove it and see the TLS session
succeed. ``` IIRC the GREASE data will be sent with random values for
ECH if the client version supports ECH even if the ECHConfig in the
DNS records is not present. to make the client hello not stick out.
basically the values of the extension are only semantically different
making it hard for the censor to block it.
Correct. We'll have to see how well that works out and
what browsers do in terms of GREASEing. It'll certainly
be interesting.
``` --> ECH will likely provide more benefit for those using a CDN
yes, where the cost of blocking the entire CDN may be too high for a
number of entities. ```
For cloudflare i used wireshark and it seems the ech public server
name is something like cloudflare-ech.com
Right. That's an experimental deployment though.
which i think if they roll
it out something like that will be for all the domains they host. If
it's the same case for Google then the cost for the censor is
blocking the whole google cloud which also includes Google services.
Right again. The idea is the CDN taking part in the
game can add value to the web sites it's hosting via
ECH.
``` --> the server can publish the name it'd like as the outer SNI in
the DNS, and browsers will use that. ```
but the restriction here is you need to own the domain that you put
in the DNS HTTPS record and have a valid certificate for that,
The "you" here is the web site (not necessarily the CDN).
And they already need a DNS name and certificate for the
web in any case.
There are also other benefits to publishing an HTTPS RR
aside from ECH (e.g. addressing the CNAME-at-apex issue)
so the hope is that publishing HTTPS RRs may become quite
common, thus lowering the cost of playing the ECH game.
Again though, we'll have to see what transpires.
the
client must abort the handshake if the certificate is not valid for
the public name. here the client can accept the self signed
certificate which you referred me to the RFC8744.
I can't see a way a self-signed cert will help tbh. And
even if there were such a way, one would need to convince
browser makers, which seems like a longshot.
Cheers,
S.
PS: Rich is probably right that this discussion so far
would be more apt on the spec repo rather than the openssl
one.
… |
draft-ietf-tls-esni-09: google/boringssl@00e434d There aren't any technical changes from draft 13 to 16, the diff is only editorial wording and keep-alive from draft expiration. |
|
From the IETF117 meeting:
Source: |
|
Hiya,
On 02/08/2023 12:42, imsys wrote:
>From the IETF117 meeting:
- Chrome and Firefox are doing a 1% sample trials.
- They expect to submit to the IESG evaluation by January 2024.
Minor clarification: the "they" in the 2nd bullet means
the draft authors, not chrome/firefox:-) This is good news
though, as all going well the spec may become an RFC in
the new year at which point we hope to have an ECH PR ready
for consideration.
Cheers,
S.
…
|
|
Fyi, Chrome is shipping it in version 117 now: https://chromestatus.com/feature/6196703843581952 Firefox hasn't (to my knowledge) announced intent to ship to stable yet, but they're presumably not far behind. |
|
Firefox's intent to ship was sent in August: dev-platform |
|
@sftcd Is there a PR submitted? More generally I'd like to know what the prospect is of this landing comparatively soon/happy to review an API to see if it will work for us. |
https://blog.mozilla.org/en/products/firefox/encrypted-hello/ Mozilla has just announced support for ECH |
|
Hiya,
Not yet. My understanding is that OpenSSL maintainers won't merge a PR until after the RFC has issued per their current policy. So I was planning to make a PR towards the end of this year in the hope that the stars might align not too long thereafter.
I'm fine with making a draft PR sooner if that's useful for getting review - would that be useful? Or, for now the new APIs are in a separate header file if that's useful. I also have code (linked from defo.ie) showing how those APIs are used for curl, nginx, apache, haproxy and lighttpd if that's useful to review. (And I'd be delighted to get review of any of that) S. |
|
I'll leave it to others for the draft review: if there are draft docs as well as headers it might be helpful: sometimes it's tricky to see from just signature alone what's intended. Will send email soon. |
|
That branch does have some documentation too:
Again, any and all comments welcome. |
|
we're planning to address this here: will close this as a dup when we get started |
and others
Encrypted Client Hello is on the standards track and is already being deployed by big players.
Draft RFC: https://tools.ietf.org/html/draft-ietf-tls-esni
Championed by the EFF: https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
Deployed by Cloudflare: https://blog.cloudflare.com/esni/
Cloudflare's technical details post: https://blog.cloudflare.com/encrypted-sni/
Supported by Firefox: https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/
Supported by NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=1495120
Work in Progress in picotls: h2o/picotls#155
🤞 this can be in OpenSSL 1.1.2 😄
The text was updated successfully, but these errors were encountered: