[ech] ECH split mode API

[Tomas Mraz]

It is not clear to me why is this SSL_CTX_ech_raw_decrypt() API call
needed at all? Why isn't all the processing done internally as part of
the SSL_connect()/SSL_accept()? There are existing message callbacks
the applications can hook into to get the messages - so these should be
extended if needed.

But I did not study the ECH RFC so there might be some obvious reasons
why it is needed.

Tomas Mraz, OpenSSL

On Wed, 2023-08-30 at 15:17 +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> I'm wondering about changing the API I defined to allow
> applications to support ECH split-mode, mostly due to
> having now gotten that working for nginx and haproxy,
> with the recent work including support for handling the
> second ClientHello when one hits HRR, and properly
> handling early data when that's present.
> 
> The main off-the-wire input for the existing API is an
> encoded (outer) ClientHello (including the record layer
> header) as that's what's easily available when processing
> the first client hello. When ECH decryption works, we
> return the inner ClientHello, similarly encoded.
> 
> But it turns out that it may be better to accept a
> different input, for two reasons: the 2nd ClientHello
> when one hits HRR is preceded by 6 octets of (pretend)
> ChangeCipherSuite and secondly, if the first ClientHello
> is accompanied by early data, then the buffer that the
> application has may include that after the ClientHello.
> And in the application code, when not terminating TLS,
> those all tend to be present in one buffer (when the
> client sent 'em) as they likely arrived in one packet.
> 
> I had to write basically the same code in nginx and
> haproxy to handle the wrangling of the above and, if
> ECH decryption works, to re-constitute the right buffer
> containing as appropriate the CCS, inner ClientHello and
> early data.
> 
> So, I'm thinking of changing the API to accept as input
> a sequence of catenated encoded TLS messages, with the
> success case behaviour being to return a buffer that's
> the same but with the outer ClientHello being replaced
> by the inner. That should eliminate the need to peek
> into the TLS encoding so much in the application.
> 
> The current API is below, (or at [1]) and the change
> would be to go from ``outer_ch`` as an input to
> ``tls_msgs_buf`` or some such, likely with a check
> that the input contains an optional CCS, then a CH
> and may have additional octets we don't look into
> (the early_data).
> 
> Any thoughts or ideas about potential gotchas welcome.
> (I think I recall someone possibly holding their nose
> about this API when we spoke before, so other comments
> on this are also welcome since I'm likely to be making
> these changes soonish anyway:-)
> 
> Thanks,
> S.
> 
> [1] 
> https://github.com/sftcd/openssl/blob/ECH-draft-13c/include/openssl/ech.h#L117
> 
> int SSL_CTX_ech_raw_decrypt(SSL_CTX *ctx,
>         int *decrypted_ok,
>         char **inner_sni, char **outer_sni,
>         unsigned char *outer_ch, size_t outer_len,
>         unsigned char *inner_ch, size_t *inner_len,
>         unsigned char **hrrtok, size_t *toklen);

-- 
Tomáš Mráz, OpenSSL