This bug tracker is so fucking broken.
I did attach two files. Then I got a bogus error saying "captcha failed" (I had NOT been presented any captcha) with the "I'm not a robot" recaptcha, which I checked and sent the form again - but the attachments were lost

Deleted: 1-RESPONSE.png 77.2 KB

	1-RESPONSE.png 77.2 KB View Download

Don't know if it is relevant, but when doing the EXACT SAME on the same server over HTTPS, it works as expected. (of course, when testing over http, both urls are http://, and when testing over https, both urls are https://)

We are seeing a similar issue. Here is how we are able to consistently reproduce it:

1. Login through the https:// website. All cookies work perfectly, cookie is set as 'secure' only from the server.
2. Go to http:// website. No cookies (as all cookies are secure). Login. Server sends a request back saying to set a 'non-secure' cookie. Nothing happens.

http:// for us only fails if https:// already set a secure cookie with the same name. If we logout of https (and the secure cookie is gone), then http works fine and all cookies are set as expected.

It appears that cookies with the same name are not supported, even when its http vs https.

Yes, that's my case too, just figured it out.
Obviously this behavior is wrong.

Additionally, and this is HUGE: deleting all the cookies for the http site (click on the left of the address bar -> Cookies -> remove all) does not fix the issue. 
I guess deleting those of the https site would fix the issue, but that might not be possible/easy (if, for example, the https site now redirects to http), and having to delete ALL browser cookies (i.e. for all sites) is not acceptable.


Real-life use case scenario: I have a website, I "migrate" to https, then I set it up so that any request to http is redirected to https. So far so good.
Now I realize there are some issues with https (e.g. scripts loaded over http, cause mixed content issues) that make the site unusable and need to be addressed. So I revert to http and set the server to redirect https to http, while I work on fixing the issues.
Now thousands of users are suddenly unable to login.

Hey folks, thanks for raising this issue. Did this behavior work prior to Chrome 56? Does it replicate without extensions / in an incognito window?

At first glance this seems worrying, because JS should not be able to delete those cookies, as they are marked HttpOnly. From your screenshots it looks like only ccsessionhash is retained.

It would help to have a net-internals log of what is going on here, could you log one by following the instructions here?
https://dev.chromium.org/for-testers/providing-network-details

I'm not sure why you mention JS deleting cookies. 
JS is not manipulating the cookies at all.

Have you read comment 4?

Also, before setting the bug as Needs-Feedback, have you done every possible effort to reproduce the issue with the information already provided, which should be enough for you to recreate a reproducing scenario? If you haven't then you shouldn't set the Needs-Feedback status. I'm not saying you shouldn't be asking for additional information before trying to recreate the issue with the available information, but setting Needs-Feedback means that (a) no developer is going to do any work on the issue until the extra information is provided and (b) the bug will expire if that doesn't happen.

Hello,

I could reproduce the bug on Chrome 55, just before I upgraded to Chrome 56. However, I do not think the bug was always there (our project is only a couple of months old) and that this did used to work at some point in the last couple of months. I can't make a guarantee on that, however, as this was not a test case we had until it no longer worked.

Also of note, this is only broken for us in Chrome. IE works fine. I have not tried to reproduce on FireFox, Safari, or Opera.

JavaScript is irrelevant here, it is not deleting any cookies. The problem is the browser is ignoring the Set-Cookie header when it is sent over http if a cookie with the same name exists only for https (secure only).

I was able to reproduce the issue in an incognito window as well.

I will try and collect the net-internal logs and get back.

Hello,

Attached are the net-internals-log.

Again, here are the steps:

1. Go to https://mydomain.com. Login. Server returns a HttpOnly, Secure cookie. Cookie is set in the browser. (Do not logout)
2. Go to http://mydomain.com. Login. Server returns a HttpOnly cookie. Cookie is not set in the browser.

Deleted: net-internals-log.json 617 KB

net-internals-log.json 617 KB View Download

Hey, sorry about that! I read the comments too hastily and misinterpreted this bug.
To clarify (mostly for myself), what's happening is essentially:

