Also this issue does not occur if we are accessing the app on https

We have exactly the same issue reported by a number of clients in our client base and reproduced by us as well. Only happens in chrome, not in any other browser. Happens relatively rarely, but after it happens once – it gets "stuck" and JSESSIONID cookie stops being saved in session until user cleans the cookies.
After "fixing" it by cleaning the cookies on one of our test machines the issue reappeared on the same machine a week later – so this is not a one-off thing caused by some update.
Attaching screenshots showing the two consecutive requests with JSESSIONID cookie not being saved between them and netinternals log of those requests.
Chrome:  57.0.2987.133 (64-bit) on Mac OS, also reproduced on Windows machines.

Deleted: 01_initial_loading.png 209 KB

	01_initial_loading.png 209 KB View Download

Deleted: 02_second_request.png 207 KB

	02_second_request.png 207 KB View Download

Deleted: 02_storage.png 128 KB

	02_storage.png 128 KB View Download

Deleted: net-internals-log.zip 244 KB

net-internals-log.zip 244 KB Download

We were able to trace why this is happening. This is related to the recent changes in how chrome handles cookies with secure flag. One of the relatively recent changes is preventing cookies with 'secure' flag set to be overwritten via non-https connection.

Consider the following scenario:

1. User enters the application via HTTPS. Web app server sets JSESSIONID cookie, flag gets 'secure' flag attached to it.

2. User switches to HTTP connection. Now, the JSESSIONID is not sent with the first request, which is fine. Web app server returns the first response with a new SetCookie for JSESSIONID

In previous versions: at that point the 'secure' JSESSIONID was overwritten by non-'secure' JSESSIONID and evertyhing, user effectevely 'received' a new session and everything was fine.

Currently: the new SetCookie for JSESSIONID id is quietly ignored and the cookie is neither ever sent back (because we are non in non-https connection) AND cannot be overwritten.

So - effectively - this user can no longer establish an HttpSession in this browser. Until either cookies get cleaned or this particular one gets deleted.

I think this may present a serious issue to a lot of currently working applications, depending on security tokens and switching between https/http schemas. At the very least there should be a console warning about that thing, to let developers know they have an issue.

Now, a (hopefully temporary) solution for a web server running behind apache/httpd. Include this mod_headers directive in your httpd.conf (or whatever config you use for that server):

Header edit* Set-Cookie "(JSESSIONID=.*)(; Secure)" "$1"

this will remove the 'secure' flag from JSESSIONID SetCookie. The cookie will no longer be secure, so the 'solution' is not really a good one, but it will help in a critical production situation

Potentially better solution from a Chrome side (besides reverting this change -- which probably won't happen) would be to treat 'secure' and 'insecure' cookies for the same domain as 2 separate 'areas' and send 'secure' ones to a https schemas and 'insecure' ones to http ones, while allowing 'secure' ones to only overwrite secure ones and same for insecure.

@aramir: thanks a lot for the detailed analysis, and for suggesting the workaround.

> One of the relatively recent changes is preventing cookies with 'secure' flag set to be overwritten via non-https connection.
This is strange and backward incompatible changes. The change breaks existing apps and brings customers complains who can't understand what's happening. 

Firefox and Safari sends cookies w/ "secure" flag even if non-secure port is used (AFAIK, this is be RFC!). Ok, if Chrome wants to provide better security, it shouldn't just silently ignore app attempts to set the cookie via non-secure flag on non-secure port. One of the possible options can be a separation for these two cookies (transparent for app/user, on Chrome side).

It's not the port that's secure or not, but the protocol.  Non-secure cookies are never sent over HTTP, so a separate HTTP-only cookie store for setting secure cookies which could never be sent over HTTP doesn't seem to accomplish anything.

The difference in Chrome is that secure cookies can't be overwritten (Or even just written) using HTTP.  So not only can an MitM attacker not see secure cookies, it can't overwrite them, either.

[mkwst]:  Mike, what's the status of standardizing leave-secure-cookies-alone?  The latest draft I can find is https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01, which expired earlier this year.

Nevermind, found it.  Latest draft is at http://httpwg.org/http-extensions/draft-ietf-httpbis-cookie-alone.html

Archiving this - working as intended.