[ech] ECH split mode API

[Tomas Mraz]

Ah, OK. Then I think the best API would be modelled as a BIO filter or
something similar - you write the raw data into it and read the
decrypted/modified messages out of it to be passed to the backend
application.

There seems to be no point in requiring the application to extract the
client hello and then mangle it back into new messages for the backend.

But again, I did not study the problem in depth.

Tomas Mraz, OpenSSL

On Wed, 2023-08-30 at 15:33 +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 30/08/2023 15:27, Tomas Mraz wrote:
> > 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.
> 
> It's because the application isn't terminating the TLS
> session at all in this split-mode case, the (frontend)
> application is only doing ECH decryption and then the
> TLS session is established between the client and the
> backend application. For example, with haproxy as the
> frontend in what it calls "tcp mode" we hit this case.
> 
> When haproxy (or other servers) do terminate the TLS
> session, then yes it all happens internally and this
> API isn't needed. In haproxy terms, that's called
> "http mode".
> 
> Nginx has similar capabilities and probably other
> servers too.
> 
> Cheers,
> S.
> 
> > 
> > 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