[ech] ECH PR reviews...

Watson Ladd watsonbladd at gmail.com
Tue Dec 12 01:24:22 UTC 2023


On Mon, Dec 11, 2023 at 4:40 PM Stephen Farrell
<stephen.farrell at cs.tcd.ie> wrote:
>
>
> Hiya,
>
> On 11/12/2023 23:11, Kurt Roeckx wrote:
> > With new code like that, it's ussually also useful to add a file
> > having some basic coverage, an example of a handshake. It will
> > be much faster in finding new coverage in that case. For the client
> > that would be things that the server sends to a client.
>
> Ah. I've been trying to figure that out this evening. (I guess there
> probably isn't a HOWTO for adding fuzzing for new APIs:-)
>
> For ECH, both the most interesting, and the most tricky, thing to
> want to fuzz is the recovered plaintext of an EncodedClientHelloInner
> on the server. I figured a way to handle static bad encodings of
> those in ``test/echcorrupttest.c`` [1] but if there's a way to make
> a fuzzy equivalent of that, that'd be interesting and useful. (Not
> sure that extending the current approach to cover that is doable
> though, given doing so might require defining an otherwise unneeded
> way to do NULL encryption for HPKE.)

Could you fuzz the function that parses it directly? Not as good as
fuzzing in the protocol, but still pretty good.
>
> Cheers,
> S.
>
> [1]
> https://github.com/sftcd/openssl/blob/ECH-draft-13c/test/echcorrupttest.c#L42
> --
> ech mailing list
> ech at openssl.org
> https://mta.openssl.org/mailman/listinfo/ech



-- 
Astra mortemque praestare gradatim


More information about the ech mailing list