openssl
openssl copied to clipboard
openssl
Support Encrypted Client Hello (formerly known as ESNI)
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: https://github.com/h2o/picotls/pull/155
:crossed_fingers: this can be in OpenSSL 1.1.2 :smile:
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. It will likely be changing more, and the risks and benefits are not terribly well understood yet.
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)
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.
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:-)
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 :woman_shrugging: 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 :woman_shrugging:
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/
ESNI has evolved and has become EncryptedClientHello, ECH. ECH is still being developed. I know @sftcd (who did the initial ESNI implementation) is very involved with ECH. Your pessimism is misguided, @Motophan
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).
eSNI is already blocked by China. The only way is to use some kind of 1-TRR and certs in DNS.
That was less than 10 days, banking stuff stopped working so it works fine again.
ESNI has evolved and has become EncryptedClientHello, ECH. ECH is still being developed. I know @sftcd (who did the initial ESNI implementation) is very involved with ECH. Your pessimism is misguided, @Motophan
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 the protocol changes, even a little, it cannot be dpi'ed because the asics cant kick the packets off the network or insert incorrect data.
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 has infinite money to throw at the GFW because they print the money they spend on it. They can spend any amount of money on it including devaluing their own currency. Cost means nothing to them.
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. 2- cypher their traffic in a personal cypher that is not currently able to be manipulated by the asics. Your traffic will look like VPN traffic but will not comparable to others and 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 1- having asics capable of nullrouting this traffic 2- willing to deal with the loss of this type of traffic on the network It turns out this traffic stopped a lot of forign banking from working so the decision was reversed and China is putting pressure on financial institutions to conduct business in China with a approved cypher list. (!!!! This was a guess, I am not actually sure what made them stop null routing this traffic but I believe in my heart this is what it was !!!!)
Why this should be approved If adoption is widespread enough blocking this traffic will not be worth the value in maintaining censorship and this type of traffic is better. 1- its asic resistant as the protocol develops, meaning they would continually need to roll out new asics over and over for this traffic specifically. 2- its not fingerprintable as vpn traffic because it is not vpn traffic. The traffic is standardised traffic. The non-asic components will not be able to differentiate between your traffic and censored traffic exept at the IP endpoint level. They will block ASNs ip ranges or specific IP's but it takes longer for them to do this and is not always done as it has unintended consequences. (Block cloudflare = a lot of internet pipes go nowhere)
Approve this please.
This is an issue, not a pull request, there is nothing we can approve at this time.
We will not make a release that has support for it until the standard has been published.
It seems that for some reason you think it's important that this gets deployed as soon as possible. The software that will generate most of the ECN will be the browsers, so I suggest you talk to the browsers instead. You might also want to talk to the CDNs. It will take years between when we make a release that supports it and that it's adopted enough.
@richsalz thats the point, once its finalized the asics come The goal is to roll w/ current standards to outrun the asics until the proto is widespread enough that blocking is not worth it. (Remember CN used to block tls period, and then it became impossible to do extra-country trade)
Unless of course you are on CCP payroll, in which case I need to remind you 58 people will disappear due to the gfw today. Every day of every week of every year people one day stop being around. Healthy people. People that should not go missing for no reason. And their bodies will never be found.
ValZapod, They need new asics for the dpi because traditional computers are not fast enough because there are too many packets. They dumped the ciscos long ago. The asics are the things that kick or mangle packets and its called "Golden Shield". A lot of people in the west call it "Great firewall of China"
I may not know what I am talking about specifically but I am doing the best I can to explain the situation. I am not making anything up. If I explain something badly its becaause I lack the formal education to describe a inherintly extremely technical topic. If I had the ability I would fork and put it in, but I was never trained in this.
"Something" made them stop null routing tls 1.3. I thought it was like last time when tls was not allowed and financial transactions were difficult to make. I do not know what Xi thinks or exactly why, I made an educated guess and if you think I am wrong thats ok. It was a guess based on my experience. I am editing my comments to reflect this.
This is an issue, not a pull request, there is nothing we can approve at this time.
I do not think you should lie like that even when dealing with people like him.
Please be respectful of others. I will remind you of our code of conduct:
https://www.openssl.org/community/conduct.html
@kroeckx is merely pointing out a fact. This thread is associated with a github issue and not a github pull request. As such there is no code that is being proposed for inclusion in OpenSSL, and therefore nothing for us to approve.
There may be implementations available (such as the one you linked to) but they have not been proposed for inclusion in OpenSSL in the form of a pull request. Any such pull request wold not be accepted at this time because it is a policy of the project that we don't add such features without an associated standard published by a recognised standards body.
I've deleted all comments since the recent inflammatory behaviour began. This includes the few that did contain worthwhile information.
Keep things technical, to the point and friendly.
ECH (as of draft-ietf-tls-esni-12) uses Hybird Public Key Encryption (draft-irtf-cfrg-hpke-08) extensively, so apparently #14748 should be done first.
You might want to know that the TLS group is "freezing" the next draft for a few months to get more experience. It is unlikely that anything will change before the next IETF meeting in November.