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: Issue with MAX_COOKIE_HEADER_LEN
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Benjamin Herrenschmidt via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 19 May 2023 09:02:25 +1000
On Thu, 2023-05-18 at 12:23 +0200, Daniel Stenberg wrote:
> On Thu, 18 May 2023, Benjamin Herrenschmidt wrote:
>
> > the default header size for IIS is 16KB.
>
> ...
>
> > I agree that the failure mode you describe is ... sub-optimal. It was my
> > understanding the limit was introduced to fix a CVE caused by unbounded
> > growth but I might be mistaken.
>
> No, that is correct. Previously there was no limit at all so it could end up
> ridiculously large. But the limit we ended up with was taken from Apache's
> implmentation, so for once it was not just arbitrarily set =)
>
> > Any better idea to solve the issue ? We (Amazon) could carry a downstream
> > only patch for our curl but I don't like that option much... The above seems
> > to be a legitimate use case.
>
> It is simply not interoperable. Sending 10K cookie headers will be rejected by
> some servers and users will not now ahead of time when or if it will work
> against a particular host. I can't think of a really good way to solve this.
This brings me back then to my original suggestion which is to have a
way for the user to explicitly change the default in situations such as
the one described where both client and servers are known to support
and (in this case due to the large kerberos token) require it.
Would this be an acceptable compromise ? If yes, in what form do you
prefer it ? I was originally trying to limit the disruption by adding
support for an env. variable that can be checked lazily (ie, if the
check against MAX_COOKIE_HEADER_LEN fails, then go check it) in order
to avoid the getenv() overhead in the normal case.
But it might be preferable to just add an option to the API and update
the curl program to get a new argument to specify it.
What do you think ? Or we simply give up ? This seems to be a real
field issue if those ADFS servers with Kerberos auth do indeed require
larger cookies.
Cheers,
Ben.
Date: Fri, 19 May 2023 09:02:25 +1000
On Thu, 2023-05-18 at 12:23 +0200, Daniel Stenberg wrote:
> On Thu, 18 May 2023, Benjamin Herrenschmidt wrote:
>
> > the default header size for IIS is 16KB.
>
> ...
>
> > I agree that the failure mode you describe is ... sub-optimal. It was my
> > understanding the limit was introduced to fix a CVE caused by unbounded
> > growth but I might be mistaken.
>
> No, that is correct. Previously there was no limit at all so it could end up
> ridiculously large. But the limit we ended up with was taken from Apache's
> implmentation, so for once it was not just arbitrarily set =)
>
> > Any better idea to solve the issue ? We (Amazon) could carry a downstream
> > only patch for our curl but I don't like that option much... The above seems
> > to be a legitimate use case.
>
> It is simply not interoperable. Sending 10K cookie headers will be rejected by
> some servers and users will not now ahead of time when or if it will work
> against a particular host. I can't think of a really good way to solve this.
This brings me back then to my original suggestion which is to have a
way for the user to explicitly change the default in situations such as
the one described where both client and servers are known to support
and (in this case due to the large kerberos token) require it.
Would this be an acceptable compromise ? If yes, in what form do you
prefer it ? I was originally trying to limit the disruption by adding
support for an env. variable that can be checked lazily (ie, if the
check against MAX_COOKIE_HEADER_LEN fails, then go check it) in order
to avoid the getenv() overhead in the normal case.
But it might be preferable to just add an option to the API and update
the curl program to get a new argument to specify it.
What do you think ? Or we simply give up ? This seems to be a real
field issue if those ADFS servers with Kerberos auth do indeed require
larger cookies.
Cheers,
Ben.
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-05-19