From https://example.com:
Set-Cookie: foo-cookie=bar; secure

From http://example.com
Set-Cookie: foo-cookie=baz

And the second Set-Cookie does nothing. I think the relevant code is here:
https://cs.chromium.org/chromium/src/net/cookies/cookie_monster.cc?rcl=b95dbb50ccb02e2f5584419033d5409ae0e1d8f5&l=1625
    // If the cookie is being set from an insecure scheme, then if a cookie
    // already exists with the same name and it is Secure, then the cookie
    // should *not* be updated if they domain-match and ignoring the path
    // attribute.
    //
    // See: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone


This is an implementation of strict secure cookies, which shipped in Chrome 49. Here is the relevant intent-to-implement thread:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/g_igIzSue40

+mkwst just in case I haven't misinterpreted things.

Yes, that is exactly it. 

I apologize; I didn't realize that this behavior had existed for a while. This resolves our issue (not sure if it resolves the original poster's issue). 

Thank you very much for looking into this issue and for your timely response.

We've been rolling out the changes to the meaning of cookies' `secure` attribute slowly since the thread that comment 10 pointed to. We ramped that up to 100% in 56 after a few quiet months of lower percentages (I think we had it capped at 20% for a while).

The general behavior is desired (`secure` cookies aren't influenced by non-secure origins), but it sounds like you've uncovered some issues that makes it more difficult to diagnose. You should be seeing a console error, for instance, which apparently isn't showing up. I'll look into that.

As a short-term workaround, setting the cookie from the `https` origin without the `secure` flag will make it available to your `http` origin. We haven't changed the behavior of cookies in general, just that of cookies that assert that they shouldn't be available to non-secure origins.

> The general behavior is desired (`secure` cookies aren't influenced by non-secure 
> origins), but it sounds like you've uncovered some issues that makes it more 
> difficult to diagnose. 

No, we have "uncovered" a fundamental flaw in how "aren't influenced" is designed and/or implemented.

You are getting a cookie in a response over https, and you are not resending the same cookie to the same domain over the same protocol. That's plain wrong. The fact that a cookie of the same name had been received over http for the same domain previously is irrelevant, or it should be. The secure/non-secure attribute has to be used when determining whether to send a coolie back, not when determining whether to store it. When receiving the secure cookie, either you store it as a separate one from the nonsecure one (as if they belonged to different domains), and then you decide which one (or neither) to send back when it's time to send it back, or you always overwrite it. I haven't thought in depth which one is correct, or more convenient, but the current behavior is clearly wrong, as the mentioned use cases demonstrate. 

And it's not just a matter of debugging. Even if we assumed that the behavior is correct (or rather, that there isn't an alternative that doesn't present issues), logging an error to the console is not enough. This is an issue that affect the END USER and on which the user needs to take action. Not only the user would have to be informed (obviously she cannot be expected to look at the console), she would also have to be provided means to take action (e.g. a prompt to choose whether to discard or overwrite the cookie). But of course I don't advocate for that "solution": most users wouldn't understand what this is about, not to mention some would get scared. And there shouldn't be any need once the behavior is fixed.

> You are getting a cookie in a response over https, and you are
> not resending the same cookie to the same domain over the same
> protocol. That's plain wrong. The fact that a cookie of the same
> name had been received over http for the same domain previously
> is irrelevant, or it should be.

Reading the thread above, I think you reversed `http` and `https` in these sentences. Is that correct?

Assuming that it is, I disagree that the fact that a cookie sent over `https` with a `secure` attribute should be "irrelevant" for the `http` version of that domain. For better or worse, cookies' security model ignores the scheme when scoping each cookie. Cookies set on secure origins flow through to the non-secure versions of those origins, and vice versa. The `secure` attribute is a signal that cookies set on secure origins should remain secure, and shouldn't flow through to the non-secure origin with a similar-enough domain.

I agree with you completely that if we could go back in time and reinvent cookies from scratch, we'd give them very different scoping rules, and ensure that they more closely matched the origin model you'd expect. Given that we're stuck with the status quo, https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone attempts to spell out the threat model we wish to address, and to justify the solution we've decided upon.

As I noted above, if you as a developer do not wish to lock your cookies down by ensuring that non-secure origins can't alter or remove them, then you can do so by setting your cookies without the `secure` attribute. That would bring back the behavior that I think you want, where both `http` and `https` have access to the same cookie.

> Reading the thread above, I think you reversed `http` and `https` 
> in these sentences. Is that correct?

Yes indeed.

However I have just observed the exact same behavior right now over https, which means: either it happened the other way round (a cookie received over https not sent back) or something else happened.

> The `secure` attribute is a signal that cookies set on secure origins should
> remain secure, and shouldn't flow through to the non-secure origin 
> with a similar-enough domain.

That doesn't mean, however, that the way to achieve that is to not store the cookie at all. As the use cases have proven (if that wasn't obvious enough) that's wrong.

