quictls / quictls

The official repository for the QuicTLS project.
Apache License 2.0
6 stars 2 forks source link

Add support ECH #58

Open Izorkin opened 5 days ago

Izorkin commented 5 days ago

Is it now possible to add support for ECH?

richsalz commented 3 days ago

Yes. We will soon work with @sftcd and try to get his ECH work ported/PR'd here.

Izorkin commented 3 days ago

Thaks! Let me know if there's anything I can do to help you :)

richsalz commented 2 days ago

You could copy over the PR and see if it works :). Not totally serious about taht.

sftcd commented 2 days ago

I've agreed API changes with the openssl devs and some of that is already merged to an openssl feature branch here. Once about 2 more PRs are merged to that, then it should be fully functional (i.e. client and server working for ECH) so will likely be a better place from which to start. I hope that might be done before the end of the year. Happy to chat meantime if you want to start sooner, based on one of my own branches.

Izorkin commented 2 days ago

@sftcd I failed to apply the patch for quictls 3.3.0.

sftcd commented 2 days ago

not a surprise;-) I've never looked at quictls so don't have good pointers for you now, might get a chance to look at it in a few weeks though, but not yet sorry

Izorkin commented 2 days ago

What PRs still need to be ported?

richsalz commented 1 day ago

So quictls is based on oepnssl 3.3 which has NONE of the ECH work from @sftcd . Perhaps he can reach out to you off-line and suggest an approach? It's all in a 'feature branch' at openssl, so can probably fetch taht branch and do 'git log' to see what is needed?

Izorkin commented 1 day ago

Something seems to be working:

./result-bin/bin/openssl ech -help
Usage: ech [options]

General options options:
 -help              Display this summary
 -verbose           Provide additional output
 -text              Provide human-readable output

Key generation options:
 -out outfile       Private key and/or ECHConfig [default: echconfig.pem]
 -public_name val   public_name value
 -max_name_len int  Maximum host name length value [default: 0]
 -suite val         HPKE ciphersuite: e.g. "0x20,1,3"
 -ech_version int   ECHConfig version [default: 0xff0d (13)]

ECH PEM file downselect/display options:
 -in infile         An ECH PEM file
 -select int        Downselect to the numbered ECH config
sftcd commented 1 day ago

well, the ECH code does work... promise:-)

question: is this something that needs doing now or would it be ok at the end of the year? If the latter that's easier, just due to time pressure. If there's a real reason to need to get done sooner, happy to chat about that. (In which case maybe a call to mutually-explain where there may square-pegs/round-holes etc. would be good.)

richsalz commented 1 day ago

My opinion is end of year is fine. But if the original poster wants it sooner...

Izorkin commented 20 hours ago

I don't know which variant would be better. But I've wanted to test ech at my server for a long time, but I didn't want to give up quic protocol support.

richsalz commented 12 hours ago

OpenSSL is doing a QUIC implementation, it is not complete, and the person who did most of the code left the project. QuicTLS has had QUIC support for years, ever since OpenSSL rejected the PR -- the difference is you have to use one of the existing open source implementations (MSQUIC, Google's, etc). They are complete and production quality. Use whatever you think best, it's a judgement call.

In my opinion, QuicTLS will get ECH before OpenSSL will get a complete QUIC.

sftcd commented 12 hours ago

Just to be clear: I'll happily stay out of the politics of quictls vs. an openssl quic implementation if that's ok:-)

On timing: I'm happy to help with integrating ECH here, but think it'll be better to start on that based on the openssl feature branch mentioned above, once that feature branch is in a working state (end of 2024 hopefully). That should mean that it'll be much easier for this project to keep ECH stuff working without too much effort whenever you pull in a new version of openssl. If we started now, based on the working ECH code from an @sftcd branch, there'd more likely be a bunch of wasted effort involved every time this project wants a new openssl version, so I figure it's better to avoid that. Secondarily, it'll take me a bit of time to get my head around any changes to ECH code needed for quic, and I'll have more time for that in the new year than now.

richsalz commented 12 hours ago

I agree with @sftcd's suggestions: I did not realize that the feature branch isn't quite ready yet.

sftcd commented 12 hours ago

Yeah, about 2 more PRs need merging to it before it'll be fully functional for ECH. You can see what that might look like in my both-sides-now branch but better to wait 'till that's gotten openssl maintainer review and been merged to the feature branch before basing any work on it.