Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: ECH support when curl is using DoH
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stephen Farrell <stephen.farrell_at_cs.tcd.ie>
Date: Thu, 14 Sep 2023 20:54:12 +0100
Hiya,
On 14/09/2023 09:58, Daniel Stenberg wrote:
> On Thu, 14 Sep 2023, Stephen Farrell wrote:
>
>> Question: is this list still ok to use for issues if those are related
>> to WolfSSL in this context or should those be handled otherwise?
>
> If those issues are suspected problems or issues in wolfSSL rather than
> in curl, I propose you submit them as issues at
>
> https://github.com/wolfSSL/wolfssl/issues
>
> ... and I can work with my wolfSSL colleagues to responses from the
> peeps with knowledge of the TLS functionality there. I don't think many
> of them keep up with this list.
The issue was that the WolfSSL client wasn't following the
middlebox compatibility mode defined in RFC8446 appendix D.4
but my ECH server code was assuming that was followed when
reconstructing the innerClientHello after decryption.
I've posted [1] and got it working by changing my ECH code
to be more tolerant. Could be that WolfSSL might want to
make a change too, even though what they're doing is correct.
I'm not sure if following D.4 is still needed today. (Or if
maybe releases of curl+WolfSSL are built to follow D.4 unlike
the local build I did.)
I've only gotten this working on a localhost test so far but
reckon I should have curl+ECH working with either OpenSSL or
WolfSSL in the next week or so. Once I'm there, is it worth
making a PR for curl on github to get feedback on the code?
(I'm pretty sure it'll still not be perfect by then:-)
Cheers,
S.
[1] https://github.com/wolfSSL/wolfssl/issues/6774
>
Received on 2023-09-14
Date: Thu, 14 Sep 2023 20:54:12 +0100
Hiya,
On 14/09/2023 09:58, Daniel Stenberg wrote:
> On Thu, 14 Sep 2023, Stephen Farrell wrote:
>
>> Question: is this list still ok to use for issues if those are related
>> to WolfSSL in this context or should those be handled otherwise?
>
> If those issues are suspected problems or issues in wolfSSL rather than
> in curl, I propose you submit them as issues at
>
> https://github.com/wolfSSL/wolfssl/issues
>
> ... and I can work with my wolfSSL colleagues to responses from the
> peeps with knowledge of the TLS functionality there. I don't think many
> of them keep up with this list.
The issue was that the WolfSSL client wasn't following the
middlebox compatibility mode defined in RFC8446 appendix D.4
but my ECH server code was assuming that was followed when
reconstructing the innerClientHello after decryption.
I've posted [1] and got it working by changing my ECH code
to be more tolerant. Could be that WolfSSL might want to
make a change too, even though what they're doing is correct.
I'm not sure if following D.4 is still needed today. (Or if
maybe releases of curl+WolfSSL are built to follow D.4 unlike
the local build I did.)
I've only gotten this working on a localhost test so far but
reckon I should have curl+ECH working with either OpenSSL or
WolfSSL in the next week or so. Once I'm there, is it worth
making a PR for curl on github to get feedback on the code?
(I'm pretty sure it'll still not be perfect by then:-)
Cheers,
S.
[1] https://github.com/wolfSSL/wolfssl/issues/6774
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pgp-keys attachment: OpenPGP public key
- application/pgp-signature attachment: OpenPGP digital signature