What about this:

> The secure/non-secure attribute has to be used when determining whether 
> to send a coolie back, not when determining whether to store it. 
> When receiving the secure cookie, [maybe] store it as a separate one from 
> the nonsecure one, and then decide which one (or neither) to send back when 
> it's time to send it back,
 
If done properly, this does not necessarily violate the principle of having a single scope for both protocols.

Also note this:

DELETING COOKIES FROM A GIVEN SITE DOES NOT FIX THE ISSUE.

Even assuming the current model was 100% correct, that is a complete nonsense. It means that (or at least this seems the only explanation), when I'm visiting the http site and delete the cookies, it only deletes the http cookies. So, the https cookies are still there, and hence when I receive the http cookie, it is still not store in order not to overwrite a secure one.
This is inconsistent with the single-scope model. If http and https cookies are supposed to belong to the same scope, deleting the cookies for a domain should delete both http and https cookies for that domain.

The current state of things is a complete mess. It should be reverted to ignoring the secure attribute altogether until this is handled decently.

> if you as a developer do not wish to lock your cookies down by ensuring that 
> non-secure origins can't alter or remove them, then you can do so by setting
> your cookies without the `secure` attribute

I shouldn't have to give up security. We should be able to get security AND correct behavior.

(when will we get the ability to edit one's own comments, for god's sake?)

> However I have just observed the exact same behavior right now over https, which
> means: either it happened the other way round (a cookie received over https not
> sent back) or something else happened.

Can you provide some details? HTTPS origins should be unaffected; if we have a bug in our implementation, I'd love to fix it.

> > The secure/non-secure attribute has to be used when determining whether 
> > to send a coolie back, not when determining whether to store it. 
> > When receiving the secure cookie, [maybe] store it as a separate one from 
> > the nonsecure one, and then decide which one (or neither) to send back when 
> > it's time to send it back,
>
> If done properly, this does not necessarily violate the principle of
> having a single scope for both protocols.

I agree with you that that's an approach we could have taken. I don't think it would completely resolve things, as we'd still need to prevent HTTP origins from setting cookies with a `secure` attribute (as it would end up being a no-op in this model), but it's a workable model.

An issue is that the model it presents is substantially different than the status quo. If we could go back in time and change the underlying security model for cookies, I'd be all for it. Since that seems unlikely to be successful, we're looking for smaller changes that would plug holes without reinventing the wheel.

> It means that (or at least this seems the only explanation), when I'm visiting the http
> site and delete the cookies, it only deletes the http cookies.

Can you give me some detail here as well? If you're doing something like `document.cookie = "name=value; expires=Thu, 01 Jan 1970 00:00:01 GMT` or `Set-Cookie: name=value; expires=Thu, 01 Jan 1970 00:00:01 GMT` on an HTTP origin, then it wouldn't delete a `secure` cookie from the corresponding HTTPS origin. That's intentional, as it prevents the non-secure origin from fixing a user session by removing and resetting the secure cookie.

> We should be able to get security AND correct behavior.

The document I referenced above attempts to describe how the `secure` attribute as previously implemented didn't actually provide security in a number of cases. Moreover, if you're actively using both an http and an https origin for your site, then it's not clear that the `secure` attribute brings you any benefit.

