[ech] order of extensions/ssltraceref.txt
Matt Caswell
matt at openssl.org
Tue Aug 22 12:42:25 UTC 2023
On 22/08/2023 13:34, Stephen Farrell wrote:
>
> Hiya,
>
> I'm just rebasing my working branch for ECH, have hit an
> issue with the quicapitest and am wondering how best to
> handle that.
>
> The issue: quicapitest compares a memory-based trace
> against a reference file (ssltraceref.txt) but is failing
> in my build as I produce extensions in a different order
> so as to be able to handle ECH inner/outer "compression"
> which requires "compressed" extensions to be contiguous
> in the ClientHello.
>
> The result is that the quicapitest comparison vs. the
> reference file fails.
>
> I think the right fix here would be to regenerate the
> ssltraceref.txt file but am not sure how to do that.
> Can someone advise?
Yes, this is the correct answer. The actual trace generated is stored in
test-runs/test_quicapi/ssltraceref-new.txt
and it is compared against the reference in
test/recipes/75-test_quicapi_data/ssltraceref.txt
You just need to update the ssltraceref.txt file to match the generated
one without disturbing the various wildcard "?" characters.
Matt
>
> An alternative fix might be to not change the order in
> which extensions are encoded when real or GREASE'd ECH
> isn't happening, but I think that'd be wrong as it'd likely
> be some kind of fingerprint, and probably more brittle once
> the QUIC implementation does make use of ECH.
>
> Thanks,
> S.
>
> PS: This may well be better handled as a github issue. I
> can post the question there later if that's useful.
>
More information about the ech
mailing list