[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