> Can you provide some details?

Unfortunately I can't. What I observed was the exact same symptoms as those described in the original report and comment 4, but the other way round, i.e. switching http and https. My deductions about the cause are mere speculation.



> Can you give me some detail here as well? If you're doing something like...

Forget about javascript, and when I talked about deleting cookies, I meant MANUALLY, as a user, here: (see screenshot) (do it for all listed domains).

There's no valid reason why ANY cookie from that page should be left after that, and hence, no reason why any cookie received right after that should not be saved, no matter what.

Deleted: delete-cookies.png 32.7 KB

	delete-cookies.png 32.7 KB View Download

> when I talked about deleting cookies, I meant MANUALLY, as a user

Interesting. Do you see the same behavior if you clear cookies from chrome://settings/cookies?

> it's a workable model.

And the current one is utterly broken, so I don't see a choice, really. 

> An issue is that the model it presents is substantially different than 
> the status quo

Can you expand on that?? I understand it implies doing work, but I don't see a substantially different MODEL, nor any actual incompatibility. I don't get why you keep talking about going back in time. I'm looking at the present.

> I don't think it would completely resolve things, as we'd still need to
> prevent HTTP origins from setting cookies with a `secure` attribute 
> (as it would end up being a no-op in this model)

I guess we should just replace "cookies received over https" with "cookies received over https and marked as secure" and "cookies received over http" with "cookies received over http or not marked as secure" in my reasonings. A part from that, I'm not sure what the correct behavior for a http marked as secure received over http should be (either discard it, or treat it as non-secure, not sure which one is more correct), but that seems to me completely orthogonal to the issue at hand.

> Interesting. Do you see the same behavior if you clear cookies 
> from chrome://settings/cookies?

I didn't try, and I don't have an agile testing scenario (as I described in comment 5, my real scenario is one of switching forth and back between http-only and https-only, which involves changing server settings) 

If I may interject. I believe the scenario that "clearing cookies" when user is on http does not delete the "secure" cookies is "logical" and makes sense.

Per the IETF draft spec, https cookies are simply not accessible from an http context. This makes sense. They are "secure" and you can't access them, in any way, from an insecure context.

When browser cookies are cleared, they only show cookies that are for that context...in this case the http context (only non-secure cookies). If the user clears the cookies from the https context, then everything IS cleared (secure and non-secure cookies). This behaviour is consistent with how the application behaves.

IMO if the expectation is that the user will be switching between http and https, and cookie sharing is desired, then you'd have to go with the least-common-denominator and make all your cookies NOT secure. 

> Per the IETF draft spec, https cookies are simply not accessible from an http 
> context. This makes sense. They are "secure" and you can't access them, 
> in any way, from an insecure context.

It's ridiculous to apply the notion of "accessing the cookies" to the act of manually deleting them performed by a user. The notion of "being in an insecure context" (or in any context for that matter) simply does not have a meaning here.

Not convinced? Then consider deleting cookies from chrome://settings/cookies. "Is that a secure or non-secure context?" Would you expect to be able to delete secure cookies from there or not? The first question doesn't make sense, the answer to the second is obviosly yes. Why should be deleting cookies from here any different from deleting cookies by clicking on the left of the address bar and clicking "cookies"? That's just a shortcut to manage cookies that are related to a certain website. You are not interacting with the website, you are interacting with Chrome. Neither the htto or https protocols are involved in what you are doing.



