Hiya,

On 01/06/2023 13:14, Mathew Heard wrote:
> Pretty cool.
>
> I'm still reading up on each but can this also be done for https
> termination?

Not quite sure what you mean by "https termination" but I
think the split-mode+HRR case below is the only problematic
one caused by ECH. ECH-enabling an nginx server that hosts
a web site was pretty simple.

In case it helps, the main new thing to configure is where
the ECH private keys are stored and that then enables ECH
decryption attempts. If that command ("echkeydir") is in
the "http" stanza of the config then it'll apply to local
web sites, if the command is in the "stream" stanza then
it'll be used with relevant upstreams in ECH split-mode.
There's a config file I use for testing at [6] that
show how to support both ECH split-mode (upstream is
foo.example.com on port 9444 which uses lighttpd in my
test setup) and a local web site (example.com on port 9442).

> Is the SSL pre-read limitation the main issue there?

I think the new issue here is yes that the pre-read module
was (sensibly) designed to only look at the 1st ClientHello
whereas with ECH, something also needs to look at the
2nd one when we hit HRR. (I hit exactly the same problem
when doing an haproxy integration.) The "something" I've
found so far that works was to put the code at [5] into
the proxy module, but I'm uncertain if that's the best
way to do it.

Cheers,
S.

[6]
https://github.com/sftcd/openssl/blob/ECH-draft-13c/esnistuff/nginx-split.conf

>
> On Thu, 1 Jun 2023, 9:31 pm Stephen Farrell, <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hi all,
>>
>> I've been working on implementing TLS encrypted client hello
>> (ECH, [1]) in the OpenSSL library (current branch at [2]).
>> Apologies that this mail requires a bit of knowledge of
>> what ECH does - I'd guess some folks on here will know that
>> already but I'm happy to explain as needed.
>>
>> I have various proof of concept integrations for my code
>> including with nginx (branch at [3]). Adding support for
>> ECH when nginx terminates TLS was pretty straightforward
>> but I have a question about whether the direction I've
>> taken for ECH in "split-mode" is sensible or not.
>>
>> ECH "split-mode" is where nginx will do the ECH decryption
>> but the TLS session is negotiated between the client and
>> the upstream. I added some code [4] to the ssl preread
>> stream module that does the ECH decryption of the initial
>> ClientHello, then forwards on the decrypted ClientHello to
>> the upstream. Again that was pretty easy and seems to work
>> fine.
>>
>> The question that I have relates to when the TLS handshake
>> between client and upstream hits a HelloRetryRequest. In
>> that case the client will ECH encrypt it's second ClientHello
>> but the ssl preread module doesn't get to see that 2nd
>> ClientHello to attempt ECH decryption.
>>
>> So I ended up adding code [5] to the stream proxy module that
>> checks if we're in that ECH split-mode + "pending" HRR state
>> and attempts the ECH decryption if so. After (a lot:-) of
>> trying to figure out where to put that code, it now also
>> seems to work ok.
>>
>> But, I'm wondering if that's the right way to handle doing
>> things with the 2nd ClientHello when we hit HRR and are
>> using the stream module(s) but nginx is not terminating
>> the TLS session?
>>
>> Any comments or advice most welcome!
>>
>> Thanks,
>> Stephen.
>>
>> PS: It'll be a while before ECH is part of the OpenSSL
>> library but once that's happening I do plan to follow up
>> submitting these changes as they are at that time.
>>
>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>> [2] https://github.com/sftcd/openssl/tree/ECH-draft-13c
>> [3] https://github.com/sftcd/nginx/tree/ECH-experimental
>> [4]
>>
>> https://github.com/sftcd/nginx/blob/ECH-experimental/src/stream/ngx_stream_ssl_preread_module.c#L129
>> [5]
>>
>> https://github.com/sftcd/nginx/blob/ECH-experimental/src/stream/ngx_stream_proxy_module.c#L1719
>> _______________________________________________
>> nginx-devel mailing list
>> nginx-devel@nginx.org
>> https://mailman.nginx.org/mailman/listinfo/nginx-devel
>>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel