Using HOST- prefix as a requirement seems like a bad idea / might not be possible to do
LGraber opened this issue · comments
Third-parties that embed content do not always control all of the cookies that appear to be associated with their domain. Specifically there are a number of intermediate systems that can exist between the third party and embedding page such as a load balancers (here are some docs on AWS ELB). Some of these intermediate systems allow a level of control over these cookies. Obviously many have enhanced that with the advent of SameSite=None requirement for embedded cookies. However, many may not allow the name to be changed. It seems like an unnecessary requirement to have the cookie be named a specific way instead of simply requiring those attributes to be set. I honestly don't know the origin of these convenience naming schemes and so can't figure out why using them as a requirement is a good thing. Can we please drop this naming requirement and just require the attributes be set (either explicitly or via the naming option). It will avoid a lot of headaches
Additionally, for better or worse, our software does not currently require https (I would love it to). We support both hosted and self-managed installations. For our customers who self-manage their servers, we highly recommend configuring https but don't require it (it is required if you want to do embedding). While it is one thing for us to change whether we set an attribute of a cookie when we create it (we already do that for SameSite=None to support embedding), it is another for us to conditionally change the name of our cookies. You could hypothesize I wonderfully clean codebase where all cookies are only ever created / read in one place, but that is rarely the case. Also, even in our code, there are cookies we might not be able to change the name of such as JSESSIONID if you are using certain Spring libraries. Again, removing the naming requirement will avoid a lot of potential blocking issues
The naming scheme is part of the Cookies RFC: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-4.1.3.2. It ensures the cookie cannot be spoofed by another subdomain of the registrable domain.
Thanks! That is good to know! Still causes the problems I describe above which makes using this naming scheme potentially not doable
Is this requirement going to be removed? This could be an adoption blocker and this feature, CHIPS, is needed for 3PC deprecation to not cause lots of issues. Thoughts?
Hey @LGraber, thanks for bringing up these concerns!
Third-parties that embed content do not always control all of the cookies that appear to be associated with their domain.
Interesting, that is good to know!
It seems like an unnecessary requirement to have the cookie be named a specific way instead of simply requiring those attributes to be set.
We are considering changing the Partitioned attribute requirements to no longer require the __Host- prefix in the cookie's name, but we'd definitely want to keep the attribute-level requirements of the __Host- prefix (Secure and Path=/ are required, the Domain would be disallowed), especially requiring the Secure attribute.
It's important to note that the __Host- prefix fixes a pretty egregious security hole in cookies where a server cannot tell if a cookie was set by a subdomain or an insecure endpoint. Having CHIPS require the __Host- was originally intended to be a way to facilitate more widespread adoption of using the prefix, thus reducing the impact of the problem the with cookies' original security model.
That being said, we understand that sometimes compromises need to be made to make CHIPS compatible with the current ecosystem. We will still require the __Host- prefix in the Chrome Origin Trial for CHIPS in M100, but we will consider removing it when CHIPS is shipped in Chrome.
@DCtheTall Hi Dylan ... thanks for the response. How, though, can I test this without removing this requirement. Can you please :) provide an earlier release which has this removed. It seems ... inappropriate to wait until shipping when this design choice is blocking the usability of the feature. Not sure exactly when CHIPS is releasing now but I / we need this and need to be able to test it before any privacy sandbox restrictions are enabled.
As for the Secure and Path=/ and no Domain, I am fine with those. I understand the underlying requirements and needs. It is just encapsulating this in a "name" that is problematic
As for the Secure and Path=/ and no Domain, I am fine with those. I understand the underlying requirements and needs. It is just encapsulating this in a "name" that is problematic
Totally grok your concern there. Filed https://crbug.com/1309902 to track this issue. I also started https://crrev.com/c/3549936. I'll keep you updated on which Chrome release you can expect the name requirement to be changed for the OT.
That does seem like a pretty big regression over the initial proposal as origin-scoped would no longer be feasible.
Or perhaps the required lack of a Domain attribute gives the same guarantees?
Or perhaps the required lack of a
Domainattribute gives the same guarantees?
@annevk - Correct, we still plan to enforce the lack of a Domain attribute.
And that gives the same guarantees? (I think it does, but it would be good if someone confirmed it.)
And that gives the same guarantees?
In terms of how the browser treats the cookie, no, there is no difference.
However, from the server-side perspective, cookies set with the __Host- prefix guarantee the server that the cookie was not set by a compromised, insecure endpoint or compromised subdomain. That is why the prefix is encoded into the name, to give the server some signal their cookie is safer than a cookie set without it.
For partitioned cookies, this may be a bit less of a concern. The __Host- prefix was invented in a world where SameSite=None cookie are globally available to the cookie's site regardless of which context the request is coming from. With partitioned cookies, the compromised endpoint would need to be on the same top-level site as the attacker intends to use the cookie on. That being said, the security win servers get from seeing __Host- in the prefix still apply to partitioned cookies nonetheless.
Well, how can it be set from a subdomain if the Domain attribute is forbidden? I'm not sure I see the compromised endpoint argument, why could those not set any cookie?
Well, how can it be set from a subdomain if the Domain attribute is forbidden?
Consider if some site, example.com, wants to set a cookie on good.example.com and decides to not use the __Host- prefix:
Set-Cookie: foo=bar; Path=/; Secure; Max-Age=...
The browser would send the following header in subsequent requests:
Cookie: foo=bar
Now let's say a compromised subdomain of that site, evil.example.com, overwrites the cookie foo using a Domain cookie:
Set-Cookie: foo=something_evil; Path=/; Domain=example.com; Max-Age=...
After the user returns to good.example.com, the cookie header will be
Cookie: foo=something_evil
and example.com cannot tell whether the cookie was set by the malicious subdomain.
The idea behind including the __Host- prefix in the cookie's name is that it gives example.com signal that the cookie was actually set by the subdomain that the request is for. Since it should not be possible for evil.example.com to set a cookie with the __Host- prefix that gets sent to requests to good.example.com.
@LGraber this change will be part of Chrome 101's release. We are still TBD if we will reinstate the name requirement at the end of the OT, but from 101-102 you can test CHIPS without the prefix.
@DCtheTall I understand that attack, but the question is how it can work in the context of partitioned cookies, right? Given that the Domain attribute is forbidden, it seems like it can't. So the name restriction looks redundant in the specific case of partitioned cookies.
I understand that attack, but the question is how it can work in the context of partitioned cookies, right? Given that the Domain attribute is forbidden
For partitioned cookies, this is definitely less of a concern, I think we are in agreement there.
Our thinking for requiring the prefix was that since not all clients support partitioned cookies yet, and older versions of some clients never will, we figured requiring the __Host- prefix would increase adoptions of better cookie security practices across the web (though that relies on the assumption that servers would use the same cookie for both types of clients). This is discussed a little in the explainer's Alternate Designs section.
Sorry for the delayed thank you but THANK YOU. This removal of the naming change makes the requirement much more inline with the previous changes to add the SameSite=None attribute and so a more 'known' quantity. I appreciate you hearing the feedback, looking through the implications, and making the change to help support easier transitions. Thanks! @DCtheTall @annevk @krgovind
Last question ... when does 101 ship? We are going to put in our changes without the name change as that is not really manageable. I want to know when we can turn this on to try it? Thanks! Have you rethought keeping this trial running after this change? We need this change to do full testing and get you better feedback. Thanks! @DCtheTall
Last question ... when does 101 ship? We are going to put in our changes without the name change as that is not really manageable. I want to know when we can turn this on to try it? Thanks! Have you rethought keeping this trial running after this change? We need this change to do full testing and get you better feedback. Thanks! @DCtheTall
@LGraber - You can see the planned Chrome "Stable Release" dates here. 101 releases on April 26. We do intend plan to run the trial at least through the end of 102. Please see this blogpost for instructions on participating in the trial. Looking forward to your feedback!
Closing this now that the __Host- prefix is no longer a part of this proposal.