And then consider this:
A user sees that something is not working well with a given website (e.g he's unable to log in), and wants to "clear everything" related with that website in order to be able to browse it. There simply HAS TO be a way to do that. Having to clear ALL cookies (i.e. for all websites) is not acceptable, as it has too big of an impact (logging out of every damn thing). So, if clearing the cookies is not going to necessarily clear all the cookies, then add a red panic button "clear every thing related to this website".

Frankly, from the user perspective I don't see how this is something _Chrome_ has to do. This is something the web site has to do. If the web site has decided that it wants http and https, and that it wants some cookies to be secure and some not...that's a rabbit hole that the website has decided to go into.

If there were NO secure cookies when http and https both exist, clearing the cookies just works. But if the web site is telling the browser that I only want this cookie to be accessible in an https context...then that's what is going to happen.

The user doesn't have to clear all the cookies for things to reset. User has to only clear cookies on https and then everything goes away (on both http and https).

It's not a matter of what the website has or doesn't have to do. The problem is: analyse current chrome behavior. Is it correct? No it isn't, it's plain wrong from every possible point of view.


However, I do see now that the current behavior is exactly as mandated by the specification: https://tools.ietf.org/html/rfc6265#section-4.1 
(step 11.2 of section 5.3, not changed by https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01 as far as the relevant stuff here is concerned)

So, unfortunately, this is yet another case of retarded specifications. 
(if I were writing Chrome, I would refuse to comply with the specs where they are so utterly broken, and would fight for changing them, but whatever)

The part about DELETING A WEBSITE'S COOKIES, however, which is completely outside the scope of any specifications, still MUST BE FIXED.

> But if the web site is telling the browser that I only want this cookie to be
> accessible in an https context...then that's what is going to happen.

And what does that have to do with manually deleting cookies??


> The user doesn't have to clear all the cookies for things to reset. 
> User has to only clear cookies on https 

And how exactly does he/she do that??

We have had multiple reports of this same problem recently, reproducible by opening an incognito window and doing two simple steps also described in earlier comments:

1. Open https://demo.vaadin.com/charts
2. Open http://demo.vaadin.com/charts

Notice that you get a "Cookies disabled" error after step 2 and the http version does not work. Ever, until you delete cookies.

Do step 2 before step 1, and everything works - both the http version and https version.

In scenario one, the server (Tomcat) sets a JSESSIONID session cookie as "Secure; HttpOnly" for the https URL. It is sent back to the https URL as expected. All is fine. The second request to a http URL does not include the "Secure" cookie (as expected) so the server generates a new session and sends back another JSESSIONID session cookie as "HttpOnly". This is thrown away by Chrome, never sent back to the server. Obviously the server can't find the session and the application can't work.

In scenario two, the same things happen but the non-secure JSESSIONID is received first and actually stored by Chrome. The secure JSESSIONID received for the https URL is also stored, and both are sent back as expected to the corresponding URLs.

It certainly seems wrong that Chrome behaves differently depending on in which order (http first or https first) you visit a site.

I am not sure based on the discussion and reasoning here how this should be solved on the server (it certainly can't be solved by all users in the world). Should any http + https setup for the same host be considered invalid? Should it be considered a flaw in Tomcat and all other Java servlet containers that use the same "JSESSIONID" cookie for both http and https?

Note that this is not a problem about sharing cookies between secure and insecure parts, it's a problem of getting a non-secure part working at all when you also have a secure part.

@31 your case is just another example of the exact same behavior described in the previous comments, there's nothing new (this is just an observation, no criticism intended - also the reproducing url helps).

This behavior is broken, but unfurtunately it's exactly what the specification mandates. It's the specification that is broken.

> Note that this is not a problem about sharing cookies between secure and 
> insecure parts, it's a problem of getting a non-secure part working 
> at all when you also have a secure part.

Yep (just like in the previous cases). And I would add: it's a problem of getting a non-secure part working at all if the user has PREVIOUSLY visited a secure part (that is, secure/non-secure requests don't need to be intertwined to reproduce the issue).

That must be what the spec authors, unbelievably, did not realize.

The solution would be TRIVIAL. Instead of not *storing* the non-secure cookie if a secure cookie of the same name exists, it should say to always store and overwrite the cookie (with or without the secure attribute as needed, regardless of the old cookie), and to not *send it back* when the security criteria are not met.

For a moment I thought this was a problem in Chrome only but it seems Firefox 52.0b8 behaves exactly in the same way

Re #33: As shown in https://www.chromestatus.com/feature/4506322921848832, Firefox joined Chrome in implementing the "Leave Secure Cookies alone" proposal.

Going to go ahead and close this, as things seem to be working as expected, and FireFox has adopted the same behavior.